Was ist TLS 1.3? Alles, was sich geändert hat

TLS 1.3 ist die aktuelle Version des Transport Layer Security-Protokolls, veröffentlicht als RFC 8446 im August 2018. Es ist eine grundlegende Neugestaltung — kein inkrementelles Update — die HTTPS schneller, einfacher und sicherer macht als jede vorherige Version.

Stand 2026 unterstützen 62 % der Websites TLS 1.3, und alle großen Browser unterstützen es seit 2018.

Was sich gegenüber TLS 1.2 geändert hat

Die Designphilosophie: Alles entfernen, was falsch konfiguriert werden kann. TLS 1.2 hat 37 Cipher Suites — einige sicher, einige gebrochen. TLS 1.3 hat 5, alle sicher.

Die 5 TLS 1.3 Cipher Suites

TLS_AES_256_GCM_SHA384        ← Stärkste, am häufigsten
TLS_AES_128_GCM_SHA256        ← Weit verbreitet, etwas schneller
TLS_CHACHA20_POLY1305_SHA256  ← Am besten für ARM/Mobile (kein AES-NI)
TLS_AES_128_CCM_SHA256        ← IoT/Embedded
TLS_AES_128_CCM_8_SHA256      ← IoT/Embedded (kurzer Tag)

Sie können diese nicht falsch konfigurieren — es sind alles AEAD-Cipher mit starken Schlüsseln. Es gibt kein Risiko, “versehentlich einen schwachen Cipher zu aktivieren” wie bei TLS 1.2.

1-RTT-Handshake: Warum er schneller ist

TLS 1.2 Handshake (2 Roundtrips):

Client → Server:  ClientHello (unterstützte Cipher)
Server → Client:  ServerHello, Certificate, KeyExchange
Client → Server:  KeyExchange, ChangeCipherSpec, Finished
Server → Client:  ChangeCipherSpec, Finished
                  [4 Nachrichten bevor verschlüsselte Daten fließen]

TLS 1.3 Handshake (1 Roundtrip):

Client → Server:  ClientHello + KeyShare
Server → Client:  ServerHello + KeyShare + Certificate + Finished
Client → Server:  Finished
                  [Verschlüsselte Daten können nach 1 Roundtrip fließen]

Der Client sendet seine Key-Share-Parameter in der ersten Nachricht — kein Warten auf die Algorithmusangabe des Servers nötig. Das verkürzt den Handshake von 2 Roundtrips auf 1.

0-RTT-Wiederaufnahme

Für wiederkehrende Besucher (die sich bereits verbunden haben) unterstützt TLS 1.3 0-RTT — verschlüsselte Anwendungsdaten werden mit der allerersten Nachricht gesendet:

Client → Server:  ClientHello + KeyShare + EarlyData (verschlüsselte Anfrage)
Server → Client:  ServerHello + Antwort

Die Anfrage wird gesendet, bevor der Handshake abgeschlossen ist. Kompromiss: 0-RTT-Daten sind anfällig für Replay-Angriffe, daher sollten sie nur für idempotente Anfragen (GET, nicht POST) verwendet werden.

Obligatorisches Forward Secrecy

In TLS 1.2 konnte man RSA-Schlüsselaustausch verwenden — der langfristige RSA-Schlüssel des Servers entschlüsselt direkt das Pre-Master-Secret. Wenn jemand den Verkehr aufzeichnet und später den privaten Schlüssel des Servers stiehlt, kann er alle vergangenen Gespräche entschlüsseln.

TLS 1.3 entfernt den RSA-Schlüsselaustausch vollständig. Der gesamte Schlüsselaustausch verwendet ephemeres Diffie-Hellman (ECDHE) — für jede Verbindung wird ein einzigartiges Schlüsselpaar generiert. Das Stehlen des privaten Schlüssels des Servers hilft nicht beim Entschlüsseln vergangener Sitzungen. Mehr zu Forward Secrecy →

Verschlüsseltes Zertifikat

In TLS 1.2 wird das Serverzertifikat (einschließlich des Domainnamens) im Handshake im Klartext gesendet. Ein passiver Beobachter kann sehen, mit welcher Seite Sie sich verbinden.

In TLS 1.3 wird das Zertifikat nach der Ableitung der Handshake-Schlüssel gesendet — es ist verschlüsselt. Der SNI (Server Name Indication) ist in TLS 1.3 noch sichtbar, aber Encrypted Client Hello (ECH) wird das in Zukunft ebenfalls verschlüsseln.

So aktivieren Sie TLS 1.3

Prüfen, ob es bereits aktiviert ist

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 2>/dev/null | grep "Protocol"
# Erwartet: TLSv1.3

Nginx (1.13+ mit OpenSSL 1.1.1+)

ssl_protocols TLSv1.2 TLSv1.3;

TLS 1.3 ist in modernem Nginx standardmäßig aktiviert — Sie müssen es nur nicht deaktivieren.

Apache (2.4.37+ mit OpenSSL 1.1.1+)

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Dies aktiviert TLS 1.2 und 1.3.

OpenSSL-Version prüfen

openssl version
# Benötigt: OpenSSL 1.1.1+ für TLS 1.3-Unterstützung

Wenn Ihr OpenSSL älter ist, aktualisieren Sie es oder aktualisieren Sie Ihr Betriebssystem.

Sollte ich nur TLS 1.3 erzwingen?

Noch nicht. Etwa 38 % der Seiten unterstützen kein TLS 1.3, und einige Clients (Unternehmensproxys, Java 8, ältere eingebettete Systeme) unterstützen nur TLS 1.2. TLS 1.2 heute aufzugeben würde einige Nutzer aussperren.

Empfohlene Konfiguration: Unterstützen Sie sowohl TLS 1.2 als auch 1.3. Dies gibt Ihnen TLS 1.3-Geschwindigkeit für moderne Clients bei gleichzeitiger Kompatibilität. Das ist, was Google, Cloudflare und die meisten großen Seiten tun.

Häufig gestellte Fragen

Brauche ich ein neues Zertifikat für TLS 1.3?

Nein. Dasselbe Zertifikat funktioniert mit TLS 1.2 und 1.3. Zertifikate sind protokollunabhängig — sie enthalten einen öffentlichen Schlüssel und eine CA-Signatur, unabhängig davon, welche TLS-Version sie verwendet.

Beeinflusst TLS 1.3 die Performance?

Ja, positiv. Der 1-RTT-Handshake spart 50-100ms bei der ersten Verbindung. Die 0-RTT-Wiederaufnahme eliminiert die Handshake-Latenz für wiederkehrende Besucher vollständig. In Kombination mit HTTP/2 (das HTTPS erfordert) sind TLS 1.3-Seiten messbar schneller.

Ist TLS 1.2 noch sicher?

Ja, mit AEAD-Cipher-Suites (AES-GCM, ChaCha20-Poly1305) und ECDHE-Schlüsselaustausch. Vermeiden Sie CBC-Cipher in TLS 1.2 — sie waren anfällig für Angriffe (BEAST, Lucky13). TLS 1.3 ist besser, aber TLS 1.2 mit modernen Ciphern bleibt sicher.

Was ist mit TLS 1.4?

Es ist kein TLS 1.4 geplant. Die IETF betrachtet TLS 1.3 als Ziel für die absehbare Zukunft. Die nächste große Änderung wird die Integration von Post-Quantum-Schlüsselaustausch (ML-KEM) als Hybrid mit bestehendem ECDHE sein — dies wird innerhalb von TLS 1.3 geschehen, nicht als neue Version.