Because it's not a blatant regression, it's a complicate bug that requires a custom-patched TLS stack on the server to be explocited. As Adam Langley put it:

> A test case could have caught this, but it's difficult because it's so deep into the handshake. One needs to write a completely separate TLS stack, with lots of options for sending invalid handshakes. In Chromium we have a patched version of TLSLite to do this sort of thing but I cannot recall that we have a test case for exactly this. (Sounds like I know what my Monday morning involves if not.)

Except: ensuring that the server is signing with the right, certificate-certified private key is the major thing that TLS is supposed to provide.

So no matter how strange or malicious the server-side stack would need to be... not having a test for such a deviation is a major oversight.

The really scary thing is that there is basically no good testsuite for SSL/TLS in existence. I would not be surprised if other stupid bugs showed up in other implementations given one…

This is a good example of why static analysis is so useful. Testing this in QA is a non-trivial problem but simply adding a compiler flag would report it.