TLS 1.3 (Transport Layer Security Version 1.3) ist die aktuelle Hauptversion des TLS-Protokolls, im August 2018 von der IETF als RFC 8446 standardisiert, nach vier Jahren Entwurfsarbeit und 28 Working Drafts. TLS verschlüsselt HTTPS, SMTP STARTTLS, IMAPS, FTPS, OpenVPN, modernes QUIC und viele weitere Anwendungsprotokolle im Internet. Verglichen mit TLS 1.2 (RFC 5246, August 2008) ist TLS 1.3 schneller (ein Round-Trip-Handshake statt zwei, optional 0-RTT-Resumption), sicherer (entfernt veraltete Cipher wie RC4, 3DES, CBC, RSA Key Exchange, entfernt statisches RSA, erzwingt Forward Secrecy über Ephemeral Diffie-Hellman) und einfacher (rund 40 Prozent kürzere Spezifikation). Alle modernen Browser, Betriebssysteme und großen Webserver unterstützen TLS 1.3 seit 2018 bis 2020. Laut Cloudflare-Daten nutzen mehr als 70 Prozent der HTTPS-Anfragen im offenen Internet inzwischen TLS 1.3, TLS 1.2 ist die einzige relevante verbleibende Alternative. TLS 1.0 und 1.1 wurden von der IETF in RFC 8996 (März 2021) abgekündigt und sind in allen aktuellen Browsern deaktiviert (Chrome 84 Juli 2020, Firefox 78 Juni 2020, Safari 14 September 2020, Edge 84 Juli 2020). PCI DSS verbietet TLS unter 1.2 seit 2018, das neueste PCI DSS v4.0 (wirksam ab 31. März 2024 und vollständig verpflichtend seit 31. März 2025) empfiehlt TLS 1.3 für Karteninhaberdaten.
Was hat sich gegenüber TLS 1.2 geändert?
| Aspekt | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake-Round-Trips | 2 RTT | 1 RTT (oder 0 RTT bei Resumption) |
| Cipher Suites | Hunderte, viele schwach (RC4, 3DES, CBC, RSA Key Exchange) | 5 starke AEAD-only (AES_128_GCM_SHA256, AES_256_GCM_SHA384, CHACHA20_POLY1305_SHA256, AES_128_CCM_SHA256, AES_128_CCM_8_SHA256) |
| Forward Secrecy | Optional | Pflicht (nur Ephemeral DH) |
| Statisches RSA Key Exchange | Erlaubt | Entfernt |
| Renegotiation | Erlaubt (CVE-anfällig) | Entfernt |
| Kompression | Erlaubt (CRIME-Risiko) | Entfernt |
| 0-RTT-Resumption | Nein | Ja (mit Replay-Bedingungen) |
| Verschlüsselter Handshake | Meist Klartext | ServerHello bis Finished verschlüsselt |
| SNI | Klartext | Standardmäßig Klartext, optional ECH (Encrypted Client Hello, RFC 9460 Draft 2024) verschlüsselt es |
Wie funktioniert der TLS-1.3-Handshake?
- Client Hello: Liste unterstützter Cipher Suites, Key Share für die bevorzugte Diffie-Hellman-Gruppe (X25519 in 99 Prozent der Fälle) und SNI für den Ziel-Hostnamen.
- Server Hello: Server wählt eine Cipher Suite, sendet eigenen Key Share und wechselt sofort zu verschlüsselten Records. Zertifikat, Certificate Verify und Finished werden bereits verschlüsselt gesendet.
- Client Finished: Client validiert Zertifikat und Key Exchange, sendet Finished.
- Application Data fließt im gleichen Round Trip, wenn der Client das unterstützt.
0-RTT-Resumption (auch Early Data) erlaubt einem wiederkehrenden Client, Anwendungsdaten schon im allerersten Paket zu senden. Schnell, aber mit Replay-Risiken. Nur idempotente Requests wie GET. POST, Zahlung und Login müssen 0-RTT ablehnen.
Performance-Wirkung von TLS 1.3
- Ein voller Round Trip pro neuer HTTPS-Verbindung gespart. Bei 100 ms RTT bedeutet das 100 ms schnellere TTFB.
- Schnellere Cipher Suites: AES-GCM und ChaCha20-Poly1305 sind AEAD-Modi, die ohne separates HMAC laufen.
- X25519 ECDH ist 5 bis 10 mal schneller als der klassische RSA Key Exchange in TLS 1.2.
- Zusammen mit HTTP/2 oder HTTP/3 verstärkt sich der Effekt: TLS 1.3 + HTTP/3 über QUIC reduzieren First Paint um 100 bis 300 ms auf Mobilverbindungen.
Sicherheits-Verbesserungen
- Keine schwachen Cipher mehr: alle CBC, RC4, 3DES, MD5, SHA-1, RSA Key Exchange und statisches DH entfernt.
- Forward Secrecy Pflicht: jede Session nutzt Ephemeral Keys. Selbst wenn ein privater Schlüssel Jahre später leakt, ist vergangener Traffic nicht entschlüsselbar.
- Verschlüsseltes Zertifikat: das Serverzertifikat wird verschlüsselt übertragen, vor passiven Beobachtern verborgen (DPI, staatliche Überwachung).
- Keine Renegotiation: Renegotiation-Angriffe wie CVE-2009-3555 sind unmöglich.
- Keine Kompression: CRIME (2012) und BREACH-artige TLS-Komprimierungs-Angriffe sind auf der TLS-Ebene nicht möglich.
- Downgrade-Schutz: Downgrade-Indikator im Random-Feld verhindert erzwungenes Fallback auf TLS 1.2.
Wie aktiviere ich TLS 1.3?
nginx
Benötigt nginx 1.13.0 oder neuer mit OpenSSL 1.1.1 oder neuer (September 2018). Distributionen liefern das seit 2019.
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;Hinweis: In TLS 1.3 wird die Cipher-Auswahl nicht mehr über ssl_ciphers gesteuert. nginx wählt automatisch aus den 5 verpflichtenden TLS-1.3-Suiten.
Apache
Benötigt Apache 2.4.37 oder neuer mit OpenSSL 1.1.1 oder neuer.
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling onCloudflare
TLS 1.3 ist seit 2018 für jede Cloudflare-Zone standardmäßig aktiv. Prüfen oder ändern: Cloudflare Dashboard, SSL/TLS, Edge Certificates, Minimum TLS Version. Auf 1.2 setzen. Zusätzlich aktivieren: Opportunistic Encryption, Automatic HTTPS Rewrites, Always Use HTTPS.
Managed-WordPress-Hoster
| Hoster | TLS-1.3-Status |
|---|---|
| Cloudflare | Standardmäßig seit 2018 |
| Kinsta | Standardmäßig |
| WP Engine | Standardmäßig |
| SiteGround | Standardmäßig |
| Cloudways | Standardmäßig |
| Hetzner managed | Standardmäßig seit 2020 |
| Alte Shared Hoster | Oft nur TLS 1.2, Cloudflare davor schalten |
Wie teste ich die TLS-Konfiguration?
- Qualys SSL Labs auf
ssllabs.com/ssltest: kostenlos, de-facto-Standard. Bewertet A+ bis F. - Mozilla Observatory auf
observatory.mozilla.org. - testssl.sh: Open-Source-Kommandozeilen-Tool, läuft lokal.
- openssl:
openssl s_client -connect example.de:443 -tls1_3 # Suche: Protocol : TLSv1.3 - curl:
curl --tlsv1.3 -v https://example.de/ 2>&1 | grep -i ssl. - Chrome DevTools: Security-Tab zeigt TLS-Version und Cipher.
Häufige TLS-1.3-Stolperfallen
- 0-RTT-Replay: Early Data nur für idempotente Requests. Login, Checkout, Account-Änderungen deaktivieren.
- Middleboxes: manche Unternehmens-Proxies und Antivirus (Avast, Kaspersky historisch) brachen TLS 1.3, weil sie den neuen Handshake nicht parsten. RFC 8446 brachte GREASE-Werte und einen Middlebox-Compatibility-Mode.
- SNI weiterhin Klartext: der Ziel-Hostname ist für passive Beobachter sichtbar. Encrypted Client Hello (ECH, RFC 9460 Draft) versteckt ihn. Cloudflare aktivierte ECH in Produktion im September 2023, Firefox und Chrome unterstützen es hinter einem Flag.
- Alte Client-Kompatibilität: Windows XP, IE 8 bis 10, Android < 5 und Java < 8 können kein TLS 1.3. Wer diese bedienen muss (weniger als 0,1 Prozent des offenen Webs 2025), behält TLS 1.2 parallel aktiv.
- Zertifikatskette: TLS 1.3 repariert keine fehlende Zwischenzertifikate.
fullchain.pemverwenden.
Was ist mit TLS 1.4?
Es ist kein TLS 1.4 geplant. Zukünftige Verbesserungen kommen als Erweiterungen zu TLS 1.3 (ECH, Post-Quantum-Hybrid-Key-Exchange) ohne Haupt-Versionswechsel. Die IETF-Post-Quantum-Migration via Hybrid X25519MLKEM768 ging in Chrome 124 (April 2024) live und ist in Cloudflare seit März 2024 standardmäßig aktiv.
Wie hilft InspectWP bei TLS?
InspectWP analysiert die TLS-Konfiguration jeder gescannten URL und meldet ausgehandelte TLS-Version, Zertifikatsgültigkeit, Schlüsselstärke, unterstützte Cipher Suites und HSTS-Konfiguration. Seiten, die noch TLS 1.0 oder 1.1 erlauben, werden kritisch markiert. Seiten ohne TLS 1.3 werden als Performance- und Sicherheits-Verbesserungspotenzial markiert.