TLS-Versionen im Überblick: Von SSL 3.0 bis TLS 1.3
Die Geschichte der Transportverschlüsselung beginnt mit SSL 2.0 (1995) und SSL 3.0 (1996), die beide als unsicher gelten und nicht mehr verwendet werden sollten. TLS 1.0 (1999) und TLS 1.1 (2006) waren jahrelang Standard, wurden aber 2020 von den großen Browsern als veraltet markiert und ab 2021 standardmäßig deaktiviert. TLS 1.2 (2008) ist die heute am weitesten verbreitete Version und gilt bei korrekter Konfiguration als sicher. TLS 1.3 (2018) ist die aktuelle Version und bietet signifikante Verbesserungen bei Sicherheit und Performance.
Wenn Ihre Website noch TLS 1.0 oder 1.1 unterstützt, deaktivieren Sie diese Versionen umgehend. Beide sind anfällig für bekannte Angriffe wie BEAST und POODLE. Moderne Browser blockieren diese Verbindungen bereits standardmäßig. XICTRAQ meldet veraltete TLS-Versionen als kritischen Sicherheitsbefund.
TLS 1.2: Stärken und Schwächen
TLS 1.2 ist seit 2008 verfügbar und hat sich als zuverlässiger Standard bewährt. Bei korrekter Konfiguration bietet es solide Sicherheit. Allerdings hat es einige architektonische Schwächen, die TLS 1.3 gezielt adressiert.
Der TLS 1.2 Handshake: vier Nachrichten, zwei Roundtrips
Der TLS-1.2-Handshake benötigt zwei vollständige Roundtrips (2-RTT) zwischen Client und Server. Im ersten Roundtrip sendet der Client ein ClientHello mit unterstützten Cipher Suites, der Server antwortet mit ServerHello, Zertifikat und Schlüsselaustauschdaten. Im zweiten Roundtrip sendet der Client seine Schlüsselaustauschdaten und eine ChangeCipherSpec-Nachricht, der Server bestätigt. Erst dann beginnt die verschlüsselte Kommunikation. Bei einer Latenz von 50 ms pro Roundtrip dauert der Handshake mindestens 200 ms, bevor der erste Byte Nutzdaten fließt.
Konfigurationsrisiken bei TLS 1.2
TLS 1.2 unterstützt eine breite Palette von Cipher Suites, darunter auch veraltete und unsichere. RSA-Schlüsselaustausch ohne Forward Secrecy, CBC-Mode-Cipher und MD5- oder SHA-1-basierte Signaturen sind in TLS 1.2 theoretisch möglich. Die Sicherheit hängt stark von der Server-Konfiguration ab. Ein falsch konfigurierter TLS-1.2-Server kann anfällig für Angriffe wie BEAST, Lucky 13 oder ROBOT sein. Security-Header allein reichen nicht aus, wenn die TLS-Konfiguration Schwächen aufweist.
TLS 1.3: Schneller, sicherer, einfacher
TLS 1.3 wurde 2018 als RFC 8446 veröffentlicht und ist das Ergebnis einer umfassenden Überarbeitung des Protokolls. Die Designziele waren klar: weniger Roundtrips, weniger unsichere Optionen und besserer Schutz der Metadaten.
Der TLS 1.3 Handshake: zwei Nachrichten, ein Roundtrip
Der TLS-1.3-Handshake benötigt nur einen Roundtrip (1-RTT). Der Client sendet im ClientHello bereits Schlüsselaustauschdaten mit, weil TLS 1.3 nur noch wenige, vorab bekannte Schlüsselaustauschalgorithmen unterstützt. Der Server kann sofort mit ServerHello, Zertifikat und verschlüsselten Daten antworten. Die verschlüsselte Kommunikation beginnt nach nur einem Roundtrip. Bei 50 ms Latenz dauert der Handshake nur 100 ms statt 200 ms, eine Halbierung der Verbindungsaufbauzeit.
0-RTT Resumption: Noch schneller bei Wiederholungsbesuchen
TLS 1.3 bietet eine 0-RTT-Resumption für wiederholte Verbindungen. Wenn ein Client bereits eine TLS-1.3-Verbindung zu einem Server aufgebaut hat, kann er bei der nächsten Verbindung sofort verschlüsselte Daten senden, ohne auf eine Serverantwort zu warten. Das eliminiert die Handshake-Latenz vollständig. Diese Funktion ist besonders wertvoll für Websites mit wiederkehrenden Besuchern und verbessert die Ladezeit messbar.
Die 0-RTT-Resumption ist nicht gegen Replay-Angriffe geschützt. Ein Angreifer könnte die erste 0-RTT-Nachricht abfangen und erneut senden. Verwenden Sie 0-RTT daher nur für idempotente Anfragen (GET) und nicht für zustandsändernde Operationen (POST, PUT, DELETE).
Weniger Cipher Suites, mehr Sicherheit
TLS 1.3 reduziert die unterstützten Cipher Suites von über 300 in TLS 1.2 auf nur fünf. Alle unsicheren Optionen wurden entfernt: kein RSA-Schlüsselaustausch mehr (Forward Secrecy ist Pflicht), kein CBC-Modus (nur AEAD-Cipher wie AES-GCM und ChaCha20-Poly1305), keine SHA-1-Signaturen. Diese Einschränkung eliminiert ganze Klassen von Angriffen und macht Fehlkonfigurationen praktisch unmöglich.
Verschlüsselte Metadaten
In TLS 1.2 werden Zertifikat und ServerHello-Erweiterungen unverschlüsselt übertragen. Ein Beobachter kann sehen, welches Zertifikat der Server verwendet und damit die aufgerufene Domain identifizieren. TLS 1.3 verschlüsselt das Serverzertifikat und weitere Handshake-Nachrichten, was die Privatsphäre verbessert. In Kombination mit Encrypted Client Hello (ECH), das seit 2025 von Chrome und Firefox unterstützt wird, wird auch der Server Name Indication (SNI) verschlüsselt, sodass ein Beobachter nicht mehr sehen kann, welche Website aufgerufen wird.
Performance-Vergleich: TLS 1.2 vs. TLS 1.3
Die Performance-Vorteile von TLS 1.3 sind in der Praxis messbar. Eine Studie von Cloudflare zeigt, dass TLS 1.3 den Verbindungsaufbau um 21 bis 40 % beschleunigt, abhängig von der Latenz zwischen Client und Server (Cloudflare). Bei mobilen Verbindungen mit höherer Latenz sind die Vorteile noch deutlicher.
- Handshake-Dauer: TLS 1.2 benötigt 2-RTT (~200-500 ms), TLS 1.3 nur 1-RTT (~100-200 ms)
- Resumption: TLS 1.2 Session Tickets benötigen 1-RTT, TLS 1.3 bietet 0-RTT
- Datendurchsatz: TLS 1.3 mit AEAD-Ciphers ist bei gleicher Sicherheit effizienter
- Core Web Vitals: Schnellerer Handshake verbessert TTFB und damit LCP
- Mobile: Bei 150 ms Latenz spart TLS 1.3 bis zu 300 ms pro Verbindungsaufbau
Google berücksichtigt HTTPS als Ranking-Signal. Obwohl die TLS-Version nicht direkt in den Algorithmus einfließt, verbessert der schnellere Handshake die Ladezeit, die wiederum ein Ranking-Faktor ist. Die Kombination aus TLS 1.3 und HTTP/2 oder HTTP/3 maximiert die Performance. XICTRAQ überwacht die TLS-Konfiguration im Security-Modul und empfiehlt die optimale Einstellung.
Kompatibilität: Welche Browser und Server unterstützen TLS 1.3?
TLS 1.3 wird 2026 von allen relevanten Browsern unterstützt: Chrome ab Version 70, Firefox ab Version 63, Safari ab Version 12.1, Edge ab Version 79 und alle mobilen Browser in aktuellen Versionen. Laut Can I Use liegt die globale Browser-Unterstützung bei über 97 % (Can I Use). Auf der Serverseite unterstützen OpenSSL ab Version 1.1.1, nginx ab Version 1.13.0, Apache ab Version 2.4.37 und Caddy nativ TLS 1.3.
Die wenigen Browser ohne TLS-1.3-Unterstützung sind Internet Explorer 11 und ältere mobile Browser. Wenn Ihre Zielgruppe ausschließlich moderne Browser verwendet, können Sie TLS 1.2 deaktivieren. In den meisten Fällen empfiehlt sich jedoch die gleichzeitige Unterstützung von TLS 1.2 und 1.3, wobei TLS 1.3 als bevorzugte Version konfiguriert wird.
TLS-Konfiguration optimieren: Best Practices
Die optimale TLS-Konfiguration hängt von Ihrem Sicherheitsbedarf und Ihrer Zielgruppe ab. Die folgenden Empfehlungen bieten eine Balance zwischen maximaler Sicherheit und breiter Kompatibilität.
Empfohlene Cipher Suites
Für TLS 1.3 werden nur AEAD-Cipher unterstützt. Die empfohlene Reihenfolge: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256. Für TLS 1.2 sollten Sie ausschließlich ECDHE-basierte Cipher mit Forward Secrecy verwenden und RSA-Schlüsselaustausch deaktivieren.
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
ssl_ecdh_curve X25519:P-256:P-384;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;HSTS aktivieren
HTTP Strict Transport Security (HSTS) weist den Browser an, Ihre Website nur über HTTPS aufzurufen. Das verhindert SSL-Stripping-Angriffe und Downgrade-Versuche. Setzen Sie den HSTS-Header mit einer langen Laufzeit und der includeSubDomains-Direktive. Ergänzend sollten Sie Ihre Domain in die HSTS-Preload-Liste aufnehmen lassen. XICTRAQ prüft den HSTS-Header als Teil der Security-Header-Analyse.
OCSP Stapling konfigurieren
OCSP Stapling beschleunigt die Zertifikatsvalidierung, indem der Server die OCSP-Antwort direkt mitliefert, statt den Client an den OCSP-Responder zu verweisen. Das spart einen zusätzlichen Roundtrip und verbessert die Privatsphäre, da der Client keine Anfrage an die Zertifizierungsstelle senden muss. Kombiniert mit OCSP Must-Staple wird der Server verpflichtet, eine gültige OCSP-Antwort bereitzustellen.
DSGVO und TLS: Verschlüsselung als rechtliche Pflicht
Art. 32 DSGVO verlangt technische Maßnahmen zum Schutz personenbezogener Daten, darunter explizit die Verschlüsselung. Websites, die Kontaktformulare, Login-Bereiche oder Bestellprozesse anbieten, müssen die Datenübertragung verschlüsseln. TLS ist die Standard-Technologie dafür. Die Aufsichtsbehörden bewerten fehlende oder veraltete Verschlüsselung als Verstoß gegen die technischen Schutzpflichten. XICTRAQ prüft die TLS-Version als Teil des DSGVO-Compliance-Moduls und meldet veraltete Konfigurationen.
Über die rechtliche Pflicht hinaus signalisiert ein korrekt konfiguriertes SSL-Zertifikat Besuchern Vertrauenswürdigkeit. Browser kennzeichnen HTTP-Seiten als unsicher, während HTTPS-Seiten ein Schloss-Symbol erhalten. Für E-Commerce-Websites ist eine aktuelle TLS-Konfiguration geschäftskritisch: 84 % der Nutzer brechen einen Kauf ab, wenn die Verbindung als unsicher gekennzeichnet ist (GlobalSign). Zusätzlich schützen richtig konfigurierte Verschlüsselungsschichten vor DNS-Hijacking und Man-in-the-Middle-Angriffen.
TLS-Monitoring: Konfiguration kontinuierlich überwachen
Eine einmalige Konfiguration reicht nicht aus. Server-Updates, Zertifikatserneuerungen und Hosting-Migrationen können die TLS-Konfiguration unbeabsichtigt ändern. XICTRAQ überwacht die TLS-Konfiguration Ihrer Website bei jedem Scan-Durchlauf und prüft dabei:
- Unterstützte TLS-Versionen und Warnung bei veralteten Protokollen
- Cipher-Suite-Reihenfolge und Erkennung unsicherer Cipher
- Forward-Secrecy-Unterstützung
- Zertifikatsgültigkeit und Ablaufdatum mit Vorab-Warnungen
- HSTS-Konfiguration und Preload-Status
- OCSP-Stapling-Verfügbarkeit
- Certificate Transparency Log-Einträge
Bei Statusverschlechterungen, etwa wenn ein Server-Update TLS 1.3 deaktiviert oder ein Cipher-Suite-Update unsichere Optionen einführt, werden Sie per E-Mail benachrichtigt und erhalten konkrete Handlungsempfehlungen im Dashboard. So stellen Sie sicher, dass Ihre TLS-Konfiguration dauerhaft auf dem aktuellen Stand bleibt.
Migration von TLS 1.2 auf TLS 1.3
Die Migration auf TLS 1.3 ist in den meisten Fällen unkompliziert. Wenn Ihr Server bereits TLS 1.2 unterstützt, genügt in der Regel eine Konfigurationsanpassung. Aktualisieren Sie OpenSSL auf Version 1.1.1 oder höher, aktivieren Sie TLS 1.3 in der Server-Konfiguration und testen Sie die Kompatibilität. Überwachen Sie die Server-Logs auf Verbindungsfehler älterer Clients und deaktivieren Sie TLS 1.0 und 1.1, falls noch aktiv.
Für Websites auf Managed Hosting oder bei Cloud-Anbietern ist TLS 1.3 häufig bereits aktiviert. Prüfen Sie die Einstellungen in Ihrem Hosting-Panel oder kontaktieren Sie den Support. XICTRAQ erkennt automatisch, ob Ihre Website TLS 1.3 unterstützt, und gibt bei fehlender Unterstützung eine Empfehlung zur Aktivierung im Security-Scan.
Häufig gestellte Fragen zu TLS-Versionen
Ist TLS 1.2 noch sicher?
Muss ich TLS 1.2 deaktivieren, wenn ich TLS 1.3 aktiviere?
Wie viel schneller ist TLS 1.3?
Unterstützen alle Browser TLS 1.3?
Verlangt die DSGVO eine bestimmte TLS-Version?
Wie überwache ich die TLS-Konfiguration meiner Website?
Dieser Artikel basiert auf Daten von: (Cloudflare), (GlobalSign), Core Web Vitals (Google).