[GODRIVER-139] Support native SSL Created: 21/Nov/17  Updated: 28/Oct/23  Resolved: 16/Jan/18

Status: Closed
Project: Go Driver
Component/s: None
Affects Version/s: None
Fix Version/s: 0.0.1

Type: New Feature Priority: Major - P3
Reporter: William Banfield Assignee: Samuel Rossi (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by GODRIVER-140 Automatically enable TLS when using SRV Closed
Epic Link: GODRIVER Core Specs

 Description   

There are three elements to this support:

  • The driver should support TLS without users having to provide a dialer. For this, we should use Go's native TLS libraries, but possibly with a restricted list of allowed cipher suites, based on consultation with product mgmt. (davi.ottenheimer, do we have such a list already?)
  • We must support TLS configuration in the connection string, possibly following libmongoc's lead for additional configuration parameters for certificates, CA, etc.
  • We must add TLS testing to Evergreen using native TLS


 Comments   
Comment by Githook User [ 16/Jan/18 ]

Author:

{'email': 'saghmrossi@gmail.com', 'name': 'Saghm Rossi', 'username': 'saghm'}

Message: GODRIVER-139 Support native SSL
Branch: master
https://github.com/10gen/mongo-go-driver/commit/2a5ee0b857efe532de07c05a7401d30761070d11

Comment by Davi Ottenheimer [ 12/Dec/17 ]

whitelist is better because it's always a short list of safe ciphers, and an infinite list of unsafe ones. preventing "newer" cipher suites is a feature as much as preventing older ones.

when you switch to FIPS mode it references a known list of good ciphers, so drivers that support FIPS technically have that whitelist intent even if not fully implemented let alone validated

Comment by Bernie Hackett [ 01/Dec/17 ]

Wouldn't it be better to have a blacklist for cipher suites? A whitelist will inevitably prohibit newer cipher suites from being used until someone realizes the list has to be updated, then you have the problem of figuring out which newer ciphers are supported on which versions of OpenSSL, Secure Transport, sChannel, libtls, ... I'd be more worried about that then a cipher suite that has been deemed weak not being added to the blacklist promptly.

In short, a whitelist has to be updated to remove ciphers newly deemed weak as well as adding new strong ciphers. I blacklist just has to add weak ciphers.

Also, we don't have a white or blacklist in any other driver (though some TLS libraries have one built in already).

Comment by Davi Ottenheimer [ 27/Nov/17 ]

william.banfield we are moving to a proactive secure by default stance on ciphers because that is requested by customers as well as the security and audit communities. we get multiple requests a week, sometimes several each day, from customers and their security/audit teams for documentation proving we have a consistent restricted cipher list across products they will use. lowering the bar is a configuration option, but to efficiently answer these requests that all ask the same thing (will customer data be safe because using known strong ciphers) we are asking all product lists to comply with the standard.

Comment by William Banfield [ 27/Nov/17 ]

kenneth.white davi.ottenheimer Thanks for the info! As David said, I'm not directly involved. I would however like to know why, if mongo itself already restricts the allowed cypher list, do we also need to restrict our list?

Comment by David Golden [ 26/Nov/17 ]

kenneth.white, thanks for volunteering! Will isn't directly involved in this part of the driver. kris.brandow and sam.rossi are the main team working on the driver – so please coordinate with them.

Comment by Davi Ottenheimer [ 22/Nov/17 ]

yes, the "supported cipher suites" document is here:

https://docs.google.com/a/10gen.com/document/d/1vA2w92MI8WT6aillyuXLxNUkbInGH4gDUws29fqX2fc/edit?usp=sharing

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