[BlueOnyx:17194] Re: 'FreakAttack' OpenSSL vulnerability?

[Michael Stauber]

Hi Ralf,

> http://it.slashdot.org/story/15/03/03/2036241/freak-attack-threatens-ssl-clients

When the Crypto-Crisis began with the Snowden revelations we took a long
and hard look at the encryption mechanisms in various BlueOnyx services
- on all BlueOnyx versions past and present.

During subsequent updates we started to harden them a lot beyond the
standard pre-defined or default values that CentOS or SL ship with.

This included the disabling of all weak protocols for all relevant
services and making sure that the strongest possible ciphers and
protocols are used in client/server negotiations. Only if a client
doesn't support the strongest possible protocols and ciphers, a fallback
to the next lesser protocol or ciphers is allowed.

But: Even then we only allow to fall back to things that are still
considered secure. If a fallback to weak and no longer supported
protocols or ciphers is requested, then we deny the communication.

Which means:

Protocols:
==========

- SSLv3, SSLv2 and SSL(v1) are disabled. No exceptions allowed.
- TLSv1.2, TLSv1.1 and TLSv1.0 are allowed. Newest one preferred.

Ciphers:
========

Not all services support all ciphers. So what's actually used where
depends on the services. We oriented ourselves on the guidelines set out
by https://bettercrypto.org/ and https://ssllabs.com/, which are beyond
reproach or doubt and enjoy a good community review.

Some minor compromises had to be made, because RedHat probably got
clubbed over the head with a "National Security Letter" from a certain
fascist government or other and disabled most elliptic curve algorithms
in EL6's OpenSSL and has not been forthcoming to enable all of them
again. They state "copyright reasons" that nobody else who ships OpenSSL
as well does have any problem with. Go figure.

So what does this mean in practical terms:

BlueOnyx 5106R on CentOS 5:
============================

The encryption in it is pretty much FUBAR. The OpenSSL in CentOS5 is
darn ancient. It supports at best TLSv1.0 and none of the elliptic curve
stuff is included in a usable fashion. We buttoned it down as good as we
could, but it's not ideal. The only good part: The OpenSSL on it is so
old, that it's not susceptible to some of the attack vectors that are
circulating.


BlueOnyx 5107R, 5207R, 5108R and 5208R on EL6, CentOS 6 or SL 6:
=================================================================

As said above: RedHat crippled the OpenSSL in it. Only with v6.6 and
onwards some elliptic curve algorithms made it back into OpenSSL, but
they are the weaker ones of the crop. TLSv1.2, TLSv1.1 and TLSv1.0 are
available and wherever applicable and possible Forwarding Secrecy is
used and strongest ciphers are preferred in the negotiations.

As far as HTTPS goes, take a look at this:

https://www.ssllabs.com/ssltest/analyze.html?d=5108r1.smd.net&latest

That's run against a 5108R with a self signed certificate and if it were
a real certificate, it would get an A-. Which is as good as it gets on
EL6 if you still want to accept connections in the most secure fashion
from most modern browsers. A straight "A" would only be possible if we
allow some browsers to use weaker stuff. Which is a compromise I won't take.

The email services are hardened in a similar fashion and likewise we get
pretty good results there, too.


BlueOnyx 5209R on EL7, CentOS 7 or SL 7:
=========================================

The included OpenSSL is a bit newer, but still shows that the guys with
the red hat bend over backwards (and lowered their pants) to appease
"the powers that be" to remove some Elliptic Curve ciphers.

We use the same optimization tweaks for ciphers and protocols on 5209R
that we use on EL6, which produces similarly good and very robust
results as far as hardening goes.


Applicability for the 'FreakAttack' exploits?
=============================================

The 'FreakAttack' is only possible via a man-in-the-middle-attack. So
you got your "friendly" (or hostile) three letter agency (domestic or
foreign) tapping your switching box in the street, or they have tapped
into the copper or fiber somewhere along the line or get the data spoon
fed by the telcos or by "renting" space in DECIX, MAE-EAST or other
national exchanges. So they see every bit and byte that flows either way
- encrypted or not.

Those who can receive can send as well. So they can send packets of
their own during the negotiation (or afterwards) and can try to
negotiate a protocol and cipher that they can crack more easily. Like
the RC4 cipher, which has been so thoroughly rooted that it's worthless.
We don't allow any algorithm that is based on RC4. We also don't allow
the horrible "Export" or "MD5" stuff that is still included in OpenSSL.
Much of what we still allow falls into combinations of Elliptic Curve,
Diffie Hellman, AES, CBC, GCM and various forms of SHA (preferably
SHA256) for hashing.

Some combinations of those are better or worse than others for various
reasons. Especially anything from Microsoft has problems with the stuff
that's considered more secure. Also newer Android versions (4.4.2 or
newer) don't support Forwarding Secrecy with the best possible ciphers,
nor do they support Elliptic Curve algorithms in that mix. Go figure. US
companies. Why are we not surprised?

So yes: Via a man-in-the-middle attack our protocols and ciphers can
still be "downgraded". But just a notch or two. We don't allow anyone to
downgrade them beyond what's still considered "safe" at this time.

If it is *still* "safe" enough? Who knows? But it's the best we can do.
Especially considering that we're not playing on a level playing ground
and are fighting this fight against oppressive, manipulative and fascist
governments and their unregulated and unsupervised GESTAPO
stormtroopers. Worse: They have the "don't be evil" guys in their
pockets, too and force them to cripple the security architecture that
this net of ours depends on.

Which is where we come back full circle: If you got such a three letter
agency tapping your communication, then all bets are off anyway. The
next time any piece of software says it wants to update, then who or
what guarantees that the update is legitimately coming from the source
it comes from and hasn't been tampered with along the way? Sure, it
might be signed, checksummed or whatever else ... but it's only as
strong as the weakest link. Which might be the Windows box in the same
network.

Technically: We did what we could. But *this* problem can't be helped
with through technical solutions, hotfixes or tweaks. It needs either a
political solution or a bloody revolution.

TL;DR:
======

It's FUBAR, but we dealt with it as best as we could manage. Now go vote
and don't make your cross for the same corrupt fascist-junta that got us
into this vexatious twattery. :o)


P.S.: Daily goal achieved. Managed to casually insert a lovely and
freshly learned English expletive into a technical/political discussion. \o/

-- 
With best regards

Michael Stauber