Lucky 13.

Lucky 13 (CVE-2013-0169) was disclosed in February 2013 by Nadhem AlFardan and Kenny Paterson of the Information Security Group at Royal Holloway, University of London. It is a timing side-channel refinement of Serge Vaudenay's 2002 padding-oracle attack, targeting every CBC cipher suite in SSL 3.0 and TLS 1.0–1.2 (and DTLS), all of which use MAC-then-encrypt with HMAC.

The name refers to the 13 bytes of TLS header and sequence number that the MAC covers. Because HMAC-SHA1 processes data in 64-byte blocks, the number of compression-function calls — and therefore the verification time — depends on how many padding bytes the record contains. A man-in-the-middle who can inject forged ciphertexts measures these sub-microsecond differences across many trials to learn whether a guessed plaintext produced valid padding, reconstructing bytes one position at a time much like BEAST or POODLE. The original results recovered full plaintext against DTLS and partial bytes against TLS, demonstrated in practice against OpenSSL and GnuTLS.

Constant-time countermeasures — always computing a fixed number of HMAC blocks regardless of padding — shipped in OpenSSL 1.0.1d, GnuTLS, and NSS. The durable fix is to abandon CBC for AEAD suites such as AES-GCM and ChaCha20-Poly1305, which TLS 1.3 mandates exclusively.

flowchart TD
  A[MITM injects forged TLS-CBC record] --> B[Server decrypts and strips padding]
  B --> C{Padding length}
  C -->|more padding| D[Fewer HMAC-SHA1 blocks - faster]
  C -->|less padding| E[More HMAC blocks - slower]
  D --> F[Attacker times MAC verification]
  E --> F
  F --> G[Statistics over millions of trials]
  G --> H[Padding oracle recovers plaintext byte]