[openssl-dev] 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 at 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: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.opensslfoundation.net/pipermail/openssl-dev/attachments/20141216/ed337990/attachment.sig>