

OpenSSL Ciphersuite Downgrade Vulnerability Announcement - tptacek
http://www.openssl.org/news/secadv_20101202.txt

======
tptacek
I don't have a bead on how serious this is.

OpenSSL contains a workaround for a bug in old versions of Netscape Server,
which workaround most servers will enable by default by specifing SSL_OP_ALL
when initializing the library.

SSL has sessions that can be resumed by connections after the first, which
allow clients and servers to bypass the most expensive part of negotiation and
instead reuse a previous handshake to rekey a new one. This is the most clunky
part of SSL, and was responsible for a very serious SSL protocol flaw last
year, but apparently it offers a (very) non-negligible performance win in the
real world.

The old Netscape bug was that it had broken behavior when picking ciphers
during the handshake of a resuming session. You don't care about the details.
What you care about is that by default, OpenSSL's session resumption code
apparently has a workaround for an ancient bug that allows clients to bypass
the server's policy for acceptable ciphersuites.

You care about that because there are some terrible old ciphersuites compiled
into older versions of OpenSSL. I'm not clear on whether this means an
attacker can resume someone _else's_ session with weak ciphersuites (which
would be terrible but seems unlikely since session resumption is
authenticated) or whether it just means a client can "fake out" a server into
establishing a weak SSL session.

There's a very cool _other_ bug in this advisory which does't matter but is
more fun to talk about.

OpenSSL contains J-PAKE, which I had to look up what that is and apparently
what it is is J-PAKE is an alternative to SRP for crypto-safe password
authentication designed in part to avoid the patent encumbrance of SRP.

Both SRP and J-PAKE use number theory in much the same way as Diffie-Hellman.
The core algorithm is based on the idea that two parties can carry out a
computation by exchanging publicly-readable derivatives of privately-held
numbers[1], and the result of that computation can only be feasibly be known
by the two parties. The innovation in SRP is _very_ simple: it's that you can
"mix in" a password into a DH exchange (by using a hash to derive a number
from the password). P-JAKE is similar.

A very well-known flaw in DH and SRP implementations exploits the fact that
the whole "algorithm" is really just a simple math problem involving
multiplication. The flaw is, an attacker (a man-in-the-middle in the DH case,
a malicious client in the SRP case) sends 0 (or 0 mod p, of which there are
obviously infinite 0 mod p variants). N * 0 = 0; the results of the simple
math problem underpinning DH and SRP become known to the attacker, and the
whole thing falls apart.

(This is a _devastating_ flaw in SRP implementations, which I've found in 3
different products now[2] which lets you log into SRP-speaking servers without
a password).

And long story short OpenSSL J-PAKE has a very similar problem and is totally
broken but you hopefully don't care because you'd have to be crazy to use
OpenSSL's not-compiled-by-default expirimental driver for an expirimental
replacement to an exotic password authentication protocol in your product.

Yay crypto!

[1] _(in the case of DH, the public parameter is a large number raised to a
power modulo a large prime)._

[2] _(which in fairness I learned from Nate Lawson and/via Trevor Perrin)_.

~~~
NateLawson
I believe it allows a MitM attacker to force a client to downgrade their
ciphersuite. This is bad in HTTPS or other SSL environments with short-lived
connections because it gives attackers a lot of chances to play this game.

The J-PAKE flaw is similar to those SRP bugs, yes. OpenSSH had the same
problem. Sebastien Martini is doing some great work rooting out crypto flaws
in widely-used open-source software.

