TLS 1.3: Warum der Handshake schneller ist — und 0-RTT Grenzen hat

Eine Runde weniger

Bei einem vollständigen TLS-1.3-Handshake sendet der Client seine unterstützten Parameter und einen Schlüsselaustausch direkt im ersten ClientHello. Der Server kann darauf mit seiner Auswahl, seinem Schlüsselanteil und den verschlüsselten Authentifizierungsnachrichten antworten. Nach einer Hin- und Rückrunde stehen damit gemeinsame Sitzungsschlüssel bereit.[1]

Der Geschwindigkeitsgewinn ist deshalb besonders auf Verbindungen mit hoher Laufzeit sichtbar. Er ersetzt allerdings keine gute Netzqualität: Paketverlust, DNS-Aussetzer oder ein langsamer TCP-Aufbau bleiben auch unter TLS 1.3 spürbar.

Was Session Resumption verändert

Nach einer erfolgreichen Verbindung kann ein Server ein Sitzungsticket ausstellen. Bei einer späteren Verbindung lässt sich dieses Ticket als vorab geteilter Schlüssel verwenden. Dadurch muss nicht jedes Mal die komplette Zertifikatsprüfung mit einem neuen vollständigen Handshake wiederholt werden.

TLS 1.3 behält beim normalen Wiederaufnahme-Handshake einen frischen Schlüsselaustausch bei. Das sorgt dafür, dass das spätere Bekanntwerden eines Sitzungsschlüssels nicht automatisch ältere Sitzungen entschlüsselt.

0-RTT ist kein kostenloser Turbo

Im optionalen 0-RTT-Modus darf ein Client bei einer Wiederverbindung bereits mit dem ersten Paket verschlüsselte Anwendungsdaten senden. Das spart eine weitere Runde, aber diese frühen Daten besitzen laut TLS-1.3-Spezifikation schwächere Sicherheitseigenschaften als reguläre 1-RTT-Daten. Insbesondere können Angreifer aufgezeichnete 0-RTT-Nachrichten erneut an den Server senden.[1]

Server müssen deshalb selbst entscheiden, ob sie 0-RTT überhaupt akzeptieren, und benötigen bei Aktivierung eine Strategie gegen Replays. Für viele Anwendungen ist ein sauberer 1-RTT-Handshake die vernünftigere Voreinstellung.

Was man tatsächlich messen sollte

Eine einzelne „TLS-Zeit“ sagt wenig aus. Sinnvoll ist die getrennte Betrachtung von DNS-Auflösung, TCP-Verbindungsaufbau, TLS-Handshake und Zeit bis zum ersten Byte. Erst dann wird sichtbar, ob Optimierung am Protokoll hilft oder ob die eigentliche Ursache im Netzwerkpfad liegt.

Für einen realistischen Vergleich sollten mehrere Verbindungen gemessen werden. Neben dem Mittelwert ist ein hohes Perzentil wie P95 wichtig, weil sporadische Timeouts und Paketverluste dort deutlich werden, selbst wenn die meisten Verbindungen schnell sind.