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.

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

[ianG]

On 16/12/2014 01:18 am, Hanno Böck wrote:
> 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.

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