On Fri, Dec 13, 2013 at 10:48 PM, <marlene.pr...@hushmail.com> wrote:
> I present a proposal to remove some vulnerable/deprecated/legacy TLS > ciphersuits from Firefox. I am not proposing addition of any new > ciphersuits, changing of priority order, protocol removal, or any other > changes in functionality. > > I have read these proposed IETF drafts and am using them as guidance along > with my experience: > https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01 > https://tools.ietf.org/html/draft-sheffer-tls-bcp-01 > Besides those, you may find these interesting: * My initial proposal (now out of date; I will clean it up): https://briansmith.org/browser-ciphersuites-01.html * Our previous recent discussion on this mailing list: https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/gFfKw3EOffo and https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/IhrOqMZe8Go and https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/36na1B2brGU and maybe more. > These are the default available ciphersuits in Firefox Aurora 28.0a2 on a > Windows system: > <some items snipped> > C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA > 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA > 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA > 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA > 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA > Note that the cipher suites above were not agreed to in the previous discussion and were not part of my proposal linked to above. They have been enabled for a long time, and I did not disable them in Firefox 27 because I wanted to be conservative in avoiding potential compatibility issues, and because I wanted to see the measurements of the effects of the reordering of the cipher suites. For reference, the cipher suite list for Firefox 26 appears at the end of this email. > Apache/nginx (and possibly many other) configurations that establish > Perfect Forward Secrecy (PFS) ciphersuits will always have available a PFS > ciphersuit that contains AES. This means that the following ciphersuits can > be safely removed, also given their non-usage in real client-server > connections: > C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > I agree. The data shows that this cipher suite is never selected by servers and it will be removed. > C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA > C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA > These cipher suites were included in my original proposal that we agreed to. IMO, it does not make sense to remove these cipher suites unless we also remove the TLS_RSA_WITH_RC4_128_* variants. Ephemeral key exchange + RC4 is much better than RSA key exchange + RC4 (or even RSA key exchange + AES) because it limits the damage of a compromised private key. The data also shows that these cipher suites are still in use. I suspect that as AES-GCM becomes more common, the use of these cipher suites will decrease further and we can reconsider removing them. (More on RC4 below.) > 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA > This cipher suite wasn't in my original proposal, however I think it makes sense to retain it because it is used surprisingly often. Also, usually DHE key exchange is better than RSA key exchange, unless the DHE key is very small. Consequently, I won't remove this one yet, unless/until we come up with a plan for small DHE keys. > DSS is obsolete and is not used for real client-server connections, hence > the following ciphersuits can be removed: > 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA > 0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA > The data we have shows that these are almost never used, and when they are used, they are always used with keys less than 2048 bits, which is supposed to be the minimum key size we support, according to our CA policy. So, we can try to remove these too. Camellia ciphersuits are little supported, never negotiated cipher, and not > as well-tested & reviewed as AES ciphersuits. The following ciphersuits can > be removed: > 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA > 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA > 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA > 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA > I agree that we can remove the Camellia cipher suites now. With the new cipher suite ordering, Camellia-256 usage dropped from ~5.55% in Firefox 26 beta to 0.03% in Firefox 27 beta. Also, Camellia-128 usage stayed at about 0% usage. If we have a problem with AES that causes Camellia to become more important in the future, we can easily re-enable it by default with a Firefox update. > The last remaining 3DES ciphersuit should be removed for performance > considerations and its legacy status: > 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA > As Kurt noted, there are a lot of servers that support only 3DES and RC4. If we remove the TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suites, we will increase the usage of RC4. unless we disable RC4 at the same time. Also, I would bet that there are now servers that can ONLY do 3DES, if they've disabled RC4 and only RC4 and 3DES were available. Also, 3DES is not the best (it has limitations that arise from it being a 64-bit block cipher, and also it has bad performance), but it is still considered a very secure cipher by almost everybody. For these reasons, I think we should leave the these two cipher suites enabled for now. The last remaining RC4 ciphersuits should be removed due to their > vulnerability: > 0005 TLS_RSA_WITH_RC4_128_SHA > 0004 TLS_RSA_WITH_RC4_128_MD5 > > RC4 ciphersuits will likely soon be prohibited anyway if the proposal is > accepted https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01 > I support this effort, but we probably cannot just turn of RC4 and walk away. Instead, we would need to implement some compatibility measures like Microsoft has done and like you suggested. > The positives of removing the listed ciphersuits: > 1) It makes the TLS handshake smaller thus preventing some issues related > to long handshake. > During IETF88, we had a discussion about the long handshake issue. Xiaoyong Wu from F5 described a workaround that Chrome has been testing and which will be in NSS soon (bug 944157 [1]). So, it seems like the long handshake issue may be solved. > 2) It protects users from misconfigured server ciphersuit preference order > - and thus no vulnerable RC4 ciphersuits will be used. > I hope I addressed this above. We can and should try something about this, but we cannot simply turn off RC4. > 3) It protects servers from misconfigured server ciphersuit preference > order - and thus no performance hit will be incurred due to use of 3DES. > Around 1/10,000 servers seem to choose 3DES anyway, so I don't think this is something to spend effort on. > 4) It prevents the use of little-reviewed Camellia ciphersuits. > During my research, I found that Camellia has been studied more than I originally gave it credit for. It definitely isn't just the Japanese government being proud of a Japanese cipher. It is also part of ENISA (European) cryptographic standards. However, because it is never used, and because I suspect that all implementations that support Camellia also support AES, and because other browsers do not support it, I agree that we should remove it. > 5) It prevents the use of retired DSS. > I agree that we should remove DSS cipher suites. We will have some compatibility risk because other browsers currently have at least one DSS cipher suite enabled. However, if browsers start enforcing the minimum key size requirement of 2048 bits, then I believe the compatibility argument will basically go away. > > The possible negatives of the removal: > 1) Some client-server connections might fail. > > Suggested mitigation of negatives: > If the initial handshake fails, make it a silent failure and retry with a > handshake that contains a larger set of ciphersuites. If somebody wants to work on this for RC4, I will help them out. I recommend somebody take this on only if they have some experience writing Gecko C++ code, though, because it is a little more complicated than simply calling a few NSS functions. The code has to interact with Gecko's preference service and deal with the fact that SSL happens on a thread where the preference service is not available. I can point people to some existing code that acts like a template. Otherwise, I think it will be several weeks before I will be free to work on this part. > This could also be accompanied with some non-blocking failure similar to > how mixed-content warnings are presented to the user - and not show the > full padlock icon in the addressbar. > UI changes are difficult because they require hours of meetings and hours of email. Also, I don't think users will generally find such UI indicators useful. Before we can bother the user with such things, we'd need to make the use of sub-optimal crypto very small (e.g. by disabling RC4 in our initial handshake like you suggested) first. > I have especially not heard anything similar to the suggested mitigation > of the negatives of decreasing the number of available ciphersuits, so this > might perhaps be a new idea how to move forward. > I have been wanting to experiment with disabling RC4 and even RSA key exchange cipher suites in the initial handshake for a while. Microsoft does disable RC4 in the IE11 handshake (at least on Windows 8.1), so it seems like that may be surprisingly reasonable, especially since use of the TLS_ECDHE_*_WITH_RC4_128_SHA cipher suites has decreased to less than 0.5% after we added TLS_ECDHE_*_WITH_AES_128_GCM_SHA256 cipher suites. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=944157 Firefox 26 cipher suite list: C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 0087 TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA 0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA C00F TLS_ECDH_RSA_WITH_AES_256_CBC_SHA C005 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 0035 TLS_RSA_WITH_AES_256_CBC_SHA C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 0044 TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA 0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA C00E TLS_ECDH_RSA_WITH_AES_128_CBC_SHA C00C TLS_ECDH_RSA_WITH_RC4_128_SHA C004 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA C002 TLS_ECDH_ECDSA_WITH_RC4_128_SHA 0096 TLS_RSA_WITH_SEED_CBC_SHA 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 002F TLS_RSA_WITH_AES_128_CBC_SHA 0005 TLS_RSA_WITH_RC4_128_SHA 0004 TLS_RSA_WITH_RC4_128_MD5 C008 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA C00D TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA C003 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA FEFF SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
