New issue
Advanced search Search tips
Starred by 27 users

Issue metadata

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



Sign in to add a comment

Disable AES-256-CBC modes by default

Project Member Reported by rsleevi@chromium.org, Dec 16 2014

Issue description

We intentionally did not implement AES-256-GCM because the security value of the AES-256 is not worth the performance tradeoff. We also had not implemented the SHA-2 PRFs for TLS 1.2

However, we still leave AES-256-CBC enabled.

We should see about disabling AES-256-CBC by default.
 
I was about to report the lack of AES-256-GCM support, so that modern and secure sites like https://raymii.org aren't considered using "obsolete cryptography" because of browser-side problem. It is Chrome which doesn't support AEAD cipher. And now Google sees about disabling 256-bit encryption completely.

How will people visit my sites if they support 256-bit encryption only? OpenSSL 1.0.2 with CHACHA20_POLY1305 support is not stable yet. Wow, Google, what a shame!

P.S. Sent via Firefox 34.0.5
Correction: Chromium != Google, but I suppose that Google is fine with the existence of such discussions, so they will be responsible for breaking the web by disabling 256-bit AES support in "Google Chrome".
I also do not understand why AES-256-CBC should be disabled and why is not AES-256-GCM implemented at all? Works fine in FireFox, also running Firefox 34.0.5
Have just reported  Issue 445801  about SHA1 sunsetting. Funny thing that Asus RT-N66U uses AES-256-CBC. Chrome definitely doesn't like me and my SOHO-router, wants to make me unable to browse its control panel.

Asus RT-N66U SHA1 AES-256-CBC.png
239 KB View Download
57667348.jpg
65.1 KB View Download

Comment 5 by agl@chromium.org, Jan 1 2015

Disabling AES-256-CBC won't break sites that currently use it unless they *only* support that (very unlikely).

AES-128-GCM is far safer than AES-256-CBC so sites that enable both, but not AES-128-GCM, are being inconsistent.

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.
There is https://cipherli.st run by https://raymii.org from where people can copy the SSL/TLS configurations. It offers 256-bit AES only, unless  the legacy software support is asked.

---> Disabling AES-256-CBC won't break sites that currently use it unless they *only* support that (very unlikely).

The sites support AES-256-GCM, but Chrome doesn't, so how will it not break? Will Chrome perform another ClientHello with 256-bit AES being listed?

---> AES-128-GCM is far safer than AES-256-CBC so sites that enable both, but not AES-128-GCM, are being inconsistent.

Didn't really understand "enable both, but not the first" :(.

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

Android since 4.4 supports AES-256-GCM, and the performance tradeoff is much more important for mobile devices. Logic added and removed here…

BTW, Windows 10 is also going to support it.

Comment 7 by agl@chromium.org, Jan 1 2015

> The sites support AES-256-GCM, but Chrome doesn't, so how will it not break?

SSL/TLS involves a negotiation: the client offers a list of ciphersuites to the server and the server picks one. Both clients and servers support one or more ciphersuites and if they have any in common then the connection will be fine.

(One of the advantages of disabling AES-256-CBC support would be that servers might then pick (the superior) AES-128-GCM.)

> Didn't really understand "enable both, but not the first"

I mean that, conceptually, you can order TLS cipher suites from best to worst. A site might want to support only cipher suites from the top of the list but, if there's a gap, then the site is somewhat inconsistent. (In short: I think the assumption is being made that 256-bit cipher suites are stronger than 128-bit, but CBC is such a disaster in TLS that's not true: AES-128-GCM is better than AES-256-CBC.)

> Android since 4.4 supports AES-256-GCM, and the performance tradeoff is much more important for mobile devices.

We are working to unify Chrome and Android's TLS handling around BoringSSL but both are large projects and it'll take a while. Chrome is at least consistent with itself on other platforms (although we are switching from NSS to BoringSSL at the moment, so that consistency might be partial at the moment.)
---> SSL/TLS involves a negotiation: the client offers a list of ciphersuites to the server and the server picks one. Both clients and servers support one or more ciphersuites and if they have any in common then the connection will be fine.

There are sites that offer 256-bit encryption only, and only AES, until OpenSSL 1.0.2 with CHACHA20_POLY1305 support becomes stable.

I thought that in case of negotiation failure Chrome might perform the second ClientHello where 256-bit AES is listed. Similar to the case when a server is intolerant to TLS 1.1 and TLS 1.2, so it is already common for Chrome to perform several ClientHello messages.

---> I mean that, conceptually, you can order TLS cipher suites from best to worst. A site might want to support only cipher suites from the top of the list but, if there's a gap, then the site is somewhat inconsistent.

Yes, if an admin cares about HTTPS configuration, there is probably "ssl_prefer_server_ciphers on" (nginx) or "SSLHonorCipherOrder On" (Apache) directive. Very useful all the time.

---> nt to support only cipher suites from the top of the list but, if there's a gap, then the site is somewhat inconsistent. (In short: I think the assumption is being made that 256-bit cipher suites are stronger than 128-bit, but CBC is such a disaster in TLS that's not true: AES-128-GCM is better than AES-256-CBC

Yes, I can't disagree that 128-bit AEAD cipher is better than 256-bit CBC + MAC, but there are 256-bit AEAD ciphers, so…
To recap the logic here:
On a scale of security AND speed
128-GCM > 128-CBC
128-GCM > 256-CBC
128-GCM ~ 256-GCM (again, we are counting both performance and effective security here)

However, a number of servers are poorly configured, where the administrator has configured the server to believe that 256 bit ciphers in any block mode are always better than 128-bit.

This is wrong. 128-GCM is far, far more desirable than 256-CBC. Hence why 256-CBC should be disabled.

This bug is not about 256-GCM. Supporting that is a non-goal at this time. It is likely that a bug to support it will go WontFixed at this time.

This bug is purely about the relative strength of 256-CBC vs 128-CBC (which, like GCM, is not really that great, and certainly slower) and of 256-CBC vs 128-GCM (which is absolutely horrible on speed and security).

Comment 10 Deleted

---> However, a number of servers are poorly configured, where the administrator has configured the server to believe that 256 bit ciphers in any block mode are always better than 128-bit.

This is how raymii.org and cipherli.st configured, which are run by "a Linux/Unix sysadmin with experience in High Availability, scaling and clustering, security, (Open)SSL and general linux system administration". Supporting only 256-bit encrtyption gives 100 points for Cipher Strength on SSL Labs.

The same logic when people were installing Windows XP Professional (not Home Edition), and now it is Windows 7 Ultimate (not Home Basic or Premium), even if they are housewifes who don't know what Group Policy is.
Ryan and Adam have already weighed in, but a quick clarification in case this wasn't clear: earlier comments cite Firefox 34.0.5, but that does not support AES-256-GCM either (it also uses NSS). You can check this with https://www.ssllabs.com/ssltest/viewMyClient.html

So disabling AES-128-GCM in favor of AES-256-{GCM,CBC} will lose you AEADs in not just Chrome but also Firefox. I really wouldn't recommend that server configuration.
At least Mozilla isn't going to disable AES-256-CBC, or is it? Yes, Firefox also doesn't support AES-256-GCM, but my comment was about regression attempts.

Wonder if there is any progress in CHACHA20_POLY1305 support. https://bugzilla.mozilla.org/show_bug.cgi?id=917571


Firefox also considers disabling AES-256-CBC.
https://bugzilla.mozilla.org/show_bug.cgi?id=1113974
raymii.org and cipherli.st are exactly examples of the misbelief mentioned by Ryan. SSL Labs should penalize CBC mode block ciphers to correct the misbelief.

Comment 15 by agl@chromium.org, Jan 2 2015

In reply to #8: ChaCha20-Poly1305 isn't final yet. (It's grinding its way through the multi-year IETF process.) OpenSSL 1.0.2 won't support it, at least initially.
Still no answer, will try it for the third time. Ryan, if AES-256-CBC is disabled by default, will Chrome still be compatible with AES-256-only servers?

1. In order to bypass SSLHonorCipherOrder directive, Chrome sends ClientHello without AES-256 ciphers.
2. Negotiation fails. Chrome now assumes a server doesn't support 128-bit encryption.
3. Chrome sends another ClientHello, but with AES-256 ciphers.
4. ServerHello, Certificate, ServerHelloDone, ClientKeyExchange, ChangeCipherSpec, EncryptedHandshakeMessage, TLSv1.2 Application Data…
5. ???????
6. PROFIT

Server Gated Cryptography taken to the new level like never before!

Comment 17 by agl@chromium.org, Jan 2 2015

If a server only supports AES-256 based ciphersuites and we pull AES-256-CBC then, no, those servers won't work. We would not add a fallback to try and work around that.
see also  Issue 58833  

it would be great to have better transparency in the chrome browser, like it was asked for also at firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=949564
How about not offering CBC ciphers by default at all? Just don't announce them in a ClientHello. This is also useful if a server prioritizes AES-128-CBC over AES-128-GCM.

Some Microsoft IIS servers prioritize about five RSA suites over two ECDHE-RSA, so it is also good not to offer RSA.

Unfortunately, the amount of fallbacks will be too damn high.
> Unfortunately, the amount of fallbacks will be too damn high.

what i would propose is this:
1. send hello with only ECDHE and ChaCha20/AES GCM suites.
2. if it fails, retry with CBC suites added and make the padlock yellow to indicate "obsolete cryptography".
3. if that fails, display an interstitial, warning the user about the lack of forward secrecy. only retry with RSA if the user chooses to continue anyway.

if all major browsers did this, the number of sites not supporting ECDHE and GCM  would drop very fast.
Exactly my thoughts! Privacy error page because of a weak cipher suite will definitely force the admins to reconfigure their servers.

PayPal and online-bankings will be sooo "happy" about this.

---> 1. send hello with only ECDHE and ChaCha20/AES GCM suites.

Traditional DHE too, since it is also "modern cryptography".
Labels: Cr-Security Cr-Security-UX M-43
Owner: davidben@chromium.org
Status: Assigned
Kicking this over to David to explore the implementation and UX ramifications of this.
So many sites that support only 256-bit AES… Some of them even request HSTS preload. At least let their admins know about this bug, most of the time I fail to communicate.
Cc: lgar...@chromium.org
#21: traditional DHE as implemented by most browsers is pretty broken and will accept silly DH parameters like https://hotaru.thinkindifferent.net/dh_bad.pem.
I think that the cipher selection handshake algorithm is not suitable for all cases since there are som high security sites that need/insist in the highest grade ciphers that Chromium does not support, and there is a lot to say to the performance trade-off where medium-grade ciphers are preferred since the top-grade ciphers require too much CPU power.

Since it is a long way to change the handshake algorithm I suggest that Chromium does it best to satify all cases by:
1) an option "retry-handshake-with-all-safe-ciphers-after-a-cipher-selection-error"
and/or
2a) an option to include the high-grade ciphers in the first handshake
and/or
2b) a user-defined list of domains with an option to include the high-grade ciphers in the first handshake
the difference between AES 128 and 256 isn't "medium-grade" vs "high-grade". it's more like "high-grade and pretty fast" vs "high grade and slow for no reason".
if you want something that's actually stronger than AES 128, use chacha20.
Labels: -M-43 M-44 MovedFrom-43
[AUTO] Moving all non essential bugs to the next Milestone.  (This decision is based on the labels attached to your ticket.)


Ref: https://sites.google.com/a/chromium.org/dev/developers/ticket-milestone-punting-1

Comment 29 Deleted

Labels: -M-44 MovedFrom-44
[AUTO] This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
@hotaru: only attack against full AES-256 and AES-192 I know is the related-key attack. It is possible when:
1. Your'e encoding data with keys that are related to each other, which means flawed entropy source or AES implementation, which means you're already screwed anyway.
2. In addiction to that you need 2^99 data encoded with 4 of those related keys to perform the attack.

Those conditions are very unlikely in case of TLSv1.2 (session keys doesn't live long), so AES-256 remains WAY stronger than AES-128 in this context (IMO).

Yes, AES-128 is faster. But it should be browser user and/or server owner decision if they want faster or more secure solution, not hard limitation coming from browser developers. If I want to connect to server using 256-bit crypto I should be allowed to do so.

For now to see the https://thundr.eu/ I need to use IE11, Safari, BlackBerry or text-mode Links browser, because Chrome can't negotiate any of the standardized 256-bit TLSv1.2 cipher suites with forward secrecy.

Comment 32 by xoc...@gmail.com, Jul 12 2015

If there's a performance tradeoff, that ought to be the server operator's choice.
It's faster to just disable encryption entirely. I have a hard time see the advantage of the browser not providing support, unless the advantage is payments toward little Timmy's college tuition...

DJB says his servers don't support AES-128 because of batch attacks: https://blog.cr.yp.to/20151120-batchattacks.html

Comment 34 by komm...@gmail.com, Feb 9 2016

His servers support AES-128, see https://www.ssllabs.com/ssltest/analyze.html?d=blog.cr.yp.to
Status: WontFix (was: Assigned)
I'm going to go ahead and close this. I would love to lose CBC mode ciphers, AES-258 and AES-128, but that's probably a ways out.
Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label

Sign in to add a comment