Lucky 13.

Lucky 13 (CVE-2013-0169) wurde im Februar 2013 von Nadhem AlFardan und Kenny Paterson der Information Security Group am Royal Holloway, University of London, veroeffentlicht. Es ist eine Timing-Seitenkanal-Verfeinerung von Serge Vaudenays Padding-Orakel-Angriff (2002) und betrifft alle CBC-Suiten von SSL 3.0 und TLS 1.0–1.2 (sowie DTLS), die MAC-then-encrypt mit HMAC verwenden.

Die Zahl 13 bezieht sich auf die konstanten Bytes aus TLS-Header und Sequenznummer, die der MAC abdeckt. Da HMAC-SHA1 die Daten in 64-Byte-Bloecken verarbeitet, haengt die Anzahl der Aufrufe der Kompressionsfunktion — und damit die Pruefzeit — davon ab, wie viele Padding-Bytes der Record enthaelt. Ein Man-in-the-Middle, der gefaelschte Ciphertexts einschleust, misst diese Unterschiede im Sub-Mikrosekunden-Bereich ueber viele Versuche und erfaehrt, ob der vermutete Klartext gueltiges Padding erzeugte — und rekonstruiert so wie BEAST oder POODLE Byte fuer Byte. Die urspruenglichen Ergebnisse stellten bei DTLS vollstaendigen Klartext und bei TLS Teilbytes wieder her, demonstriert an OpenSSL und GnuTLS.

Konstantzeit-Gegenmassnahmen — stets eine feste Zahl von HMAC-Bloecken berechnen — kamen in OpenSSL 1.0.1d, GnuTLS und NSS. Die dauerhafte Loesung ist der Verzicht auf CBC zugunsten von AEAD-Suiten wie AES-GCM und ChaCha20-Poly1305, die TLS 1.3 ausschliesslich vorschreibt.

flowchart TD
  A[MITM schleust gefaelschten TLS-CBC-Record ein] --> B[Server entschluesselt und entfernt Padding]
  B --> C{Padding-Laenge}
  C -->|mehr Padding| D[Weniger HMAC-SHA1-Bloecke - schneller]
  C -->|weniger Padding| E[Mehr HMAC-Bloecke - langsamer]
  D --> F[Angreifer misst MAC-Pruefzeit]
  E --> F
  F --> G[Statistik ueber Millionen Versuche]
  G --> H[Padding-Orakel stellt ein Klartext-Byte wieder her]