New issue
Advanced search Search tips
Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Support AES-256-GCM in HTTP/2

Reported by ma...@apsalar.com, Oct 21 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.1.56 (KHTML, like Gecko) Version/9.0 Safari/601.1.56

Steps to reproduce the problem:
1. Attempt to connect to https://aes256gcm.majid.org/
2. Get the error message ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

What is the expected behavior?
Load the page, verify the HTTP settings are using AES-256-GCM

What went wrong?
The nginx 1.9.5 server is configured with the OpenSSL cipher list 'AES256+EECDH' and with HTTP/2 enabled.

Did this work before? No 

Chrome version: 46.0.2490.71 (Official Build) (64-bit)  Channel: stable
OS Version: OS X 10.10.5
Flash Version: 

There is a lengthy discussion of this in  issue 442572 , which pertains to the not-exactly-related deprecation of AES-256-CBC. To quote Adam Langley: "The reason for not enabling AES-256-GCM is because the security value of the AES-256 is not worth the performance tradeoff and because NSS doesn't support it and we try not to diverge from Firefox too much. Cipher suites are not like Pokémon: the aim isn't to enable every single one. We might reconsider that in the future; perhaps even as part of disabling AES-256-CBC (if that happens) so that there's still a 256-bit cipher for the sake of it."

The error message is misleading: the inadequate transport security is not the server's doing, but from Chrome's lack of support for AES-256-GCM. I did not encounter this error previously when the server was configured with SPDY, and with SPDY or HTTP/2 disabled to force a fallback to HTTP/1.1, it will connect, using ECDHE-RSA-AES256-SHA, so this behavior is caused by the parallel HTTP/1.1 and HTTP/2 stacks not being in sync in terms of which ciphers they support.
 

Comment 1 by ma...@apsalar.com, Oct 21 2015

Firefox Developer Edition for Mac does not connect (it yields an empty page with no error message).
Safari 9 on Yosemite connects using HTTP/1.1, TLSv1.2 and ECDHE-RSA-AES256-SHA384.
Safari 9 on El Capitan connects using HTTP/2, TLSv1.2 and ECDHE-RSA-AES256-GCM-SHA384.
Mobile Safari 9 on iOS 9 connects using HTTP/2, TLSv1.2 and ECDHE-RSA-AES256-GCM-SHA384.
Opera on iOS 9 connects using HTTP/1.1, TLSv1.2 and ECDHE-RSA-AES256-SHA.
Chrome on Android Marshmallow shows the same error as Chrome on Mac.

Comment 2 by kenrb@chromium.org, Oct 21 2015

Cc: rsleevi@chromium.org agl@chromium.org
Labels: -Restrict-View-SecurityTeam -Type-Bug-Security Type-Bug

Comment 3 by rsesek@chromium.org, Oct 21 2015

Labels: -OS-Mac OS-All Cr-Internals-Network-HTTP2

Comment 4 by b...@chromium.org, Oct 21 2015

From the HTTP/2 side, it seems to me that it's working as intended.  A cipher suite is negotiated which is on the HTTP/2 blacklist [1], thus Chrome SHOULD [2] and indeed chooses to close the connection.

The server chooses the cipher and the client protocol.  It would be unreasonable for Chrome not to adversite blacklisted ciphersuites, because they might be suitable with other application protocols.  It would be unreasonable for Chrome not to advertise HTTP/2 support, which is a suitable application protocol with certain ciphersuites.  The trouble is that these are both advertised in the TLS client hello, and Chrome is not in the position to define restrictions on ciphersuite + application protocol pairings (except for the inherent one coming from the HTTP/2 specification).  The server picks both the ciphersuite and the application protocol, so one could argue that this is really a server bug.  Which, as the reported points out, could be mitigated by Chrome supporting AES-256-GCM with this particular server deployment.

[1] https://httpwg.github.io/specs/rfc7540.html#BadCipherSuites
[2] https://httpwg.github.io/specs/rfc7540.html#rfc.section.9.2.2

Comment 5 by ma...@apsalar.com, Oct 21 2015

A design flaw in HTTP/2, really, since it imposes additional cipher negotiation requirements that cannot be supported by ALPN.

The cipher list is:
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA

The non-GCM (i.e. CBC) modes are blacklisted, but the first 2 ciphers in the server preference are not.

Isn't AES-256-GCM supported in hardware on both Intel AES-NI and ARMv8-A?

Comment 6 by b...@chromium.org, Oct 21 2015

Re: #5.  "A design flaw in HTTP/2..."  That I cannot argue with.  We seem to be finding out the hard way how big a price it was that we are all paying for moving server deployments generally towards better ciphersuites by such requirements in the HTTP/2 specification.

Since the only non-blacklisted ciphers on the server list are AES256-GCM which are not supported, it seems to me that the workaround to this problem would be to enable additional ciphers that are supported by Chrome and are not blacklisted (AES128-GCM? just a wild guess), and put them after AES256-GCM but before any CBC ones on the server preference list.

Comment 7 Deleted

Comment 8 by ma...@apsalar.com, Oct 21 2015

Sure, that's what I did by switching to EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH, and am indeed getting AES-128-GCM, but it took me a while to figure out the server cipher settings were too high rather than too low because of the wording of the error message.

One possible way around your quandary would be: when you get a banned cipher suite back in a HTTP/2 call, retry offering only the restricted set of acceptable ciphers in the ClientHello. Presumably a server that supports HTTP/2 will implement at least one of them. More leakage between layers, I know. It wouldn't have helped in my case since none of the non-banned ciphers are implemented in Chrome, but for servers where the priority includes banned ciphers like AES-256-CBC above acceptable ones like AES-128-GCM, it would make a difference.

If you think TLS moves glacially, I've spent most of my career since 1994 trying to drive IPv6 adoption along...

Comment 9 by b...@chromium.org, Oct 21 2015

Re: #8, "...retry offering only the restricted set of acceptable ciphers in the ClientHello."  This certainly is a possibility.  I will track ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY errors to assess if it's worth it.
re: #9: I think David and I would oppose such a change :)

Comment 11 by b...@chromium.org, Jan 11 2016

Status: WontFix
Based on the discussion above, my understanding is that there is not much Chrome could do differently, so I'm closing this as WontFix.

Comment 12 by ma...@apsalar.com, Jan 18 2017

It looks like Chrome has added AES256-GCM after all. My 55.0.2883.95 is now negotiating ECDHE-RSA-AES256-GCM-SHA384 just as I finally switched to OpenSSL 1.1.0c for ChaCha20 support...

Sign in to add a comment