Handshake mit einem oder mit null Round-Trips

Der Handshake von TLS erforderte bisher zwei volle Round-Trips, bevor Daten gesendet werden können. TLS 1.3 optimiert den Protokollverlauf und verhindert dabei einen kompletten Round-Trip. Bei der ersten Verbindung mit einem TLS-Host können also deutlich früher Daten gesendet werden. Das Single-Round-Trip-Verfahren dürfte jenseits der Sicherheitsgewinne einer der größten Anreize sein, TLS 1.3 zu implementieren.

TLS 1.3 sieht auch eine noch schnellere Variante vor, ein Zero-Round-Trip-Verfahren (0-RTT), mit dem der Client direkt Daten an den Server schicken kann. Dieses Zero-Round-Trip-Verfahren funktioniert nur, wenn Server und Client bereits vorher eine Verbindung aufgebaut haben. Der Verbindungsschlüssel wird dabei aus dem Schlüssel der vorigen Verbindung berechnet.

Neue Angriffe durch Zero-Round-Trip-Handshake?

Doch dieses 0-RTT-Verfahren hat auch Bedenken hervorgerufen, es könne Replay-Angriffe ermöglichen. Denkbar wäre etwa eine Situation, in der ein Server eine bestimmte Aktion auf Anweisung eines Clients durchführt, etwa einen Geldtransfer. Ein Angreifer könnte das Datenpaket für diese Aktion mitlesen und erneut an den Server schicken - und somit die Aktion mehrfach ausführen.

Um solche Replay-Angriffe zu vermeiden, darf das Zero-Round-Trip-Verfahren nur für Aktionen eingesetzt werden, die den Status auf dem Server nicht ändern. Unproblematisch ist es etwa für normale Webseitenabrufe, bei denen der Client nur Daten anfordert, aber dem Server nichts mitteilt. Doch damit dies korrekt funktioniert, muss die Applikationslogik mit der TLS-Implementierung kommunizieren und entsprechend unterschiedliche Anfragen unterschiedlich behandeln. Das widerspricht der Idee, TLS als separaten Layer zu betrachten, der auf bestehende Protokolle aufgesetzt werden kann.

Bei allen Protokollen und Applikationen, die eine solch enge Verzahnung von TLS und Applikationslogik nicht gewährleisten können, sollte man auf den Zero-Round-Trip-Handshake trotz der Performancevorteile besser verzichten.

Formale Verifikation hilft beim Protokolldesign

Eine ganze Reihe der TLS-Angriffe, die in den vergangenen Jahren veröffentlicht wurden, geht zurück auf ein Team des Kryptographen Karthik Bhargavan, der am französischen Forschungsinstitut Inria das Prosecco-Team (Programming Securely with Cryptography) leitet.

Die Forscher von Inria haben in den vergangenen Jahren das TLS-Protokoll mit formalen mathematischen Methoden analysiert und konnten bestimmte Sicherheitseigenschaften beweisen. Außerdem erstellten sie eine formal verifizierte Implementierung namens miTLS in der Programmiersprache F#. Die Inria-Forscher waren permanent an der Diskussion um TLS 1.3 beteiligt und analysierten das Design des neuen Protokolls, um die bekannten Angriffe zu verhindern.

Diese Arbeiten führten etwa dazu, dass künftig mehr Daten des Handshakes signiert werden. Außerdem wurde die Berechnung des sogenannten Pre Master Secrets, aus dem der Sitzungsschlüssel abgeleitet wird, neu gestaltet. Hintergrund dafür war der sogenannte Triple-Handshake-Angriff.

Mit dem SLOTH-Angriff zeigten die Inria-Forscher zudem die Risiken von schwachen Hashverfahren wie MD5 und SHA-1. Der Sweet32-Angriff zeigte Schwächen des veralteten Triple-DES-Verfahrens, das mit einer kleinen Blockgröße von 64 Bit arbeitet. All diese alten Verfahren sind in TLS 1.3 nicht mehr nutzbar.