TLS 1.3

Hanno Böck
https://hboeck.de

Vorstellung

Hanno Böck

Schreibe regelmäßig für Golem.de und andere, veröffentliche monatlichen Bulletproof TLS Newsletter.

Fuzzing Project - unterstützt von der Core Infrastructure Initiative der Linux Foundation.

Nebenher: Administrator bei kleinem Webhoster schokokeks.org.

Ein Blick zurück

BEAST-Angriff (2011)

Source

BEAST

Angriff auf CBC-Verschlüsselung in TLS 1.0 und SSL 3.

TLS 1.1/1.2 nicht betroffen, aber damals paktisch nicht in Verwendung.

Padding Oracle

Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS... Vaudenay (Eurocrypt 2002)

Hintergrund CBC/HMAC

TLS: Verschlüsselung und Authentifizierung

TLS wurde lange Zeit üblicherweise mit AES im CBC-Modus und HMAC verwendet

MAC-then-Pad-then-Encrypt

([Plaintext][MAC][Padding])Encrypt

TLS Padding

0x00

0x01, 0x01

0x02, 0x02, 0x02

0x03, 0x03, 0x03, 0x03

TLS 1.0 / 1.1 Error alerts

bad_record_mac

decryption_failed

CBC Decryption

CBC Padding Oracle

TLS 1.2 (RFC 5246)

Canvel et al. [CBCTIME] have demonstrated a timing attack on CBC padding based on the time required to compute the MAC. [...] This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable [...].

Lucky Thirteen (2013)

Timing-Variante von Vaudenay-Angriff trotz Gegenmaßnahmen.

Schwer zu vermeiden, später weitere Varianten (Lucky Microseconds).

Fix in OpenSSL führte zu weiterem Padding-Problem.

RC4

2013: Erster Angriff auf RC4 in TLS, seither mehrere verbesserte Angriffe.

2015: RFC 7465, Prohibiting RC4 Cipher Suites

SSL ist tot

SSLv2 DROWN

SSLv3 POODLE

Dank Downgrade- und Cross-Protokoll-Angriffen selbst dann ein Risiko, wenn diese Versionen überhaupt nicht verwendet werden.

TLS nach Lucky13 und RC4-Angriffen

	CBC	RC4	GCM
TLS 1.0	unsicher	unsicher	n/a
TLS 1.1	unsicher	unsicher	n/a
TLS 1.2	unsicher	unsicher	sicher

GCM (RFC 5288 / TLS 1.2)

Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number.

Doppelte Nonces bei GCM

Eine kleine Zahl von Servern (184) nutzt doppelte Nonces.

Ca. 70.000 Hosts mit zufälligen Nonces (geringes Risiko).

Allerdings: Alles Implementierungsfehler, korrekte Implementierungen nicht betroffen.

Nonce-disrespecting Adversaries (Böck et al)

Was bleibt?

Nur GCM-Modi in TLS 1.2 sind nicht kryptographisch gebrochen.

Entwicklung startete 2014, inzwischen 20 Entwürfe.

Zahlreiche Implementierungen bereits verfügbar.

Verabschiedung in Kürze.

Forward Secrecy

Früher zwei Möglichkeiten für Generierung des Session-Schlüssels: RSA-Verschlüsselung und Schlüsselaustausch (Diffie Hellman oder Elliptic Curve Diffie Hellman).

Nur der Schlüsselaustausch bietet Forward Secrecy.

RSA-Verschlüsselung sowieso sehr fragil (Bleichenbacher-Angriff).

TLS 1.3 und Forward Secrecy

RSA-Schlüsselaustausch fliegt raus, Forward Secrecy nicht mehr optional.

Und dann waren da noch die Banken...

Vertreter von Banken-Verband BITS bittet im September 2016 darum, den unsicheren RSA-Schlüsselaustausch beizubehalten (wg. passivem Überwachungsequipment).

Antwort von Kenny Paterson

My view concerning your request: no.

Rationale: We're trying to build a more secure internet.

Meta-level comment:

You're a bit late to the party. We're metaphorically speaking at the stage of emptying the ash trays and hunting for the not quite empty beer cans.

More exactly, we are at draft 15 and RSA key transport disappeared from the spec about a dozen drafts ago. I know the banking industry is usually a bit slow off the mark, but this takes the biscuit.

Nur noch authentifizierte Verschlüsselung

TLS garantiert Verschlüsselung und Authentifizierung.

SSL/TLS nutzte meistens CBC/HMAC in der fragwürdigen Kombination MAC-then-Encrypt (Padding Oracles).

Authentifizierte Verschlüsselung: Verschlüsselungsmodi, die Verschlüsselung und Integrität kombinieren (GCM, Poly1305).

Kompression raus

CRIME-Angriff nutzte TLS-Kompression.

Problem nicht gelöst: Kompressionsangriffe funktionieren auch mittels HTTP-Kompression (BREACH, TIME, HEIST).

Weitere Änderungen

RSA-PSS statt PKCS #1 1.5 (Bleichenbacher Signature Forgery, BERserk).

MD5, SHA1 raus (SLOTH).

Keine frei wählbaren elliptischen Kurven und Diffie-Hellman-Gruppen (Logjam)

Renegotiation raus (Triple Handshake).

Neue Berechnung Pre-Master-Secret (Triple Handshake).

Client-Zertifikate

Bisher wurden Client-Zertifikate unverschlüsselt übertragen (Privacy).

TLS 1.3 verschlüsselt Client-Zertifikate.

Ciphersuites

Ciphersuite alt: ECDHE-RSA-AES128-GCM-SHA256

Ciphersuite neu: AES128-GCM-SHA256

Key Exchange wird unabhängig davon gewählt.

Optimierter Handshake

Quelle: Filippo Valsorda, Nick Sullivan, Cloudflare

0-RTT

Bei vorhandemen Pre-Shared-Key von voriger Verbindung können unmittelbar im ClientHello verschlüsselte Daten mitgeschickt werden.

Probleme mit 0-RTT

Replay-Angriffe.

Seitenkanalangriffe.

0-RTT

Aus Performance-Sicht wünschenswert, aber mit vielen Risiken verbunden.

0-RTT erfordert detailierte Kenntnisse über die Applikationslogik, darf nicht per default genutzt werden.

0-RTT und HTTPS

HTTP-GET-Requests müssen idempotent sein (dürfen auf dem Server keine Änderungen hervorrufen).

Versionsnummer

TLS hat ein extrem komplexes Versionsaushandlungsverfahren.

TLS-Versionsaushandlung

Client schickt ClientHello mit maximal unterstützter TLS-Version.

Falls Server diese nicht unterstützt antwortet er mit niedrigerer, maximal unterstützter TLS-Version.

Beispiel Versionsaushandlung

ClientHello mit TLS 1.2

Server unterstützt nur TLS 1.0, daher:

ServerHello mit TLS 1.0

Anschließend: Verbindung mit TLS 1.0.

Extrem komplex?

Naja...

Zumindest zu komplex für Cisco, IBM, Citrix und zahlreiche andere Hersteller.

Version Intolerance

ClientHello mit TLS 1.2

Server unterstützt nur TLS 1.0, daher...

Absturz, Verbindungsabbruch, TLS-Alert, ...

Fallbacks

Da es zu viele defekte Server gab, die die Versionsaushandlung nicht korrekt durchführen, hatten Browser Fallbacks eingeführt.

Schlägt Verbindung mit TLS 1.2 fehl: Versuche es nochmal mit TLS 1.1, TLS 1.0, SSLv3.

Fallbacks? Ist das sicher?

Nein, natürlich nicht.

Angriffe nutzen Versions-Fallbacks: Virtual Host Confusion, POODLE.

Daher: SCSV, Mitigation für Fallbacks.

TLS 1.3 und Versionsaushandlung

Versionsaushandlung als Extension, alte Version wird auf 3.3 (== TLS 1.2) festgenagelt.

GREASE

Clients schicken gelegentlich zufällig bestimmte reservierte "GREASE"-Werte mit, um sicherzustellen, dass Server diese korrekt ignorieren.

Bei der Entwicklung von TLS 1.3 wurde mit allen Mitteln versucht, eine Kompatibilität mit defekten Legacy-Implementierungen herzustellen.

Dann gabs da aber noch Blue Coat.

Software

Unterstützung in Firefox (NSS) und Chrome (BoringSSL).

Experimentelle Unterstützung in OpenSSL (zukünftige Version 1.1.1).

[DEMO]

OpenSSL und TLS 1.3

Die aktuelle Version von OpenSSL (1.1.0, noch ohne TLS-1.3-Support) hat viele API-Änderungen.

Viel inkompatible Software.

Testet Eure Software jetzt mit OpenSSL 1.1.0.

TLS 1.3 ist nicht alles

Viele Verbesserungen in Sachen TLS haben nicht direkt mit der Protokollversion zu tun.

Certificate Transparency, HTTP Public Key Pinning, CAA-Records, SameSite-Cookies, ...

Es tut sich viel - und TLS ist heute viel sicherer als früher.

Certificate Transparency

Öffentliche Logs mit Zertifikaten.

Webinterface: crt.sh

Notification-Services: Certspotter, Facebook.

Zukunft

0-RTT aussichtsreicher Kandidat für zukünftige Sicherheitslücken.

QUIC statt TLS?

Post-Quanten-Kryptographie steht an.

TLS 1.3 kommt bald

Fragen?