[CDRIVER-1133] Add support for SSL verification options matching the server Created: 23/Feb/16  Updated: 10/Aug/16  Resolved: 18/Jul/16

Status: Closed
Project: C Driver
Component/s: None
Affects Version/s: 1.4.0
Fix Version/s: 1.4.0

Type: New Feature Priority: Major - P3
Reporter: Hannes Magnusson Assignee: Hannes Magnusson
Resolution: Done Votes: 0
Labels: intern2016
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to CDRIVER-842 Allow for more finegrained SSL connec... Closed
is related to CDRIVER-1231 Allow to use system crypto policies Closed
Epic Link: TLS Improvements

 Description   

The server supports the following configuration options:

  • --sslCipherConfig (source)
    Undocumented cipher list override (e.g. remove AES-GCM)
  • --sslDisabledProtocols (source)
    Explicitly disable TLSv1, TLSv1.1 or TLSv1.2
  • --sslAllowConnectionsWithoutCertificates AKA --sslWeakCertificateValidation (source)
    Allow clients to not provide certificate. If it does though, validate it.
  • --sslAllowInvalidCertificates (source and source)
    If certificate validation fails by OpenSSL certification checks, still allow it. Also allow invalid hostnames
  • --sslAllowInvalidHostname (source)
    Allow certificate hostname mismatch to fail (use Subject Alternate Name if exists, otherwise most specific Common Name field in subject).

The OpenSSL built-in checks seem light, and the docs say only:
"The certificate chain is checked starting with the deepest nesting level (the root CA certificate) and worked upward to the peer's certificate. At each level signatures and issuer attributes are checked. "

The server does the following checks:

  • Certificate expiration (source)
  • CRL check if --sslCRLFile is provided (source and source)
    Verifies the chain leaf (NOT entire chain)
  • Certificate issued by specific, or any of the provided CAs (source)

It furthermore explicitly disables:

  • SSLv2
  • SSLv3

It activates all "bug workaround options" in OpenSSL...


Currently we only support weak_cert_validation which equals to --sslAllowInvalidHostname.
If provided with ca_file, it is used.
If provided with crl_file, it is used.



 Comments   
Comment by Hannes Magnusson [ 14/Jul/16 ]

We now support all the above mentioned things expect for sslDisabledProtocols and sslCipherConfig – which are a bit problematic to implement cross TLS libraries.
We could do some string parsing on the protocols value and match against known values like "tls1.0", "ssl3" and then resolve that into however these things are disabled per lib..
But the cipher config would be crazy messy as their string representation isn't always available and not something we can match for.

I'm thinking maybe we should expose the individual "contexts" as callbacks and allow the app to configure it accordingly?

This would be

  • SSLContextRef on Secure Transport
  • SCHANNEL_CRED on Secure Channel
  • SSL_CTX * on OpenSSL

That would allow applications to tune these things as they see fit, irregardless of our recommendation. It also allows them to set some configuration values if we are behind on setting them, or only set them in later versions etc etc.

Comment by A. Jesse Jiryu Davis [ 16/Jun/16 ]

Thanks bjori. Can you update the description with a specific series of tasks that must be accomplished in order to complete this, please?

Comment by Hannes Magnusson [ 16/Jun/16 ]

The description is still fully correct.
These options need to be implemented in all the tls implementations we support.

We already support "weak" (e.g. 'none') validation, and hostname. None of the others.

Comment by A. Jesse Jiryu Davis [ 16/Jun/16 ]

bjori I'm left confused by this. Is there a specific task we need to do to close this ticket?

Comment by Bernie Hackett [ 15/Mar/16 ]

Yeah, good point. Well, using CERT_OPTIONAL in python doesn't hurt anything, it's just pointless.

Comment by A. Jesse Jiryu Davis [ 15/Mar/16 ]

Supporting what Hannes said above, if you try to start mongod without a cert it quits:

$ mongod --sslOnNormalPorts
BadValue need sslPEMKeyFile when SSL is enabled

(Tested with 3.2.)

Comment by Bernie Hackett [ 15/Mar/16 ]

That's interesting. The Python ssl module docs make no distinction.

https://docs.python.org/2/library/ssl.html#ssl.CERT_OPTIONAL

That means our support for this option in PyMongo is completely pointless...

Comment by Hannes Magnusson [ 14/Mar/16 ]

Turns out. We don't need to.

Since it is a protocol error for the server to not send its certificate this flag is noop in client mode.
Setting this flag would only affect our internal mock server in server mode.

SSL_VERIFY_FAIL_IF_NO_PEER_CERT
Server mode: if the client did not return a certificate, the TLS/SSL handshake is immediately terminated with a "handshake failure" alert. This flag must be used together with SSL_VERIFY_PEER.

Client mode: ignored

https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html

Comment by Bernie Hackett [ 14/Mar/16 ]

For weak_cert_validation I think you just want SSL_VERIFY_PEER. The default should be SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT.

Comment by Hannes Magnusson [ 14/Mar/16 ]

Note: We should probably set SSL_VERIFY_FAIL_IF_NO_PEER_CERT even for the generic weak_cert_validation option?
Its technically a bc break, but not sending server cert is a tls error soo........

Comment by Hannes Magnusson [ 23/Feb/16 ]

We also need to document these. our current weak_cert_validation doesn't say anything about what validation it weakens.

Generated at Wed Feb 07 21:11:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.