On Sat, Dec 14, 2013 at 06:48:01AM +0000, 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
I want to point out that we already had a very long discussion to get to this point which is a compromise between what we want and what the servers support. > These are the default available ciphersuits in Firefox Aurora 28.0a2 on a > Windows system: > C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA > C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA > C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA > C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA > C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA > C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA > 0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA > 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA > 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA > 0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA > 0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA > 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA > 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA > 002F TLS_RSA_WITH_AES_128_CBC_SHA > 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA > 0035 TLS_RSA_WITH_AES_256_CBC_SHA > 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA > 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA > 0005 TLS_RSA_WITH_RC4_128_SHA > 0004 TLS_RSA_WITH_RC4_128_MD5 > > Now follows reasoning for removing some of the ciphersuits. > > 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 > C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA > C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA > 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA > > Removing the above ciphersuits also helps avoiding some usage of 3DES (due to > its low performance) and RC4 (due to its vulnerability). Please note that apache and nginx are not the only servers out there. I think that TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA is the only (EC)DHE one supported my some IIS versions. On the other hand I doubt anybody is going to bother with TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA. We currently have to live with RC4 since everybody suddenly seems to want to use this. > 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 I think this actually makes sense that we want to drop them at some point. I would also like to move the minimum allowed bits up. I think for DHE in NSS is currently happy with 512 bits, and IIS is known to use 768 bits and apache 2.2 1024. I would like to see a minimum of at least 1024 for them. I would like to have this even higher, but I would like to see this changd to 768 for DHE at least and 1024 for RSA/DSA/DSS. > 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 But Camellia is the only suite other than AES that is recommended to be used. Previous version of firefox even negiotatied this often due to the order of the ciphers. > The last remaining 3DES ciphersuit should be removed for performance > considerations and its legacy status: > 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA As you can see, there are sites still using it. They do not support AES. So the question becomes do you want to use RC4 or 3DES? > 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 The SHA one is currently the most popular one, sometimes even the only cipher that is enabled on some servers. Note that we also put them completly at the end of our priority list and still is used that much. But I think we all agree that we want to get rid of it. > The positives of removing the listed ciphersuits: > 1) It makes the TLS handshake smaller thus preventing some issues related to > long handshake. > 2) It protects users from misconfigured server ciphersuit preference order - > and thus no vulnerable RC4 ciphersuits will be used. > 3) It protects servers from misconfigured server ciphersuit preference order > - and thus no performance hit will be incurred due to use of 3DES. > 4) It prevents the use of little-reviewed Camellia ciphersuits. > 5) It prevents the use of retired DSS. > > 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 ciphersuits. 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. I really see no point in this. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
