Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Parent Full thread

I didn't look very hard (I just jumped to the RSA decrypt function, then found its caller, then verified its caller was part of the actual handshake code) but this code looks like it has the Bleichenbacher padding oracle (it decrypts with RSA, in P1v15 padding, and generates a direct error if that fails; with chosen ciphertexts, those errors reveal and update bounds of the private key).

Not at all sure (rather unsure) that this is practically exposed, but defenses against these kinds of attacks are why you generally want well-tested well-understood TLS implementations.

A broader critique is that this one-file TLS state machine just delegates the gnarliest bits of TLS --- most importantly X.509 and ASN.1 --- to its library dependencies.

Your assessment is correct, this code will send TLS alert packets when something goes wrong during RSA decryption otherwise it will press on. This means if you deploy this code adversaries can use your server as an Oracle to sign things with your private key even though they can't steal the key itself.

Depending on how much bandwidth the adversary can get to you, it may be practical to attack clients doing PFS because the adversary can stall them and then use your oracle to have you sign the "Yes I'm really me" message they otherwise could not make.

On the one hand, this problem doesn't make the code unsuitable for clients. On the other hand, this is not a subtle failure, this is specifically called out in the RFCs as something you need to do, so what else did they miss?

By the way people, this sort of thing is why we're always telling you that wildcard certs and having a hundred unrelated SANs in a cert are dangerous. A box labelled "Bob's toy IRC server" running this code and sharing keys with your production web server makes "Bob's toy IRC server" into a working oracle for that production web server.

You critique them for __NOT__ using well tested libraries, and then critique them __FOR__ using well tested libraries.

The first critique is a specific vulnerability, not a general comment about libraries.

No, you've misread.

Reply on news.ycombinator.com