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

[Viktor Dukhovni]

On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote:

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

In which case, they will never use AES-256, and yet:

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

you claim that somehow AES-256 is used anyway.  This is simply wrong.

> Take this scenario:
> * Server operator uses apache+openssl wiht cipher string
>   "HIGH:!MEDIUM:!LOW:!aNULL at STRENGTH". This seems reasonable. Only HIGH

This is a cipherstring with great redundancy and a typo.  What you
meant was:

    DEFAULT:!EXPORT:!LOW:!MEDIUM

which is simpler and harder to screw up (subtracting from DEFAULT
is the safest approach for most users, building up from nothing is
error-prone).

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

The server chooses the client's best cipher (from client's preference
order or its own).  Not the other way around.

> What can be done to avoid this?

Since you've got the wrong end of the stick, there's not much to
discuss.

-- 
	Viktor.