[BlueOnyx:17535] Re: CBC ciphers

[Michael Stauber]

Hi Matt,

> One of our clients recently had an external security audit on their
> dedicated server and the security firm recommended disabling all
> cipher suites that run in CBC mode (as, apparently, we have some
> running on that server).
> 
> Is this easy to do in BlueOnyx?  We’re running 5107R here.

I'm sorry to hear you fell for a snake oil vendor. Can you still ask for
a refund?

I'm really serious about this question.

Let me walk you through a couple of things here so that you understand
the problem and can explain it to the decision makers and the client.

Encryption is a pretty complicated thing and OpenSSL provides us with a
toolbox for doing encryption in many different forms via different
mechanisms.

On BlueOnyx we rely for this on the OpenSSL that ships with the OS.

BlueOnyx 5106R:	CentOS5 - openssl-0.9.8e-33.el5_11 (at this time)
BlueOnyx 5107R:	CentOS6 - openssl-1.0.1e-30.el6_6.7 (at this time)
BlueOnyx 5207R:	CentOS6 - openssl-1.0.1e-30.el6_6.7 (at this time)
BlueOnyx 5108R:	CentOS6 - openssl-1.0.1e-30.el6_6.7 (at this time)
BlueOnyx 5208R:	CentOS6 - openssl-1.0.1e-30.el6_6.7 (at this time)
BlueOnyx 5209R:	CentOS7 - openssl-1.0.1e-42.el7.4 (at this time)

For the network facing services on BlueOnyx that use encryption (HTTPS,
FTPS, POP3S, IMAPS, AdmServ) we follow the best practices as outlined
and specified by bettercrypto.org, SSLlabs.com, heise.de and refined
that with 20 years of own experience and peer review by experts from
StackOverflow.

So please point them to this page first: https://bettercrypto.org/

The frontpage there shows how the SSL Cipher Suite should be configured.

The goal there is this:

1.) Disable SSLv1, SSLv2 and SSLv3.
2.) Force usage of best ciphers and protocols.
3.) Force browsers to prefer TLSv1.2.
4.) Prefer ciphers that provide forwarding secrecy wherever possible.
5.) Prefer elliptic curve encryption and Diffie Hellman when possible.
6.) Disable all weak protocols and ciphers.
7.) Secure against the Pootle attack.
8.) Prevent downgrading of protocols or ciphers to something unsafe.

But naturally there is a catch. Actually there are a few of them:

We must not break compatibility with browsers or email clients that are
out there and are still widely in use. And some of the older browsers
(especially anything from Microsoft) forces us to lower the bar from our
optimum to what *they* actually support as best available mechanism.

Despite that we raised our bar so high that certain really old clients
no longer will be able to connect to HTTPS on a BlueOnyx. Namely any
Internet Explorer for Windows XP will be unable to connect. Same for
certain old and exotic browsers. XP is EOL, hence we don't care.

The final catch rests with the underlying OS of BlueOnyx and the OpenSSL
library that the OS provides. The OpenSSL on CentOS5 is too old and
lacks many of the more advanced features. Worse: RedHat crippled the
OpenSSL that ships with CentOS6 and CentOS7 and they removed some of the
best elliptic curve algorithms - allegedly for copyright and license
reasons.

So this further reduces our "toolset" to a common denominator: We use
the best that *is* available and disable anything that's unsafe.

Due to the realities forced on us by the "crippled" OpenSSL, BlueOnyx
uses the following Cipher Suites (instead of the ones recommended by
bettercrypto.org) we slightly modified the parameters a bit.

With the most modern browsers we force the visitor to use this:

Firefox:
TLS1.2		TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Chrome:
TLS 1.2 	TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

IE11:
TLS 1.2 	TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Android 4.4.2:
TLS 1.2 	TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Android 5.0.0:
TLS 1.2 	TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Safari 7 & 8:
TLS 1.2 	TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

All of these support Forwarding Secrecy. As a net result the experts at
SSLlabs rate our form of SSL implementation "A-":

Protocol Support:	95%
Key Exchange:		90%
Cipher Strength:	90%

This is a good as it gets given the limitations of the OS. I am *always*
open for suggestions about how to improve this further on RedHat or
CentOS based OS's. *WITHOUT* breaking support of current and still
maintained and supported browsers or email clients.

So your "snake oil vendor" recommended to disable CBC? In that case I
invite them to show me *one* server where this is done and which *still*
gets a better rating on SSLlabs.com than we do.

Let them try. Let them show you how it's done. But I know they'll crash
and burn, because they can't.

Like anyone who has some clue about encryption I agree that among the
available block ciphers Cipher Block Chaining (CBC) is not really the
top of the crop. Hey, it was invented by IBM in 1976, so it had it's
run. But it is still the most commonly used mode of operation and
(sadly) the weaknesses of CBC have been exploited in the POODLE attack.
But there always were other contributing factors that made this
possible. Factors, which don't exist in our form of implementation.

So you can't look at CBC here alone. You have to look at the protocols,
the encryption, the padding and the presence or absence of Forwarding
Secrecy as a whole.

And *THEN* you realize:

a.) Despite some browsers still using "something CBC related" we're not
the least bit vulnerable to Pootle.

b.) We're not vulnerable to forced protocol downgrading in a way that we
eventually get vulnerable.

c.) Forwarding Secrecy provides additional security for all half way
modern browsers.

d.) Wherever possible we use elliptic curve and/or Diffie Hellman.

e.) Everything (except a few ancient browsers) is forced to use TLSv1.2.


Bottom line and TL;DR for the management:
=========================================

Our usage of CBC does *not* make SSL on BlueOnyx the least bit more
vulnerable.

To the contrary: If we disable CBC we downgrade 80% of the still
supported browsers to use ciphers without elliptic curve and/or Diffie
Hellman and therefore fall back to more easily circumvented ciphers.

So disabling CBC lowers our resilience tremendously.

Hence we neither will do it, nor would we suggest to do so.

-- 
With best regards

Michael Stauber