Circumstances cause CBC often to be preferred over GCM modes

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Circumstances cause CBC often to be preferred over GCM modes

Hanno Böck-4
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: [hidden email]
GPG: BBB51E42

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Circumstances cause CBC often to be preferred over GCM modes

Chris Palmer
+agl explicitly, just to be sure

On Mon, Dec 15, 2014 at 5:18 PM, Hanno Böck <[hidden email]> 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.
> 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: [hidden email]
> GPG: BBB51E42
>
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumstances cause CBC often to be preferred over GCM modes

Ryan Sleevi-2
On Mon, Dec 15, 2014 at 5:25 PM, 'Chris Palmer' via Security-dev <
[hidden email]> wrote:

>
> +agl explicitly, just to be sure
>
> On Mon, Dec 15, 2014 at 5:18 PM, Hanno Böck <[hidden email]> 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.
>

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)


> >
> > 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: [hidden email]
> > GPG: BBB51E42
> >
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumstances cause CBC often to be preferred over GCM modes

Lucas Garron
In reply to this post by Hanno Böck-4
Hopefully most people on these lists know this, but I thought I'd point out
that Mozilla provides a neat TLS configuration generator
<https://mozilla.github.io/server-side-tls/ssl-config-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).

On Mon Dec 15 2014 at 5:18:43 PM Hanno Böck <[hidden email]> 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.
> 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: [hidden email]
> GPG: BBB51E42
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

RE: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes

Salz, Rich
In reply to this post by Hanno Böck-4
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: [hidden email] Twitter: RichSalz


_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes

Hanno Böck-4
On Mon, 15 Dec 2014 20:31:53 -0500
"Salz, Rich" <[hidden email]> 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
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Circumstances cause CBC often to be preferred over GCM modes

Hanno Böck-4
In reply to this post by Ryan Sleevi-2
On Mon, 15 Dec 2014 17:36:40 -0800
Ryan Sleevi <[hidden email]> 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)

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

mail/jabber: [hidden email]
GPG: BBB51E42

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Circumstances cause CBC often to be preferred over GCM modes

Ryan Sleevi-2
On Mon, Dec 15, 2014 at 6:02 PM, Hanno Böck <[hidden email]> wrote:

>
> On Mon, 15 Dec 2014 17:36:40 -0800
> Ryan Sleevi <[hidden email]> 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)
>

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.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumstances cause CBC often to be preferred over GCM modes

Hanno Böck-4
On Mon, 15 Dec 2014 18:07:15 -0800
Ryan Sleevi <[hidden email]> 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).


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

mail/jabber: [hidden email]
GPG: BBB51E42

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Circumstances cause CBC often to be preferred over GCM modes

Ryan Sleevi-2
On Mon, Dec 15, 2014 at 6:15 PM, Hanno Böck <[hidden email]> wrote:

>
> On Mon, 15 Dec 2014 18:07:15 -0800
> Ryan Sleevi <[hidden email]> 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.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumstances cause CBC often to be preferred over GCM modes

David Benjamin
On Tue Dec 16 2014 at 9:29:50 PM Ryan Sleevi <[hidden email]> 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.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Circumstances cause CBC often to be preferred over GCM modes

ianG-2
In reply to this post by Hanno Böck-4
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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security