+++ This bug was initially created as a clone of Bug #973755 +++ When filing bug 973755, the reporter wrote the following: I wanted to ensure I was using the strongest cipher suites available in TLS v1.2. However, they are not implemented. Specifically, I wanted to only use ECDHE_ECDSA_AES_256_GCM_SHA384 or ECDHE_RSA_AES_256_GCM_SHA384. Expected results: There should be support in Firefox 27.x and above for the following ciphers: ECDHE-ECDSA-AES256-GCM-SHA384 ECDH-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDH-RSA-AES256-GCM-SHA384 If all four can't be implemented, than at least these two should be implemented immediately: ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 They are specified in the RFC (http://tools.ietf.org/rfc/rfc5288.txt) and implemented in openssl (https://www.openssl.org/docs/apps/ciphers.html#TLS_v1_2_cipher_suites). Until support for the above TLS v1.2 ciphers are implemented, the documentation should be updated to reflect "significantly limited support for TLSv1.2." Thanks.

Google changed the ciphers of his YouTube Servers: TLS_RSA_WITH_RC4_128_MD5 was replaced by TLS_RSA_WITH_AES_128_GCM_SHA256 https://www.ssllabs.com/ssltest/analyze.html?d=r18---sn-1gi7zn7y.googlevideo.com

Microsoft has updated their ciphers in IE: https://support.microsoft.com/kb/2929781

see also bug 949564

Any news on this. It is a shame that Firefox cannot access servers which are limited to only allow the strongest cipher suites available. It can now be considered a recommendation to use AES256 instead of AES128. For example see the pqcrypto inital recommendations published on September 07, 2015 at http://pqcrypto.eu.org/docs/initial-recommendations.pdf (Chapter 2).

I think the browser vendors are moving toward ChaCha20-Poly1305 instead.

(In reply to Yuhong Bao from comment #6) > I think the browser vendors are moving toward ChaCha20-Poly1305 instead. This isn't going away, though. Both need to be supported.

The problem with implementing AES256-GCM is that it might encourage people to actually use it. There is a common misconception that more bits equal more security. A successful attack on AES-GCM is highly unlikely to depend on the key size. Using AES256-GCM instead of AES128-GCM does nothing than burn more CPU time and add absolutely no extra security. If support for AES256-GCM is added to nss then it would be strongly advised that it is not enabled by default and that Firefox and other client programs do not enable it.

In a post-quantum computer era AES128 will be considered broken, and the current defense against it is AES256. Due to the advancement done by companies like D-Wave in the quantum computing area, it's only due diligence to support AES256.

You only lose between 10 and 15% AES performance when switching from 128 to 256 bits on a CPU with AES-NI (hardware acceleration). https://calomel.org/aesni_ssl_performance.html

Simon Eisenmann, Bruno Thomsen: AES_256 is considered less secure than AES_128: http://www.heise.de/security/meldung/Einschlaege-bei-AES-256-kommen-naeher-749257.html http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ By nature the AES algorithm has been designed to work with 128bit only; 256bit are an insufficient extension of AES_128 while a brute force attack against AES_128 can still be considered equally infeasible as against AES_256. "The team of Alex Biryukov, Orr Dunkelman, Nathan Keller, Dmitry Khovratovich has according to the cryptography expert Bruce Schneier already succeeded in 2009 to drive attacks against reduced forms of AES-256. The attacks have been in the magnitude of 2^39 and could even be cracked with a normal PC within 9 rounds. Cracking AES_256 in 11 rounds would almost have been possible in 2009." However computing resources have increased since then and cracking regular AES_256 which requires 14 rounds may well be possible already with supercomputers that are more than eight times faster in comparison. The given weakness is related to the key schedule of AES_256. "Parts of the plain text need to be know; such scenarios concern encryption of hard drives or network protocols". Schneier recommends to increase the number of rounds by 16 for AES-128, from 12 to 20 for AES-192 and from 14 to 28 for AES-256. The reason for AES_128 to be hardly attackable would be that with less bits there become less relationships exhibited between these bits at cryptographic analysis.

Nonetheless the far more awkward problem about AES_256 in its current state of implementation is CBC (see for the second article from above) and that better modes like f.i. AES_256_GCM_SHA384 as pointed out in the initial comment are not supported yet.

TLS 1.3 current draft references TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as should be implemented cipher suites. Maybe we should focus on these two for the sake of interoperability. [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-11

Comment on attachment 8759616 [details] [diff] [review] patch Review of attachment 8759616 [details] [diff] [review]: ----------------------------------------------------------------- great - thanks

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b98526084d70 Try looks good (Win7 cl failures are known).

https://hg.mozilla.org/integration/mozilla-inbound/rev/85d31bd76c19fe2e7d32eb9176d15f96fd2048e1 Bug 975832 - Enable AES-256 variants of the AES-128 GCM cipher suites we have already enabled. r=keeler

Why is the priority order different from those of Chromium-based ones? Are there special reasons? Mozilla: AES-128-GCM -> ChaChe20/Poly1305 -> AES-256-GCM Chromium: AES-128-GCM -> AES-256-GCM -> ChaChe20/Poly1305

We had discussions about the priority order in a NSS bug that implemented AES-256-GCM (bug 923089 comment 70 and onwards). I don't know about the reason behind the Chromium's order. Unfortunately, NSS does not (yet) provide flexibility to change the priority order. We need to update NSS to change the order at the moment.

(In reply to Masatoshi Kimura [:emk] from comment #24) > We had discussions about the priority order in a NSS bug that implemented > AES-256-GCM (bug 923089 comment 70 and onwards). I don't know about the > reason behind the Chromium's order. > > Unfortunately, NSS does not (yet) provide flexibility to change the priority > order. We need to update NSS to change the order at the moment. One reason Chromium might prefer using AES-256-GCM over ChaCha20/Poly1305 is that AES/GCM is faster than ChaCha on CPUs that embed native AES instructions. IMHO, the ideal setup might be to put AES-GCM suites in front of Chacha (for perfomance sake) only when the host CPU features such instruction set, but I'm not sure if such a tweak is acceptable/reasonable, and where it would be implemented. On non-x86 platforms, the answer is obviously to privilege ChaCha20/Poly1305 over AES-GCM suites.

Masatoshi, ggramaiz Thank you for providing informaion.

[Tracking Requested - why for this release]: Cannot open web page Could you uplift to 48.0b if possible? We cannot open the following page. https://www.e-conveni.net/

Unfortunately, this patch depends on NSS 3.25 that Firefox 48 will not use.

(In reply to Alice0775 White from comment #27) > We cannot open the following page. > > https://www.e-conveni.net/ You can disable AES-256 cipher suites as a workaround. (Search for "aes_256" in about:config.)

Thanks.

Please consider restricting comments due to continuous spams to a closed bug.