TLS 1.3: Was sich ändert und wie man es prüft
Aktualisiert 2026-11-03 · 6 Min. Lesezeit
TLS 1.3 ist die erste Protokollrevision seit einem Jahrzehnt, die Features entfernt statt hinzuzufügen. Das macht es schneller und schwerer falsch zu konfigurieren — und deshalb kann ein Server, der nur TLS 1.2 spricht, die Bestnote nicht erreichen.
Was sich gegenüber TLS 1.2 geändert hat
TLS 1.3 reduziert den Handshake von zwei Roundtrips auf einen, bei Wiederaufnahme auf null. Es entfernt statischen RSA- und Diffie-Hellman-Schlüsselaustausch, damit Forward Secrecy Pflicht statt Option ist. Es streicht CBC-Cipher, RC4, SHA-1 und Kompression vollständig und verschlüsselt mehr des Handshakes — inklusive des Zertifikats —, sodass Zwischenstationen weniger erfahren.
Die praktische Folge: Fast jede Altlast, die früher sorgfältige Konfiguration erforderte, ist nun unmöglich. Man kann bei TLS 1.3 nicht versehentlich eine schwache Cipher aushandeln, weil das Protokoll nur AEAD-Cipher mit modernen Hashes definiert.
Warum es für die Bewertung zählt
CertH verlangt TLS 1.3 für ein A+, unabhängig von allem anderen. Eine Site mit perfektem Zertifikat, starken Ciphern und HSTS bleibt ohne es bei 95 und einem A. Diese eine Zeile ist der häufigste Grund, warum eine gut betriebene Site bei A stehen bleibt.
Der zweite Grund ist der Handshake selbst. Bei hoher Latenz auf Mobilfunk bedeutet ein gesparter Roundtrip je neuer Verbindung Dutzende bis Hunderte Millisekunden — ein direkter, messbarer Effekt auf die wahrgenommene Geschwindigkeit.
Aktivieren
Bei nginx hängt TLS-1.3-Unterstützung von der OpenSSL-Version ab, gegen die das Binary gebaut wurde. OpenSSL 1.1.1 oder neuer ist nötig; prüfen Sie mit nginx -V auf die Zeile built with OpenSSL, bevor Sie etwas ändern.
Bei Apache genügt SSLProtocol, solange httpd gegen ein modernes OpenSSL gelinkt ist. Bei Cloudflare ist TLS 1.3 ein zonenweiter Schalter unter SSL/TLS → Edge Certificates und seit 2021 für die meisten Zonen standardmäßig aktiv.
# nginx: does this binary even support TLS 1.3?
nginx -V 2>&1 | tr ' ' '\n' | grep -i openssl
# negotiate TLS 1.3 explicitly and print the protocol
openssl s_client -connect example.com:443 -tls1_3 -servername example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher"Die Fallstricke, die niemand erwähnt
Zero-RTT-Wiederaufnahme ist schnell, aber wiederholbar: Ein Angreifer, der den ersten Flight mitschneidet, kann ihn erneut senden. Erlauben Sie 0-RTT nie auf Endpunkten, die beim ersten Request Zustand ändern — etwa alles, was schreibt.
Manche Unternehmens-Middleboxen brechen bis heute bei TLS 1.3. TLS 1.2 parallel aktiv zu lassen ist der übliche Kompromiss: Kompatibilität bleibt, und die A+-Anforderung ist trotzdem erfüllt, weil der Grader prüft, ob TLS 1.3 angeboten wird, nicht ob TLS 1.2 abgeschaltet ist.
Schließlich verbirgt ein CDN oder Load Balancer, der TLS terminiert, das Origin vollständig. Das Origin zu ändern, ohne den Edge zu ändern, ändert nichts, was ein externer Scanner sehen könnte.
FAQ
Sollte ich TLS 1.2 abschalten, sobald TLS 1.3 läuft?
Nein. TLS 1.2 aktiv zu lassen erhält die Kompatibilität mit älteren Clients und Middleboxen und kostet keine Punkte. Es abzuschalten entfernt nur Fallback-Optionen.
Ändert TLS 1.3 meine Zertifikatsanforderungen?
Es macht einige Legacy-Algorithmen unbrauchbar. Zertifikate mit RSA-Schlüsseln sind weiterhin in Ordnung, aber die Kette muss Signaturalgorithmen verwenden, die das Protokoll erlaubt — SHA-1-Signaturen etwa sind in TLS 1.3 nicht nutzbar.