TLS 1.2, for contrast — and a padding oracle that actually works

The TLS 1.2 PRF takes a secret, a label and a seed and expands them to any length, and everything — the master secret, every key, the Finished MAC — comes out of that one construction with only the label to separate the uses. It works, but it carries no proof of key separation, and the label is an arbitrary ASCII string concatenated with no structure at all. TLS 1.3 replaced it with HKDF, a two-stage Extract-then-Expand design with a structured info field, and spends a whole section of RFC 8446 deriving each secret from a value that already mixes in the previous stage.

Daniel Bleichenbacher’s 1998 attack on RSA PKCS#1 v1.5 encryption (the “million message attack”) applies directly to the TLS RSA key exchange: the client sends the premaster secret RSA-encrypted with PKCS#1 v1.5 padding, and a server that reported why a decryption failed leaked one bit about the plaintext. Repeated adaptively, that bit recovers the premaster secret and therefore the whole session. The TLS fix is to always proceed as if the decryption had succeeded — substituting a random premaster when it did not — and to keep the error path constant-time. The 2017 ROBOT work showed how many deployments had quietly reverted to a distinguishable error path. TLS 1.3’s answer was structural: delete the RSA key exchange entirely, so there is no PKCS#1 v1.5 ciphertext to attack.

BEAST (2011) exploited TLS 1.0’s implicit IV — the IV is the previous record’s last ciphertext block — to mount a chosen-plaintext attack; TLS 1.1 fixed it with an explicit per-record IV. POODLE (2014) used SSL 3.0’s padding as an oracle to decrypt a byte at a time. Lucky 13 (2013) turned the CBC MAC-then-encrypt construction’s timing into an oracle: removing the padding and checking the MAC take time that depends on the padding. DROWN (2016) used an SSLv2 server with export ciphers to break RSA key exchange even on a modern TLS 1.2 endpoint. Raccoon (2020) is not a padding bug at all: it exploits a timing difference between HMAC computations over Diffie–Hellman premaster secrets of different lengths, leaking the leading bits of the shared secret. All five share one lesson — the moment a decryption routine’s behaviour depends on secret data, the protocol leaks it — which is why TLS 1.3 permits only AEAD records and constant-time key derivation.

This page implements the classic padding-only setting: the record is PKCS#7-pad(fragment) and then CBC-encrypted, and the oracle returns only “padding ok” or “padding invalid” — no MAC is involved. That is the cleanest way to watch recovery happen byte by byte, and it is exactly the oracle POODLE exploited. Real TLS 1.2 instead uses MAC-then-encrypt, so the padding sits after a 32-byte HMAC-SHA256 and the same attack recovers that MAC along the way; this page also builds that record, to show its shape. In real TLS the receiver, having removed the padding, then checks the MAC and returns a single uniform bad_record_mac whether the padding or the MAC was wrong — and, since Lucky 13, in constant time. TLS 1.3 removes the whole class by using AEAD records, where one tag covers ciphertext, header and length and there is no padding to leak at all.

It does not implement record-layer framing, alerts, retransmission or renegotiation, and the RSA key transport demonstration uses a deliberately small 512-bit key so the arithmetic is visible — it is labelled as the shape of the mechanism, not a usable key. The PRF, the key schedule, the CBC encryption and the padding oracle are real and complete, and the oracle attack is asserted against the plaintext it was given. The PRF’s output is additionally cross-checked against an independent implementation of RFC 5246 §5 outside the browser; the page reports the result of its own checks in the badge.