[BlueOnyx:17536] Re: CBC ciphers

[Matt James]

Hi Michael,

As always, an incredibly in-depth and educational response.  Based on the limited time working with super-strict security audits, it’s my sense that they feel the need to flag anything possible (even really crazy things that don’t matter) to make the case for their fees.  I get it — if you audit a server in one pass and everything gets fixed, but the audits are recurring every few months and you continue to have a “blank” list, it might make the client think “Why am I doing this, again?”.

So, my general sense is that this is what’s going on here.  It’s not that they’re lying or anything.  It’s just that they have to sort of chase the dragon of vulnerabilities.

In any case, this recommendation was made in the “informational” category of fixes, so I think we have solid ground to put forward ignoring the recommendation.

Thanks for everything, Michael!

-Matt

> On May 7, 2015, at 1:37 PM, Michael Stauber <mstauber at blueonyx.it> wrote:
> 
> 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
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx