Explain Cipher Choice.

[StormTide]

The Cipher Spec listed resolves to the following on a typical OpenSSL 1.0.1g

ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES128-SHA AES128-GCM-SHA256 AES128-SHA256 AES128-SHA ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA AES256-GCM-SHA384 AES256-SHA256 AES256-SHA ECDHE-RSA-DES-CBC3-SHA ECDHE-ECDSA-DES-CBC3-SHA DES-CBC3-SHA ECDHE-RSA-RC4-SHA ECDHE-ECDSA-RC4-SHA RC4-SHA

There might be good legacy support reasons to support some of these weaker ciphers, but it would be nice to know the browser overlap/reason for support.

[AlekSi]

+1

[StormTide]

Also "We currently use OpenSSL 1.0.2-stable (+ patches)." <--- the 1.0.2 series is still in beta, (beta1+snapshots are latest current) so seems like an interesting choice for a deployed environment.

[jgrahamc]

Worth reading this: http://blog.cloudflare.com/killing-rc4-the-long-goodbye

[StormTide]

I think there's a bit of a flaw in the logic here -- newer clients aren't vulnerable, so lets support older (unpatched(unpatchable?), end of life xp, phone, etc) vulnerable clients with DES-CBC3-SHA before RC4-SHA?

Also, how are you deciding within the herd whether the clients now selecting CBC aren't vulnerable? If the patches were truly deployed you'd see a lot larger use of the GCM modes I'd think. Despite the availability of patches, sounds like this change might just re-enable the attacks that prompted the move to RC4 in the first place.

[grittygrease]

Here is the latest: https://blog.cloudflare.com/end-of-the-road-for-rc4/