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