TLS 1.2 vs. TLS 1.3: Änderungen und richtige Konfiguration

TLS 1.2 vs. TLS 1.3 ist keine Wahl mehr zwischen zwei gleichwertigen Versionen. TLS 1.2 (RFC 5246, 2008) ist sicher, wenn es auf ECDHE-Schlüsselaustausch und AEAD-Cipher-Suites beschränkt wird. TLS 1.3 (RFC 8446 aus dem Jahr 2018, im Juli 2026 als RFC 9846 überarbeitet) macht genau das zur einzigen Option, verschlüsselt einen größeren Teil des Handshakes und ist die einzige Version, die hybriden Schlüsselaustausch mit Post-Quanten-Verfahren und Encrypted Client Hello bietet.

Auf einen Blick

Der Handshake

TLS 1.2 handelt zuerst aus und tauscht danach Schlüssel aus: Der Client listet Cipher Suites auf, der Server wählt eine davon und sendet sein Zertifikat und die Parameter für den Schlüsselaustausch, der Client sendet seinen Key Share, und beide schließen ab. Zwei Roundtrips vergehen, bevor Anwendungsdaten fließen, und das Zertifikat wird im Klartext übertragen. Bei Suites mit statischem RSA verschlüsselt der Client das Premaster Secret mit dem Schlüssel aus dem Zertifikat des Servers – wer diesen Schlüssel später erlangt, kann also jede aufgezeichnete Sitzung entschlüsseln.

TLS 1.3 arbeitet mit einer Vermutung: Der Client sendet schon in der ersten Nachricht Key Shares für seine bevorzugten Gruppen, der Server antwortet mit seinem Key Share und sofort danach mit den verschlüsselten Extensions, dem Zertifikat, CertificateVerify und Finished, und der Client kann nach einem Roundtrip Daten senden. Wiederaufgenommene Sitzungen können sogar 0-RTT-Daten (Early Data) mitführen, auf Kosten des Replay-Schutzes für diese Daten.

Das folgende Skript, ausgeführt mit OpenSSL 3.6.5 gegen einen öffentlichen Server am 20. Oktober 2026, zeigt das praktische Ergebnis, wenn derselbe Client jeweils eine der beiden Versionen erzwingt.

#!/bin/sh
host=${1:-cloudflare.com}
for version in -tls1_2 -tls1_3; do
  echo "== $version"
  echo | openssl s_client -connect "$host:443" -servername "$host" "$version" -brief 2>&1 \
    | grep -E "Protocol version|Ciphersuite|Peer Temp Key|Negotiated TLS1.3 group"
done

== -tls1_2
Protocol version: TLSv1.2
Ciphersuite: ECDHE-ECDSA-CHACHA20-POLY1305
Peer Temp Key: X25519, 253 bits
== -tls1_3
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Negotiated TLS1.3 group: X25519MLKEM768

Die Verbindung über TLS 1.2 ist hier sicher, weil der Server nur ECDHE mit AEAD zulässt, sie bleibt aber auf klassisches X25519 beschränkt; die Verbindung über TLS 1.3 handelt die hybride Post-Quanten-Gruppe aus.

Was TLS 1.3 entfernt hat – und warum

Fast jeder bekannte TLS-Angriff der 2010er-Jahre nutzte eine Funktion aus der Ära von TLS 1.2 aus, die TLS 1.3 gestrichen hat:

• CBC-Modus mit MAC-then-Encrypt (BEAST, Lucky Thirteen, POODLE): Es bleiben nur AEAD-Verschlüsselungsverfahren.
• RC4 (statistische Verzerrungen) und 3DES (SWEET32): entfernt.
• RSA-Schlüsseltransport (Padding-Orakel nach Bleichenbacher, ROBOT; keine Forward Secrecy): entfernt.
• Gruppen in Exportstärke und beliebige Gruppen über endlichen Körpern (FREAK, Logjam): Es bleiben nur Named Groups.
• Renegotiation und Kompression (Triple Handshake, CRIME): entfernt.
• Signaturen über Teile des Transkripts (ServerKeyExchange in TLS 1.2 signiert nur die Parameter): CertificateVerify signiert das gesamte Transkript.
• SHA-1 und MD5 in Signaturen: entfernt.

RFC 9846 verschärft außerdem die Anforderungen an Implementierungen von TLS 1.2, und RFC 9325 beschreibt die sichere Teilmenge von TLS 1.2: ECDHE oder DHE mit AEAD, Extended Master Secret (RFC 7627) und sichere Renegotiation.

Funktionen, die nur TLS 1.3 bietet

• Hybrider Schlüsselaustausch mit Post-Quanten-Verfahren (X25519MLKEM768, RFC 10024), in den großen Browsern seit Ende 2024 standardmäßig ausgehandelt und in OpenSSL seit 3.5.
• Encrypted Client Hello (RFC 9849), das den Servernamen vor dem Netzwerk verbirgt, wenn es zusammen mit DNS-Einträgen vom Typ HTTPS eingesetzt wird.
• Zertifikatskompression (RFC 8879) und Delegated Credentials (RFC 9345).
• QUIC, das den Handshake von TLS 1.3 einbettet und als Transport für HTTP/3 dient.

Compliance und Richtlinien

• Systeme der US-Bundesbehörden: NIST SP 800-52 Rev. 2 verlangt, dass TLS-Server der Regierung bis zum 1. Januar 2024 TLS 1.3 unterstützen, und erlaubt TLS 1.2 mit zugelassenen Suites.
• Umgebungen mit Zahlungskarten: PCI DSS verbietet SSL und frühes TLS (1.0) seit dem 30. Juni 2018; TLS 1.2 und 1.3 sind beide zulässig.
• IETF: RFC 8996 hat TLS 1.0 und 1.1 im Jahr 2021 für veraltet erklärt; die Browser haben sie 2020 entfernt.
• Post-Quanten-Pläne: NIST IR 8547 (Entwurf) und CNSA 2.0 setzen eine hybride Schlüsseleinigung oder eine reine Post-Quanten-Schlüsseleinigung voraus, die es nur in TLS 1.3 gibt.

Wann welche Version passt

• Öffentliche Websites und APIs: TLS 1.3 bevorzugt, TLS 1.2 mit der sicheren Teilmenge als Fallback.
• Interne Dienste, Service Meshes, mTLS: nur TLS 1.3.
• Ältere Clients (alte Android-Versionen, Embedded-Geräte, ältere Java- und Windows-Versionen): TLS 1.2 mit ECDHE und AEAD; plane ihre Ablösung.
• Middleboxes, die den Datenverkehr untersuchen: Rechne damit, dass sie für TLS 1.3, ECH und große Post-Quanten-ClientHellos Updates brauchen, statt ihretwegen die Server zurückzuhalten.
• Alles, was Post-Quanten-Vertraulichkeit braucht: TLS 1.3 mit einer hybriden Gruppe.

Hinweise zur Migration

1. TLS-Bibliothek aktualisieren: OpenSSL 1.1.1 oder neuer für TLS 1.3, 3.5 oder neuer für Post-Quanten-Gruppen als Standard; aktuelles BoringSSL, Go, Java 11 oder neuer, Windows Server 2022 oder neuer.
2. TLS 1.3 neben 1.2 aktivieren, dann 1.2 auf ECDHE- und AEAD-Suites beschränken; in nginx ssl_protocols TLSv1.2 TLSv1.3; mit einer kurzen Liste in ssl_ciphers, da die Suites von TLS 1.3 separat konfiguriert werden.
3. Zertifikate und Schlüssel prüfen: RSA-Zertifikate funktionieren mit TLS 1.3, weil die Signaturen im Handshake PSS mit denselben Schlüsseln verwenden; ECDSA-Zertifikate funktionieren unverändert.
4. Über 0-RTT entscheiden: Lass es deaktiviert, es sei denn, die Anwendung kann wiederholt eingespielte frühe Anfragen sicher verarbeiten.
5. Den verbleibenden Verkehr über TLS 1.2 messen und, wo er auf null sinkt, ein Datum für die Abschaltung festlegen. Der TLS-Konfigurationsgenerator erzeugt Einstellungen für gängige Server, und der Bulk-Domain-Checker zeigt, welche Versionen deine Hosts akzeptieren.

Quellen

• RFC 9846, TLS 1.3 (§1.3 Unterschiede zu TLS 1.2, §1.4 Änderungen mit Auswirkungen auf TLS 1.2)
• RFC 5246, TLS 1.2
• RFC 9325, Empfehlungen für den sicheren Einsatz von TLS und DTLS
• RFC 8996, Abkündigung von TLS 1.0 und TLS 1.1
• RFC 10024, hybride Schlüsseleinigung mit ML-KEM für TLS 1.3
• RFC 9849, Encrypted Client Hello für TLS
• NIST SP 800-52 Rev. 2
• PCI SSC: Migration weg von SSL und frühem TLS