[DRIVERS-214] Default to verifying certificates against default CA certificates Created: 28/Mar/15 Updated: 08/Jan/24 Resolved: 15/Nov/16 |
|
| Status: | Closed |
| Project: | Drivers |
| Component/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Jared D. Cottrell | Assignee: | Barrie Segal |
| Resolution: | Done | Votes: | 0 |
| Labels: | newdriver | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Driver Compliance: |
|
||||||||||||||||||||||||||||||||||||
| Description |
|
If the server is using a certificate signed by a CA with well-distributed certs, it ought to be possible to verify the certificate without providing an explicit list of trusted certificates. Most languages either distribute their own canonical set of trusted certificates (as in Node.js) or know how to pull them off the OS (as in Python). Drivers should use them if available and no CA certificates have been explicitly passed in as configuration. |
| Comments |
| Comment by Rathi Gnanasekaran [ 15/Nov/16 ] |
|
All drivers validated. Closing ticket. |
| Comment by Hannes Magnusson [ 03/Apr/15 ] |
|
This is a bit complicated in PHP land, depending on PHP versions for example. The current PHP drivers just follows whatever PHP defaults there are. As for our new PHP driver, we now do as much as we can out-of-the-box in all PHP versions. Note that PHP still needs to be configured properly to be able to use the "default CA certificates" (using the openssl.capath INI option). This should be the case when using distro packages. |
| Comment by Jared D. Cottrell [ 31/Mar/15 ] |
|
Thanks David. Yeah, the revocation story is SSL's Achilles' heel--there is no perfect answer. Whatever we decide the behavior should be, we should make sure to clearly document it so that users aren't surprised by it. We should also make it standard across all drivers, at least as much as the underlying languages will reasonably allow. I don't think users expect CRLs to be maintained by the drivers, like Chrome maintains their CRLSet. However, if the default is no CRL and no OCSP check, that means there is no revocation checking going on at all by default, which doesn't seem right. As flawed as it may be, I lean toward enabling OCSP checks by default. I keep going back to the user expecting that when "ssl=true" they get "browser" behavior. Now, as the Chrome blog shows, there is no true standard for SSL across browsers, but they do all do some kind of revocation checking. I agree that the user ought to be able to configure different behaviors. I think more sophisticated customers will want to:
Most of this really belongs in |
| Comment by David Golden [ 30/Mar/15 ] |
|
We need to think carefully about checking revocation because the options for doing so have various problems:
We should have a way to let users enable one or both forms of revocation checks, but I don't think we can pick a default that makes the right tradeoffs for any given user. |
| Comment by Jared D. Cottrell [ 30/Mar/15 ] |
|
That's right, Bernie. I believe the tests to be performed are covered by
|
| Comment by Bernie Hackett [ 30/Mar/15 ] |
|
jared, to clarify, the feature request is to automatically verify the server's certificate when only "ssl=true" is passed in the URI, correct? This would necessarily require verifying against system CA certificates. |