[DOCS-11116] Clarify the format for cipher suite names in Ops Manager Created: 12/Dec/17 Updated: 11/Sep/18 Resolved: 11/Mar/18 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | Ops Manager |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Dmitry Ryabtsev | Assignee: | Caleb Thompson |
| Resolution: | Done | Votes: | 1 |
| Labels: | security, ssl | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
https://docs.opsmanager.mongodb.com/current/reference/configuration/#mms.disableCiphers |
||
| Issue Links: |
|
||||
| Participants: | |||||
| Days since reply: | 5 years, 49 weeks, 2 days ago | ||||
| Epic Link: | DOCSP-1743 | ||||
| Story Points: | 0.2 | ||||
| Description |
|
In Ops Manager v3.6 we provided users with ability to disable specific TLS/SSL cipher suites. We have a corresponding section added to the documentation here. The problem is that it is not really obvious that the format in which the ciphers have to be specified must be the one used in Java, which follows cipher suite names notation as defined in the RFC. To elaborate further, a user might want to use the OpenSSL toolkit for checking the available ciphers. However cipher suite names used in OpenSSL do not match the RFC:
Unfortunately, if the cipher that needs to be disabled is specified in the OpenSSL format (e.g. ECDHE-RSA-DES-CBC3-SHA, not TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA), Ops Manager will silently accept it, but the cipher suite will not get disabled. We should clarify that the cipher suite names must be specified in the Java / RFC format as otherwise some users may end up in a situation when they think they have disabled some ciphers, but that's not actually the case. |
| Comments |
| Comment by Githook User [ 05/Mar/18 ] | ||||||||||
|
Author: {'email': 'caleb.thompson@mongodb.com', 'name': 'MongoCaleb', 'username': 'MongoCaleb'}Message: | ||||||||||
| Comment by Githook User [ 05/Mar/18 ] | ||||||||||
|
Author: {'email': 'caleb.thompson@mongodb.com', 'name': 'MongoCaleb', 'username': 'MongoCaleb'}Message: | ||||||||||
| Comment by Caleb Thompson [ 01/Mar/18 ] | ||||||||||
|
james.broadhead Awesome, thanks. I'll get something staged for you to review soon. | ||||||||||
| Comment by James Broadhead (Inactive) [ 01/Mar/18 ] | ||||||||||
|
caleb.thompson thanks for picking this up. We improved the logging after this ticket was filed. Now, customers will get something like this:
Aside from that, the current docs mention the 'Admin' interface – this is not correct; the change applies to the whole OM interface | ||||||||||
| Comment by Caleb Thompson [ 01/Mar/18 ] | ||||||||||
|
luke.prochazka, james.broadhead-- I'm picking this up for Tony. Based on your most recent comments, it seems to me like the solution is to add a note to the (https://docs.opsmanager.mongodb.com/current/reference/configuration/#mms.disableCiphers) section stating: OpenSLL cipher suite names in do not match the cipher suite names defined in RFC 5246. Cipher suite names used in Ops Manager must follow the RFC or Java conventions. If Ops Manager does not recognize a cipher name, it will ignore the cipher name silently. (and also probably link "RFC 5246" to https://tools.ietf.org/html/rfc5246#appendix-C). Does this work for you? | ||||||||||
| Comment by Luke Prochazka [ 04/Jan/18 ] | ||||||||||
|
In my experience, the published cipher list was incomplete. For example, the following ciphers do not appear on that list, yet that are valid and accepted by the JRE, and are required to resolve for Sweet32:
This is intrinsically the hazard of needing to spell out each cipher combination in the suite, as opposed to explicitly disabling a given cipher. | ||||||||||
| Comment by James Broadhead (Inactive) [ 04/Jan/18 ] | ||||||||||
|
^ I added a comment to the code review. Let's discuss the logging over there & keep this ticket about the documentation | ||||||||||
| Comment by Davi Ottenheimer [ 04/Jan/18 ] | ||||||||||
|
i'm a bit concerned with "The following ciphers were not disabled as they were not recognized..." message at face value. from a security perspective that sounds scary. unrecognized ciphers are not ones that should be left enabled. could we phrase instead as "warning: the following ciphers are enabled and unrecognized"? | ||||||||||
| Comment by James Broadhead (Inactive) [ 04/Jan/18 ] | ||||||||||
|
Thanks everybody for the input. In CLOUDP-26786, we're going to have Ops Manager log "The following ciphers are enabled... " and "The following ciphers were not disabled as they were not recognized...". If we continue to see confusion around this setting once that change has shipped, we'll contemplate adding some simpler UI. (caveat: hiding detail can often be something users don't actually want when it comes to security settings) tony.sansone for this ticket: it seems that a minimal change to our docs would be to link out to the JSSE cipher suite names page https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites | ||||||||||
| Comment by Davi Ottenheimer [ 02/Jan/18 ] | ||||||||||
|
good catch. interesting that java still references deprecated SSL protocol when it means TLS. would it help if we discussed why the RFC used TLS, or other naming standards like this, when we list the mongodb supported ciphers document? | ||||||||||
| Comment by Dmitry Ryabtsev [ 02/Jan/18 ] | ||||||||||
|
Hi everyone, Our further research has revealed that some of the cipher suite names that were defined in Java before TLS got standardised will not match the cipher suite names defined in the RFC. Consider this example:
Here OM will understand SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA only. Unfortunately this adds another level of complexity as users would need to cross check the cipher suite names they put into the OM UI against both - the RFC and the cipher suite names defined in Java. The proposed documentation change needs to be updated to reflect this. | ||||||||||
| Comment by Rodrigo Valin (Inactive) [ 18/Dec/17 ] | ||||||||||
|
We should move forward by adding explicit documentation about the format of the ciphers Ops Manager will understand:
| ||||||||||
| Comment by Rodrigo Valin (Inactive) [ 13/Dec/17 ] | ||||||||||
|
The cipher gets disabled when starting the server, so any message will have to be logged (we don't have a UI for this), and that's going to be probably missed by the admin. We should add this consideration to the documentation and expect the admins to use the right cipher names. Java being unable to understand one particular cipher is related to its ability to recognize a particular cipher, and this configuration can change from one version to the next. Let me try to explain this a little:
We should be explicit about the format Ops Manager expects from the ciphers in order to disable them, but not to report unrecognized ones. | ||||||||||
| Comment by James Broadhead (Inactive) [ 12/Dec/17 ] | ||||||||||
|
tony.sansone thanks for sending over the link – it'd be a good docs change. rodrigo.valin I vaguely remember us discussing printing out a warning if the user passed an unknown cipher - is there some reason it's not possible? If it's reasonable, could you file a CLOUDP to print a warning error message saying something like | ||||||||||
| Comment by Shannon Bradshaw (Inactive) [ 12/Dec/17 ] | ||||||||||
|
jordan.sumerlus, is this a known Ops Manager bug? Is providing an error message in situations such as that which Dmitry describes on the roadmap? cc: tony.sansone |