[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: |
|
||||||||
| Epic Link: | GODRIVER Core Specs | ||||||||
| Description |
|
There are three elements to this support:
|
| Comments |
| Comment by Githook User [ 16/Jan/18 ] |
|
Author: {'email': 'saghmrossi@gmail.com', 'name': 'Saghm Rossi', 'username': 'saghm'}Message: |
| 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: |