SSL/TLS Security

I'd like to give a small update on the SSL situation on BlueOnyx. It's just a FYI and to let you know about some of the thought processes of behind our constant attempts to stay on the forefront of providing secure SSL/TLS on BlueOnyx.

The Mozilla Foundation has released their "Observatory" toolset as open source. Previously they used it internally to check the security of their own websites and the SSL implementation of their web services.

I used the form at that URL to test a few SSL enabled websites on 5207R/5208R and 5209R to see if there would be any recommendations that we might want to follow to improve our security.

There is also a Mozilla SSL Configuration Generator which can be used to generate "safe" SSL configurations for various web server and their subversions.

So for shit and giggles I tried it out for 5209R. I selected "Apache", Server Version 2.4.6 (the one we use on 5209R) and selected "Modern". I also tried "Intermediate".

I then implemented the resulting SSL configurations on a 5209R and then checked the results both through the Mozilla "Observatory" and via the Server Check on SSLlabs. And I trust SSLlabs a hell of a lot more.

My findings:

In pretty much all modern browsers (Firefox, Chrome, IE11) the resulting ciphers then use TLS_ECDHE_RSA (Elliptic curve) and default to using "secp256r1". This is an elliptic curve algorithm that was developed by NIST. The "r" in it defines it as "random", opposed to "secp256k1", which uses predefined Koblitz-Curves. Bitcoin for example uses "secp256k1".

The problem with the supposedly more random "secp256r1" curve is this: It's not clear how many random parameters influenced the outcome. So the entropy is a more than a bit dubious to say the least. What's clear is that the "secp256r1" uses the seed of "c49d360886e704936a6678e1139d26b7819f7e90", pushes it through SHA-1 and that influences the domain parameters that eventually are used.

The key problem with "secp256r1" is that the NSA selected the seed. It's also called the "NIST P-256" curve in other documentation. It's pretty much "industry standard" these days and unless you forego elliptic curve encryption entirely it'll be the most accepted choice. The safety of it depends largely on your believe in the altruism of the NSA. Did they really do us a favour and select the seed that generates the hardest to crack encryption? Or the one that's easiest for them to subvert? Your guess on that is probably as good as mine.

Bruce Schneier and Dan J. Bernstein specifically warned against using "secp256r1" and this forum message here has a good summary of what both said.

Daniel J. Bernstein said:

The possibility of attackers manipulating standard curve choices was raised in the late 1990s, when NSA volunteered to "contribute" elliptic curves to the committee producing ANSI X9.62. NSA did in fact end up producing various elliptic curves later standardized by ANSI X9.62, SEC 2, and NIST FIPS 186-2; these curves were subsequently deployed in many applications.

In response to NSA's contributions, ANSI X9.62 developed "a method for selecting an elliptic curve verifiably at random", and a procedure to "verify that a given elliptic curve was indeed generated at random"; it even claims that this procedure "serves as proof (under the assumption that SHA-1 cannot be inverted) that the parameters were indeed generated at random". However, this procedure does not verify randomness; it verifies only that the curve coefficients were produced as SHA-1 output. The claimed "proof" is nonexistent. The ANSI X9.62 curve-generation method is not trivially manipulatable but it is manipulatable.

IEEE P1363 copied the same curve-generation method and stated that it allows "others to verify that the curve was indeed chosen pseudo-randomly". However, "pseudo-random" is not the same as "random", and does nothing to stop a malicious curve generator from searching through many choices of seeds. NIST correctly characterized the verification procedure for these curves as merely checking "that the coefficient b was obtained from s via the cryptographic hash function SHA-1.

It gets even better:

The NSA themselves moved towards deprecating "secp256r1" as Matthew Green so eloquently mentioned on Twitter.

In his article "A Few Thoughts on Cryptographic Engineering" he puts it this way:

In other words, Koblitz and Menezes are saying that if you accept the weak curve hypothesis into your heart, the solution is not to replace the NIST elliptic curves with anything at all, but rather, to leave the building as rapidly as possible and perhaps not shut the door on the way out. No joke.

Additionally this website has some more information about which curves are safer than others.

Conclusion:

There is no good answer to this. On CentOS 7 based BlueOnyx 5209R we're "hobbled" in so far that the shipped OpenSSL has been "crippled" by RedHat. For "patent reasons" they stripped out all elliptic curves but the ones from the "NSA Suite B". When you try to adhere to established industry standards or to RFC5430, then you pretty much end up with P-256, P-384 or P-521 of the "NSA Suite B". Other choices (assuming an uncrippled OpenSSL) are not as commonly accepted. The only compromise might indeed be to "shut the door on the way out" and fall back to DHE_RSA with Diffie-Hellman > 1024 Bit instead of using elliptic curves.

In the longer haul we might want to ship BlueOnyx 5209R with a separate OpenSSL-1.1.0 or 1.0.2h and compile all relevant network services against that. Development towards that end is currently being carried out and is in the early stages of testing.