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

[Hanno Böck]

On Mon, 15 Dec 2014 18:07:15 -0800
Ryan Sleevi <rsleevi at 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 at 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 at 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: 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/66f9f9a4/attachment-0001.sig>