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 _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx