[BlueOnyx:20011] Re: Crypto Update

[Michael Stauber]

Hi all,

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.

See: https://observatory.mozilla.org/

I used the form at that URL to test a few SSL enabled websites on
5207R/5208R and 5209R.

There is also a Mozilla SSL Configuration Generator at this URL:

https://mozilla.github.io/server-side-tls/ssl-config-generator/

That form spits out "safe" SSL configurations for various web server and
their subversions.

So for shit and giggles I tried it out for 5209R. I configured "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.

Net result: I'm appalled, horrified and more than a little pissed at the
Mozilla Foundation.

In pretty much all modern browsers (Firefox, Chrome, IE11) the resulting
ciphers then use TLS_ECDHE_RSA (Elliptic curve) *and* default to using
"secp256r1". When I saw that, I felt like throwing something heavy
against the wall. Preferably in the general direction of the Mozilla
Foundation.

Why? Because it's fucking ridiculous to use "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 bit dubious. 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 bloody NSA selected the
seed. It's also called the "NIST P-256" curve in other documentation.

Bruce Schneier and Dan J. Bernstein specifically warned against using
"secp256r1":

http://www.heise.de/forum/Netze/News-Kommentare/NSA-Skandal-IETF-bezweifelt-Vertrauenswuerdigkeit-der-NIST/Elliptische-Kurven-auch-betroffen-c49d360886e704936a6678e1139d26b7819f7e90/posting-4078091/show/

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.
----------------------------------------------------------------

Also more information about which curves are safer than others:
http://safecurves.cr.yp.to/rigid.html

Net result: The Mozilla Foundation is either a bunch of clueless
faggots, or they are in bed with the NSA. Their recommended server
configuration defaults to cryptographic ciphers that are proven unsafe
and have been subverted by the NSA.

-- 
With best regards

Michael Stauber