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

RESOLVED FIXED in Firefox 49

Status

()

enhancement
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: briansmith, Assigned: emk)

Tracking

({wsec-crypto})

Trunk
mozilla49
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox48 wontfix, firefox49 fixed)

Details

(Whiteboard: [psm-assigned][adv-main49-])

Attachments

(1 attachment)

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

5 years ago
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

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

Updated

5 years ago
Duplicate of this bug: 1051210

Updated

5 years ago
See Also: → RC4

Comment 4

4 years ago
see also bug 949564

Updated

4 years ago
Blocks: 1178092

Comment 5

4 years ago
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

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

Comment 7

4 years ago
(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

3 years ago
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

3 years ago
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

3 years ago
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
Assignee

Updated

3 years ago
Duplicate of this bug: 1244752
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.

Comment 14

3 years ago
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 hidden (spam)
Assignee

Comment 17

3 years ago
Posted patch patchSplinter Review
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Attachment #8759616 - Flags: review?(dkeeler)
Assignee

Updated

3 years ago
Depends on: 1277255
Comment on attachment 8759616 [details] [diff] [review]
patch

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

great - thanks
Attachment #8759616 - Flags: review?(dkeeler) → review+
Whiteboard: [psm-backlog] → [psm-assigned]
Assignee

Comment 19

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

Comment 20

3 years ago
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 22

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/85d31bd76c19
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Assignee

Updated

3 years ago
Depends on: 1278434

Comment 23

3 years ago
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
Assignee

Comment 24

3 years ago
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

3 years ago
(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

3 years ago
Masatoshi, ggramaiz

Thank you for providing informaion.

Comment 27

3 years ago
[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/
Flags: needinfo?(VYV03354)
Assignee

Comment 28

3 years ago
Unfortunately, this patch depends on NSS 3.25 that Firefox 48 will not use.
Flags: needinfo?(VYV03354)
Assignee

Comment 29

3 years ago
(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

3 years ago
Thanks.
Whiteboard: [psm-assigned] → [psm-assigned][adv-main49-]
Comment hidden (spam)
Comment hidden (spam)
Comment hidden (spam)
Comment hidden (spam)
Assignee

Comment 37

2 years ago
Please consider restricting comments due to continuous spams to a closed bug.
You need to log in before you can comment on or make changes to this bug.