[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:
Related
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:

// This is the same cipher suite
// Java / RFC
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
// OpenSSL
ECDHE-RSA-DES-CBC3-SHA

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: DOCS-11116 fix
Branch: v3.6
https://github.com/10gen/mms-docs/commit/16226459d39dc523366017737e2864e8a63a122a

Comment by Githook User [ 05/Mar/18 ]

Author:

{'email': 'caleb.thompson@mongodb.com', 'name': 'MongoCaleb', 'username': 'MongoCaleb'}

Message: DOCS-11116 fix
Branch: master
https://github.com/10gen/mms-docs/commit/cd2f5e849a6dc88a1edb4b64a4e08d31e5ee02ca

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:

mms0.log:2018-03-01T17:53:14.835+0000 [main] INFO  com.xgen.svc.core.ServerMain [ServerMain.java.createSSLConnector:634] - Disabled Ciphers: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, foo
mms0.log:2018-03-01T17:53:14.848+0000 [main] INFO  com.xgen.svc.core.ServerMain [ServerMain.java.createSSLConnector:639] - The following ciphers are enabled for Ops Manager: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
mms0.log:2018-03-01T17:53:14.848+0000 [main] INFO  com.xgen.svc.core.ServerMain [ServerMain.java.createSSLConnector:641] - Your config lists the following as ciphers which should be disabled. However, they are not recognised by the JDK. Please check the format of the entries and list of enabled ciphers. [foo]

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 ]

james.broadhead,

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:

SSL_RSA_WITH_3DES_CBC_SHA
SSL_RSA_WITH_DES_EDE_CBC_SHA
SSL_DSS_WITH_DES_CBC_SHA
SSL_DSS_WITH_3DES_CBC_SHA
SSL_DH_DSS_WITH_DES_EDE_CBC_SHA
SSL_DH_RSA_WITH_DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_EDE_CBC_SHA
SSL_CK_DES_64_CBC_WITH_SHA
SSL_CK_DES_192_EDE3_CBC_WITH_SHA

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...".
With luck, this will let users tweak their lists more easily.

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:

Code RFC OpenSSL Java
0x16 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

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:

Cipher suite names should follow RFC or Java conventions, as defined here. If a cipher name is not understood by Ops Manager, it will be silently ignored.

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:

Let's say Java version A includes the cipher-A, which is insecure and admins are disabling it using `disableCiphers`. We can assume that at some point cipher-A will be removed, it will not be accepted by Java anymore, because of how they deprecate obsolete/insecure protocols. At this point the admin will update Ops Manager to a new version, which includes Java version B (which disabled cipher-A), and now they configuration (disabling cipher-A) will become an error or warning, because this cipher is not recognized by the JRE.

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
"Did not understand disabled cipher: [cipher name]. Please use Java format, described here: [docs link]"

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

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