975832 - Enable AES-256 variants of the AES-128 GCM cipher suites we have already enabled

Status: RESOLVED FIXED

(Core :: Security: PSM, enhancement)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ 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.

Comment 1

[sjw]

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

Comment 2

[sjw]

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

Comment 4

[Ralf Hauser]

see also bug 949564

Comment 5

[Simon Eisenmann]

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).

Comment 6

[Yuhong Bao]

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

Comment 7

[Dave Garrett]

(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.

Comment 8

[John Tall]

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.

Comment 9

[Bruno Thomsen]

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.

Comment 10

[Bruno Thomsen]

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

Comment 12

[Elmar Stellnberger]

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.

Comment 13

[Elmar Stellnberger]

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.

Comment 14

[ggramaiz]

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 16

[Meet]

http://google.com

Comment 17

[Masatoshi Kimura [:emk]]

Attachment: patch

Comment 18

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Comment on attachment 8759616 [details] [diff] [review]
patch

Review of attachment 8759616 [details] [diff] [review]:
-----------------------------------------------------------------

great - thanks

Comment 19

[Masatoshi Kimura [:emk]]

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

Comment 20

[Masatoshi Kimura [:emk]]

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

Comment 21

[Masatoshi Kimura [:emk]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d428fe8ac7fe

Comment 22

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/85d31bd76c19

Comment 23

[Kosuke Kaizuka]

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

Comment 24

[Masatoshi Kimura [:emk]]

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.

Comment 25

[ggramaiz]

(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.

Comment 26

[Kosuke Kaizuka]

Masatoshi, ggramaiz

Thank you for providing informaion.

Comment 27

[Alice0775 White]

[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/

Comment 28

[Masatoshi Kimura [:emk]]

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

Comment 29

[Masatoshi Kimura [:emk]]

(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.)

Comment 30

[Alice0775 White]

Thanks.

Comment 37

[Masatoshi Kimura [:emk]]

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