[CDRIVER-933] mongoc_ssl_opt_get_default changed in 1.2.0 Created: 14/Oct/15 Updated: 08/May/17 Resolved: 29/Oct/15 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | libmongoc, tls |
| Affects Version/s: | 1.2-rc0 |
| Fix Version/s: | 1.2.1 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Jeroen Ooms [X] | Assignee: | A. Jesse Jiryu Davis |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
Is it intended that `mongoc_ssl_opt_get_default()` will now enforce SSL and disconnect otherwise? To reproduce, use connect.c
It will no longer connect to non-ssl servers. This was not the case in 1.1 |
| Comments |
| Comment by Githook User [ 04/Nov/15 ] | ||||||||||||||||||||
|
Author: {u'username': u'bjori', u'name': u'Hannes Magnusson', u'email': u'bjori@php.net'}Message: Merge branch 'r1.2'
| ||||||||||||||||||||
| Comment by Githook User [ 04/Nov/15 ] | ||||||||||||||||||||
|
Author: {u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}Message: Beginning in version 1.2, once a pool or client has any SSL options | ||||||||||||||||||||
| Comment by Githook User [ 29/Oct/15 ] | ||||||||||||||||||||
|
Author: {u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}Message: Beginning in version 1.2, once a pool or client has any SSL options | ||||||||||||||||||||
| Comment by Hannes Magnusson [ 23/Oct/15 ] | ||||||||||||||||||||
|
Yeah I absolutely see the value in what you are proposing. For now, our stance is to error on the side of security in ambiguous situations like setting ssl_opts but forgetting to set "?ssl=true" in the connection string. We should think about doing something like "mongoc_ssl_set_default_opts ()" which would be used by default when ?ssl=true is provided. I think such name is clearer that "if ssl opts are needed, use these" rather then the current "use these ssl_opts for this mongoc_client" like mongoc_client_set_ssl_opts() implies. | ||||||||||||||||||||
| Comment by Jeroen Ooms [X] [ 23/Oct/15 ] | ||||||||||||||||||||
|
OK I took your advise, so that solves the problem for me. You can close the issue if you'd like. However I am still not 100% convinced it is irrational to set general options on a client handle (cert store, etc), even if you are unsure if the user is actually going to connect to an ssl server. In libcurl we always first set the options on the client handle which the user can use for connecting to one or more http and/or https servers. Suppose that at some point you want to add a feature which allows certain SSL options to be set at runtime via an environment variable. This is quite nice because it requires no effort from the driver implementations to expose bindings for each option. For example libcurl will pick up the CURL_CA_BUNDLE variable, regardless of which language you are using. However with your current logic such a feature would be annoying because mongoc would limit itself to only ssl connections if such an environment variable happens to be set in the process, which is probably not what we want. | ||||||||||||||||||||
| Comment by Hannes Magnusson [ 15/Oct/15 ] | ||||||||||||||||||||
|
Jeroenooms But you actually set the ssl_opts on the client you are using. Its not only a global context you can apply to a client, but you actually do assign it to the client with mongoc_client_set_ssl_opts(). I would recommend you instead do:
rather then unconditionally apply the ssl_opts to the client. This becomes a bit clunky when you are doing connection pooling though as individual client could oddly enough be (re)constructed with whatever settings that are later set due to the fact its not immutable – and therefore has no mongoc_client_pool_get_uri ().. But this is how I would recommend achieve this effect. | ||||||||||||||||||||
| Comment by Jeroen Ooms [X] [ 15/Oct/15 ] | ||||||||||||||||||||
|
FWIW, my expectation as a developer was that this would work similar to a http client, with mongoc_client_set_ssl_opts defining global system options such as the location of the cert store. I was under the impression that only the URL controls whether SSL is used for a given server or not. Just like a browser or libcurl support both http and https urls, even though ssl has been configured. I think it is unexpected that configuring global SSL options would actually limit the client to SSL servers. What I am trying to design is a client that has proper SSL support, and which will support both SSL and non-SSL connections. Just like browser with SSL support will let the user enter both http and https urls. | ||||||||||||||||||||
| Comment by A. Jesse Jiryu Davis [ 14/Oct/15 ] | ||||||||||||||||||||
|
To complete this ticket, first do | ||||||||||||||||||||
| Comment by A. Jesse Jiryu Davis [ 14/Oct/15 ] | ||||||||||||||||||||
|
That's not quite the bug; in 1.1 (and all prior versions with any SSL support) if "ssl=true" is not in the client's URI then it requires a plain-text connection, regardless of whether you call mongoc_client_set_ssl_opts:
| ||||||||||||||||||||
| Comment by Hannes Magnusson [ 14/Oct/15 ] | ||||||||||||||||||||
|
Interesting. On one hand you are supposed to provide "ssl=true" in the connection string to enable SSL. Once SSL is enabled, then SSL is enabled. We will not allow you to think you are connecting to a SSL enabled server, when in fact it isn't. I have reproduced this like you mentioned in 1.1 and that is a severe bug that has now been fixed in 1.2. There is a compiler error in the connect.c example you linked so will that - but we won't be changing setting SSL options to "maybe, if its cool with you server, lets chat SSL - otherwise, you know, I'm fine with clear text". |