Circumstances cause CBC often to be preferred over GCM modes

[Hanno Böck]

Hi,

Sorry for crossposting this to three lists but I feel this is a
multi-software-issue and I feel all software involved need to find a
way to resolve this.

I feel the current software setting of tls server configs and browsers
leads to the unoptimal result that often CBC modes are preferred over
authenticated encryption GCM-modes. There seems to be widespread
agreement that TLS-CBC-Modes are not optimal and should be avoided
(Padding oracles, Lucky Thirteen etc.)

Firefox and Chrome support authenticated encryption via TLS 1.2 and GCM
these days. However they have for some reason decided not to support
AES-256 but only AES-128. This is in itself no problem because there is
no reason to believe AES-128 is not safe. But it leads to the probably
unintended consequence that often AES-256-CBC is preferred over
AES-128-GCM.

Take this scenario:
* Server operator uses apache+openssl wiht cipher string
"HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH". This seems reasonable. Only HIGH
security ciphers and sort them by strength.
* Browser (Chrome or Firefox) will take the first preferred cipher
suite it supports. As it doesn't support AES-GCM-256 it will choose
AES-CBC_256.

What can be done to avoid this?
a) First of all server operators can do more manual work and sort
ciphers on their own. However it's probably not desired that every
server operator needs to know the inner details of TLS.
b) OpenSSL changes so that it considers GCM-modes always more secure
than CBC modes and sorts them to the front.
c) Browsers could start supporting AES-256-GCM
d) Browsers could stop supporting AES-256-CBC

Each of these would solve the issue, they don't exclude each other
(in theory you could do all of them). I feel b) should happen anyway
and probably one of c) or d). If browsers feel AES-128 is "good enough"
they could just remove AES-256 support completely. If they feel they
want AES-256 in the unlikely case that attacks against AES improve by a
great margin then there is no reason not to support AES-256-GCM. It
feels illogical to support AES-256, but only in its less secure mode.

Thoughts?

cu,
--
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

[Chris Palmer]

+agl explicitly, just to be sure

> To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Lucas Garron]

Hopefully most people on these lists know this, but I thought I'd point out that Mozilla provides a neat TLS configuration generator (which strongly tries to prefer at the moment).

If part of the effort for this issues involves recommending that server operators upgrade their cipher suite configs, it would probably be a good idea to recommend using Mozilla's tool (which is also the most likely place to contain up-to-date advice in the future).

[Salz, Rich]

Is this a theoretical issue, or have you seen it in widespread use?

I thought most servers these days picked what they wanted, and used the client ordering as a suggestion, at best.


--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz

[Ryan Sleevi]

This isn't an accurate description of the flow.

The client advertises its set of ciphersuites in the client hello. The server is responsible for choosing the ciphersuite used, and may take either client priority into consideration (e.g. if the client is a constrained device, it might intentionally prefer a weaker-but-efficient algorithm; this was classically true for 3DES and RC4) or it may ignore this and choose at the server level. For example, with Apache, http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslhonorcipherorder

Chromium-based browsers will already optimize their ciphersuite preferences to prefer GCM over CBC in their advertisements (and with the draft/experimental POLY1305 algorithms as well being prioritized over CBC). Likewise, so does Firefox.

You can throw your favourite browser at https://www.ssllabs.com/ssltest/viewMyClient.html to see this. The NSS bug (Firefox, some versions of Chrome) for this was https://bugzilla.mozilla.org/show_bug.cgi?id=936828

 

>
> What can be done to avoid this?
> a) First of all server operators can do more manual work and sort
>   ciphers on their own. However it's probably not desired that every
>   server operator needs to know the inner details of TLS.

This is already recommended. However, again, the ClientHello sets client priority.

 

> b) OpenSSL changes so that it considers GCM-modes always more secure
>   than CBC modes and sorts them to the front.

This could be done. OpenSSL already provides callbacks for this.

 

> c) Browsers could start supporting AES-256-GCM

This is unlikely. The security vs performance costs at that key strength vs the effective security value lend themselves to preferring AES-128, although I'll let Adam speak to this.

 

> d) Browsers could stop supporting AES-256-CBC

This seems reasonable. I filed https://code.google.com/p/chromium/issues/detail?id=442572 to track the discussion in Chromium (please don't take the bug as a conclusion)

[Hanno Böck]

On Mon, 15 Dec 2014 20:31:53 -0500
"Salz, Rich" <rs...@akamai.com> wrote:

> Is this a theoretical issue, or have you seen it in widespread use?

www.openssl.org would be an example where you can see it live and
real :-)

[Hanno Böck]

On Mon, 15 Dec 2014 17:36:40 -0800
Ryan Sleevi <rsl...@chromium.org> wrote:

> > > * Server operator uses apache+openssl wiht cipher string
> > > "HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH". This seems reasonable.
> > > Only HIGH security ciphers and sort them by strength.
> > > * Browser (Chrome or Firefox) will take the first preferred cipher
> > > suite it supports. As it doesn't support AES-GCM-256 it will
> > > choose AES-CBC_256.
> >
>
> This isn't an accurate description of the flow.
>
> The client advertises its set of ciphersuites in the client hello. The
> server is responsible for choosing the ciphersuite used, and may take
> either client priority into consideration (e.g. if the client is a
> constrained device, it might intentionally prefer a
> weaker-but-efficient algorithm; this was classically true for 3DES
> and RC4) or it may ignore this and choose at the server level. For
> example, with Apache,
> http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslhonorcipherorder

Ah, sorry, of course you're right.
My analysis of the situation was wrong, however it doesn't really
change the outcome: There are a number of sites probably configured in
good faith with secure settings that result in CBC being preferred over
GCM.

(But good to note that a quick fix is to disable SSLHonorCipherOrder
on affected apache servers)

[Ryan Sleevi]

I fear you may have misread again.

SSLHonorCipherOrder is on by default, and respects the client preferences. The mainstream clients generally prefer GCM over CBC, ergo, honoring the cipher order is the right thing.

By setting SSLHonorCipherOrder to false (disabling it), you set the servers preference. It now becomes the server operator's responsibility to configure the ciphersuites correctly, which gets into the issues you were wanting to avoid.

As Rich said, have you observed this in practice and looked into why? At least Chrome and Firefox are doing the right thing. The story with IE is... more complicated... but is getting better. But that's a Microsoft/IE issue.

[Hanno Böck]

On Mon, 15 Dec 2014 18:07:15 -0800
Ryan Sleevi <rsl...@chromium.org> wrote:

> I fear you may have misread again.
>
> SSLHonorCipherOrder is on by default, and respects the client
> preferences. The mainstream clients generally prefer GCM over CBC,
> ergo, honoring the cipher order is the right thing.
>
> By setting SSLHonorCipherOrder to false (disabling it), you set the
> servers preference. It now becomes the server operator's
> responsibility to configure the ciphersuites correctly, which gets
> into the issues you were wanting to avoid.

Reading apache doc tells me the opposite:
"When choosing a cipher during an SSLv3 or TLSv1 handshake, normally the
client's preference is used. If this directive is enabled, the server's
preference will be used instead."

> As Rich said, have you observed this in practice and looked into why?

I have on my own servers and as I already wrote you can on
see it on www.openssl.org.

Having tested with not setting SSLHonorCipherOrder however causes other
issues - some other browsers won't use FS ciphers then (notably some
older IE versions and all mobile IEs - at least that's what the ssl labs
test says).

To reiterate the above said, I have two apache configs:
SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH

Result: GCM in chrome/ff, but no FS in many IE versions (and A- on ssl
labs).

SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH

Result: no GCM in chrome/ff, but FS in all ssl labs reference browsers
(and A+ rating).

[Ryan Sleevi]

On Mon, Dec 15, 2014 at 6:15 PM, Hanno Böck <ha...@hboeck.de> wrote:

On Mon, 15 Dec 2014 18:07:15 -0800
Ryan Sleevi <rsl...@chromium.org> wrote:

> I fear you may have misread again.
>
> SSLHonorCipherOrder is on by default, and respects the client
> preferences. The mainstream clients generally prefer GCM over CBC,
> ergo, honoring the cipher order is the right thing.
>
> By setting SSLHonorCipherOrder to false (disabling it), you set the
> servers preference. It now becomes the server operator's
> responsibility to configure the ciphersuites correctly, which gets
> into the issues you were wanting to avoid.

Reading apache doc tells me the opposite:
"When choosing a cipher during an SSLv3 or TLSv1 handshake, normally the
client's preference is used. If this directive is enabled, the server's
preference will be used instead."

Apologies, worded poorly on my part.

SSLHonorCipherOrder on == Use the server's preference

SSLHonorCipherOrder off == Use the client's preference (default)

 

> As Rich said, have you observed this in practice and looked into why?

I have on my own servers and as I already wrote you can on
see it on www.openssl.org.

Having tested with not setting SSLHonorCipherOrder however causes other
issues - some other browsers won't use FS ciphers then (notably some
older IE versions and all mobile IEs - at least that's what the ssl labs
test says).

To reiterate the above said, I have two apache configs:
SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH

Result: GCM in chrome/ff, but no FS in many IE versions (and A- on ssl
labs).

SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH

Result: no GCM in chrome/ff, but FS in all ssl labs reference browsers
(and A+ rating).

Correct, if you're going to set SSLHonorCIpherOrder to "on", then you need a better SSLCipherSuite flag. Upthread includes Mozilla's recommendations for server configurations.

As it relates to OpenSSL, the question is whether "HIGH" should also set some form of implicit priorities. Currently, it uses a mask in https://github.com/openssl/openssl/blob/master/ssl/ssl_ciph.c

In particular, examine https://github.com/openssl/openssl/blob/master/ssl/ssl_ciph.c#L1504 and below to see how the list is constructed. But that's an OpenSSL + deployment issue more than a browser issue. The issue as you presented it - that browsers are preferring 256-CBC over 128-GCM - is not correct for at least two browsers. IE (or at least IE9) does, and also prefers RSA over ECDSA, but I can't speak for Microsoft or if it's changed in the latest IE/Windows versions.

[David Benjamin]

On Tue Dec 16 2014 at 9:29:50 PM Ryan Sleevi <rsl...@chromium.org> wrote:

As it relates to OpenSSL, the question is whether "HIGH" should also set some form of implicit priorities. Currently, it uses a mask in https://github.com/openssl/openssl/blob/master/ssl/ssl_ciph.c

In particular, examine https://github.com/openssl/openssl/blob/master/ssl/ssl_ciph.c#L1504 and below to see how the list is constructed. But that's an OpenSSL + deployment issue more than a browser issue. The issue as you presented it - that browsers are preferring 256-CBC over 128-GCM - is not correct for at least two browsers. IE (or at least IE9) does, and also prefers RSA over ECDSA, but I can't speak for Microsoft or if it's changed in the latest IE/Windows versions.

Specifically, the ordering comes from OpenSSL doing a strength sort at the end, so it defaults to preferring 256-bit ciphers over 128-bit ciphers over all other criteria. If OpenSSL is willing to change such things, tweaking the default cipher order may be worthwhile. We switched our defaults in BoringSSL to this for Chrome[1]:

https://boringssl.googlesource.com/boringssl/+/master/ssl/ssl_ciph.c#1034

One reason NSS-based clients advertise 256-CBC but not 256-GCM is because 256-GCM changes the PRF to SHA-384, and NSS doesn't implement a SHA-384-based PRF. See https://bugzilla.mozilla.org/show_bug.cgi?id=880543#c9
BoringSSL doesn't have this limitation, but we currently disable those ciphers in BoringSSL Chrome ports too.

David

[1] Well, I'd forgotten until just now to explicitly order ECDHE_ECDSA vs ECDHE_RSA, so that's slightly ahead of currently shipping BoringSSL Chrome ports.

[ianG]

Right. It's a totally ridiculous goal. The only people who have a
handle on these differences are the ones who get deeply into the issue,
and anyone who's a server admin doesn't typically have the time for that
(although I agree it's a fun hobby).

Specialisation is a characteristic of advanced society for a reason.

> b) OpenSSL changes so that it considers GCM-modes always more secure
> than CBC modes and sorts them to the front.
> c) Browsers could start supporting AES-256-GCM
> d) Browsers could stop supporting AES-256-CBC

Those three are fiddling at the edges. Maybe useful in the short term,
but a more systemic solution is desirable.

e) Future versions of TLS should establish a single suite that is secure
in the minds of the designers. They should stamp their own credibility
as being higher than the sysadms in this area.

http://iang.org/ssl/h1_the_one_true_cipher_suite.html

It should be noted that there are many arguments against the notion that
there should only be one suite in a given protocol. Most or all of them
fail to stand up to scrutiny as they are more responsive of the
popularity of the choice-paradigm from decades past.

> Each of these would solve the issue, they don't exclude each other
> (in theory you could do all of them). I feel b) should happen anyway
> and probably one of c) or d). If browsers feel AES-128 is "good enough"
> they could just remove AES-256 support completely. If they feel they
> want AES-256 in the unlikely case that attacks against AES improve by a
> great margin then there is no reason not to support AES-256-GCM. It
> feels illogical to support AES-256, but only in its less secure mode.

:) There are no clear answers once the question is framed as "choice".

iang