[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:
Depends
depends on RUST-154 Default to verifying certificates aga... Closed
depends on PYTHON-872 When ssl=True and ssl_cert_reqs not p... Closed
depends on PYTHON-874 Use certifi or wincertstore to load C... Closed
depends on RUBY-886 Verify server certificates by default... Closed
Related
related to DRIVERS-302 Test connections to Mango Closed
is related to PHPC-223 Use explicit SSL options rather then ... Closed
is related to CDRIVER-1182 Load Windows trusted CA by default wh... Closed
Driver Compliance:
Key Status/Resolution FixVersion
PYTHON-872 Done 3.0
RUBY-886 Done 2.1.0
PYTHON-874 Done 3.0
RUST-154 Done
SWIFT-464 Works as Designed

 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.
See commits related to PHPC-223.

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:

  • enable checking against a CRL they manage (ideally the file is watched for changes, running driver state updates gracefully)
  • enable/disable OCSP checking
  • change the OCSP failure modes (hard fail, soft fail, maybe a custom callback)
  • allow/require OCSP stapling (not supported by server, I believe, but if it were)

Most of this really belongs in DRIVERS-124; let me know if I should take it there.

Comment by David Golden [ 30/Mar/15 ]

We need to think carefully about checking revocation because the options for doing so have various problems:

  • CRLs are huge and have to be kept up to date somehow – is that really a driver responsibility?
  • OCSP leads to spurious failures if the CA isn't reachable and has its own vulnerability problems (see No, don't enable revocation checking)

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 DRIVERS-124; specifically:

  • Certificate chains back to a trusted cert
  • Certificate has not been revoked
  • Server's hostname matches CN of certificate presented by server
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.

Generated at Thu Feb 08 08:21:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.