Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA is not insecure #17

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
3 participants
@briansmith
Copy link

commented Jan 10, 2014

SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA is exactly like SSL_RSA_WITH_3DES_EDE_CBC_SHA except for one difference when the handshake negotiates SSL 3.0: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA will use the more secure TLS PRF, whereas SSL_RSA_WITH_3DES_EDE_CBC_SHA will use the less secure SSL 3.0 PRF. Consequently, at least in theory, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA is more secure than SSL_RSA_WITH_3DES_EDE_CBC_SHA. Since SSL_RSA_WITH_3DES_EDE_CBC_SHA is considered "Probably okay" and SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA is more secure than that one, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA should be considered "Probably okay" too.

In practice, no servers negotiate this cipher suite, and the browser that offers it (Firefox 26 and earlier) does not do TLS False Start, so it really doesn't matter in terms of security whether the browser supports the cipher suite or not.

Soon this will be a non-issue because Firefox 27 will stop offering the SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA cipher suite in its ClientHello.

@jmhodges

This comment has been minimized.

Copy link
Owner

commented Jan 10, 2014

So, even with that, I'm hesitant.

The problem is that this thing had no findable documentation on it. See my email to the dev-tech-crypto list back in Nov about it.

I'm really glad you had the link available in your reply to my email (which still not something I could find by searching for it, though my email is), but I worry about the precedent this sets for other old cipher suites. Will we keep getting emails about how "it's not a cipher suite that's been formally allocated, no one else uses it, it's hard to find documentation fo rit, and it's like 6 years old, but it's fine"? It doesn't scale well.

I note that Firefox 27 is just around the corner and this setting will soon disappear for most users.

@jmhodges

This comment has been minimized.

Copy link
Owner

commented Jan 10, 2014

A counter argument I expect to hear would point to the special casing of the Chrome's fallback SCSV and the ChaCha20/Poly1305 cipher suites. However, they all have findable documentation and are actually needed in the current security environment.

Fallback SCSV: http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01
ChaCha20/Poly1305: http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04

I would also be open to adjusting the text and section that the FIPS cipher suite falls in.

@briansmith

This comment has been minimized.

Copy link
Author

commented Jan 10, 2014

It is actually difficult to say that these are bad cipher suites. We disabled them in Firefox because of non-use in browser scenerios, based on our telemetry. I actually wouldn't be surprised if Mozilla ends up having to restore the preference that allows for these cipher suites to be re-enabled due to "enterprise" needs, though I expect we'd still keep them off by default in that case. We won't even know that until later in the year, when this change gets merged into the long-term-support (ESR) version of Firefox. As recently as 2010, these cipher suites were/are considered MUST-implement for at least some enterprisy standards. From
http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html#Mandatory_Ciphersuites:

The specified algorithm suites are considered to be
widely-implemented, secure and interoperable.

R5703 Any TLS-capable INSTANCE that is FIPS compliant
MUST support TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA

R5704 Any SSL-capable INSTANCE that is FIPS compliant
MUST support SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA 

I agree with you that it is hard to find documentation on these via Google and that's not great. That doesn't make them worse than, say, TLS_RSA_WITH_RC4_128_MD5 or weirder than a client actually implementing TLS_RSA_WITH_IDEA_CBC_SHA* or TLS_KRB5_WITH_3DES_EDE_CBC_SHA. However, when you Google for the cipher suite names, there are quite a few "enterprisy" products from IBM, Oracle, and others that support them.

I do think it might be worth expanding the definition of "weird" to include, say, KRB5, IDEA, and/or SEED cipher suites, as well as the FIPS ones, given the rational in section 4.2 of RFC 5269*. It's difficult to rank the badness of this in your "Probably Good," "Improvable," "Bad" ranking system and it depends heavily on taste and political goals. I think that's probably a choice that you would be better off making, as opposed to a contributor like me, based on your rhetorical goals. I think it would be best to accept this change, to remove the misleading information, and then improve the "weird cipher suite" support separately, perhaps by creating a new section like you suggested. Do you agree or disagree? And, with that in mind, would you still like me to update the changeset to remove the "weird" classification completely?

[*] http://tools.ietf.org/search/rfc5469#section-4.2

@jmhodges jmhodges closed this Mar 6, 2014

@AnneTheAgile

This comment has been minimized.

Copy link

commented Mar 6, 2014

Thank you for being such a public and up to date site! I just got this issue now.
At first my security was 'good'. Then after following the tips at http://grymoire.wordpress.com/2014/02/01/improving-the-https-of-firefox-using-howsmyssl-com-and-aboutconfig/ I got the error about SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA , which I cannot find on my about:config. Finding this ticket I understand I have no fears on this particular score :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.