TLS 1.2 und TLS 1.3 verstehen

TLS (Transport Layer Security) ist das kryptografische Protokoll, das Daten verschlüsselt und authentifiziert, die zwischen Clients und Servern über ein Netzwerk übertragen werden. Es schützt persönliche Informationen, Finanztransaktionen, API-Verkehr und Geschäftskommunikation vor Abhören, Manipulation und Identitätsdiebstahl. TLS 1.3 ist die aktuell empfohlene Version. Sie reduziert die Anzahl der Handshake-Roundtrips von 2 auf 1, schreibt Forward Secrecy mittels ECDHE für alle Verbindungen vor, entfernt alle veralteten, schwachen Verschlüsselungssammlungen und verschlüsselt einen größeren Teil des Handshakes als TLS 1.2. Die empfohlene Vorgehensweise: Aktivieren Sie TLS 1.3 umgehend auf allen Servern, deaktivieren Sie TLS 1.0 und 1.1, beschränken Sie TLS 1.2 während der Übergangsphase auf ECDHE-AEAD-Verschlüsselungssammlungen und betreiben Sie beide Versionen parallel, bis die Analyse älterer Clients bestätigt, dass TLS 1.2 nicht mehr benötigt wird.

Kurzantwort: TLS 1.2 vs. TLS 1.3 – Welches sollte man verwenden und warum?

TLS 1.3 ist die richtige Wahl für alle neuen Implementierungen. Es ist schneller (1-RTT-Handshake statt 2-RTT), sicherer (obligatorische Vorwärtsgeheimhaltung, verschlüsselter Handshake, Abschaffung aller veralteten Algorithmen) und einfacher (5 statt Hunderte von Verschlüsselungssammlungen). TLS 1.2 ist nur noch aus Gründen der Abwärtskompatibilität mit Clients und Systemen erforderlich, die TLS 1.3 noch nicht unterstützen. Das NIST schreibt gemäß NIST SP 800-52 Revision 2 vor , dass alle TLS-Server der US-Bundesregierung sowohl TLS 1.2 (mit FIPS-konformen Verschlüsselungssammlungen) als auch TLS 1.3 unterstützen müssen, wobei TLS 1.3 ab dem 1. Januar 2024 verpflichtend ist. TLS 1.0 und TLS 1.1 dürfen nicht mehr verwendet werden; sie weisen bekannte Sicherheitslücken auf und haben derzeit keine legitime Verwendung mehr.

Was ist TLS?

Transport Layer Security (TLS) ist ein kryptografisches Protokoll, das 1999 von der IETF standardisiert wurde. TLS baut auf SSL (Secure Sockets Layer) auf, indem es dessen Schwachstellen behebt und die Sicherheit durch stärkere Verschlüsselungsalgorithmen, verbesserte Zertifikatsvalidierung und Schutz vor Angriffen erhöht, die auch in SSL-Versionen vorhanden sind. Ältere TLS-Versionen (1.0 und 1.1) wiesen Sicherheitslücken auf, die es Angreifern ermöglichten, sensible Daten zu stehlen. TLS schützt Daten durch drei zusammenwirkende Mechanismen:

• Authentifizierung: Der Server legt während des Handshakes ein von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestelltes TLS-Zertifikat vor. Der Client überprüft dieses Zertifikat, um sicherzustellen, dass er mit dem legitimen Server und nicht mit einem Angreifer kommuniziert.
• Verschlüsselung: Nachdem beim Handshake ein gemeinsamer Sitzungsschlüssel festgelegt wurde, werden alle übertragenen Daten mit einer symmetrischen Verschlüsselung (AES-GCM oder ChaCha20-Poly1305 in TLS 1.3) verschlüsselt, um zu verhindern, dass Lauscher den Inhalt lesen können.
• Integrität: AEAD-Verschlüsselungssuiten beinhalten Authentifizierungs-Tags, die jede Änderung an verschlüsselten Daten erkennen und so sicherstellen, dass ein Angreifer die Daten während der Übertragung nicht unbemerkt verändern kann.

TLS 1.2 und sein Handshake

TLS 1.2, eingeführt im August 2008 (IETF RFC 5246), behob die Einschränkungen von TLS 1.0 und 1.1 durch stärkere Verschlüsselungsalgorithmen, verbesserte Zertifikatsvalidierung und Unterstützung für AEAD-Verschlüsselungssammlungen. Sein Handshake erfordert zwei Roundtrips (2-RTT):

• Der Client sendet ein ClientHello mit unterstützten TLS-Versionen, Cipher Suites, einem Client Random und einer optionalen Session-ID.
• Der Server antwortet mit einem ServerHello, in dem er die TLS-Version und die Verschlüsselungssuite, seinen eigenen Zufallsgenerator und sein signiertes Zertifikat mit öffentlichem Schlüssel auswählt. Falls eine gegenseitige Authentifizierung erforderlich ist, fordert der Server ein Clientzertifikat an.
• Der Client validiert das Serverzertifikat anhand vertrauenswürdiger Zertifizierungsstellen. Bei Mutual TLS (mTLS) validiert auch der Server das Clientzertifikat.
• Kryptographie mit öffentlichem Schlüssel Die Schlüsselübertragung wird gesichert: Der Client sendet ein mit dem öffentlichen Schlüssel des Servers verschlüsseltes Pre-Master-Secret. Nur der Server kann es mit seinem privaten Schlüssel entschlüsseln, der sicher in einem Speicher abgelegt ist. HSM oder Schlüsseltresor. Beide Parteien leiten Sitzungsschlüssel aus dem Vor-Master-Secret und deren Zufallswerten ab.
• Client und Server tauschen ChangeCipherSpec- und Finished-Nachrichten aus, um zu bestätigen, dass sie für die symmetrische Verschlüsselung bereit sind. Die gesamte nachfolgende Kommunikation verwendet die abgeleiteten Sitzungsschlüssel.

Hauptfunktionen von TLS 1.2

• Verbessertes Hashing: Die in früheren Versionen verwendete Kombination aus MD5 und SHA-1 wurde durch konfigurierbare Hash-Algorithmen wie SHA-256 und SHA-384 ersetzt.
• Unterstützung für AES-Verschlüsselungssuiten: eingeführt AES Verschlüsselungssuiten mit 128-Bit- und 256-Bit-Schlüsseln bieten eine deutlich stärkere symmetrische Verschlüsselung als die DES-basierten Suiten, die sie ersetzt haben.
• Unterstützung für authentifizierte Verschlüsselung (AEAD): Erweiterte Unterstützung für AEAD-Modi einschließlich AES-GCM und AES-CCM, die sowohl Vertraulichkeits- als auch Integritätsprüfung in einem einzigen Vorgang ermöglichen.
• Verhandelbare Hash- und Signaturalgorithmen: Sowohl Client als auch Server können während des Handshakes ihre unterstützten Hash- und Signaturalgorithmen angeben, sodass die stärkste, von beiden Seiten unterstützte Kombination ausgewählt werden kann und eine reibungslose Migration weg von schwachen Algorithmen wie SHA-1 ermöglicht wird.

TLS 1.3 und sein Handshake

TLS 1.3, veröffentlicht im August 2018 (RFC 8446), stellt eine grundlegende Überarbeitung des Protokolls dar. Es priorisiert die Sicherheit, indem es anfällige ältere Optionen entfernt, anstatt zusätzliche Sicherheitsmaßnahmen einzuführen. Der TLS-1.3-Handshake wird in einem Roundtrip (1-RTT) abgeschlossen.

• Der Client sendet ein ClientHello-Paket mit den unterstützten TLS-Versionen, Cipher Suites, Client Random und Key Shares für seine bevorzugten ECDHE-Gruppen. Ist die Client-Authentifizierung aktiviert, übermittelt der Client zusätzlich Zertifikatsinformationen.
• Der Server wählt die Verschlüsselungssuite und die ECDHE-Gruppe aus, generiert das Master-Secret aus dem ClientHello-Zufallswert und dem serverseitig generierten Zufallswert, kombiniert mit den ausgewählten Schlüsselanteilen, und sendet ein ServerHello mit den ausgewählten Parametern sowie eine ServerFinished-Nachricht. Das Serverzertifikat und alle nachfolgenden Handshake-Nachrichten werden verschlüsselt.
• Der Client überprüft das Serverzertifikat, generiert mithilfe seines eigenen Schlüssels und der Serverantwort denselben Master-Secret, sendet eine ClientFinished-Nachricht und beide Parteien beginnen mit dem verschlüsselten Datenaustausch der Anwendung. Der gesamte Handshake ist in einem einzigen Roundtrip abgeschlossen.

Hauptfunktionen von TLS 1.3

• Obligatorische Vorwärtsgeheimhaltung: TLS 1.3 erfordert ECDHE für alle Schlüsselaustausche, wodurch Forward Secrecy für jede Verbindung obligatorisch wird. Selbst wenn der langfristige private TLS-Schlüssel eines Servers später kompromittiert wird, können vergangene Sitzungen nicht entschlüsselt werden, da die temporären Sitzungsschlüssel verloren gegangen sind.
• Nur AEAD-Verschlüsselungssuiten zulässig: TLS 1.3 erlaubt nur fünf Verschlüsselungssammlungen, alle AEAD: AES-128-GCM-SHA256, AES-256-GCM-SHA384, ChaCha20-Poly1305-SHA256, AES-128-CCM-SHA256 und AES-128-CCM-8-SHA256. Sie alle bieten authentifizierte Verschlüsselung mit Erkennung von Manipulationen.
• Verschlüsselter Handshake: TLS 1.3 verschlüsselt mehr vom Handshake als TLS 1.2, einschließlich des Serverzertifikats. Passive Beobachter können nicht sehen, welches Zertifikat ein Server vorlegt.
• 0-RTT-Wiederaufnahme: Clients, die sich erneut mit einem Server verbinden, mit dem sie bereits zuvor verbunden waren, können Anwendungsdaten mit der ersten Nachricht (0-RTT) senden, wodurch die Latenz bei wiederkehrenden Verbindungen reduziert wird. Hinweis: 0-RTT-Daten sind anfällig für Replay-Angriffe und sollten nicht für nicht-idempotente Operationen (zustandsverändernde Anfragen wie Finanztransaktionen) verwendet werden.
• Algorithmusentfernung: TLS 1.3 entfernt RC4, DES, 3DES, MD5, SHA-1, RSA-Schlüsselaustausch, statisches DH, CBC-Verschlüsselungssuiten und TLS-Komprimierung – allesamt Angriffsvektoren in TLS 1.2-Implementierungen.

Vergleich: TLS 1.2 vs. TLS 1.3

Funktion	TLS 1.2	TLS 1.3	Auswirkungen
Hin- und Rückfahrten per Handschlag	2-RTT	1-RTT (0-RTT für die Wiederaufnahme der Sitzung)	TLS 1.3 ermöglicht einen schnelleren Verbindungsaufbau; 0-RTT birgt das Risiko von Replay-Angriffen.
Zulässige Verschlüsselungssammlungen	Hunderte, darunter auch schwache (RC4, DES, CBC)	Nur fünf AEAD-Suiten	TLS 1.2 erfordert eine sorgfältige Konfiguration, um schwache Sicherheitslücken zu vermeiden; TLS 1.3 ist von Grund auf sicher.
Schlüsselaustausch	RSA, DHE, ECDHE (alle unterstützt)	Nur ECDHE	TLS 1.3 bietet Vorwärtsgeheimhaltung für jede Verbindung; der RSA-Schlüsselaustausch von TLS 1.2 bietet keine Vorwärtsgeheimhaltung.
Vorwärtsgeheimnis	Optional (abhängig von der Verschlüsselungssuite)	Verpflichtend	TLS 1.3 schützt vergangene Sitzungen auch dann, wenn der Langzeitschlüssel kompromittiert wurde.
Handshake-Verschlüsselung	Das Zertifikat wurde während des Handshakes im Klartext angezeigt.	Das Zertifikat wurde im Handshake verschlüsselt.	TLS 1.3 verbirgt die Serveridentität vor passiven Beobachtern.
Algorithmusentfernung	Unterstützt RC4, MD5, SHA-1, 3DES (muss explizit deaktiviert werden)	Diese Algorithmen haben vollständig entfernt	TLS 1.3 eliminiert ganze Angriffsklassen (POODLE, BEAST, CRIME), indem die anfälligen Primitiven entfernt werden.
Sitzungswiederaufnahme	Sitzungs-IDs und Sitzungstickets	PSK mit 0-RTT-Option	TLS 1.3-Sitzungstickets bieten Vorwärtsgeheimhaltung; TLS 1.2-Sitzungstickets möglicherweise nicht.
Zertifikatsvalidierung	Einige Details zum Händedruck enthüllt	Der vollständige Handshake ist nach ServerHello verschlüsselt.	TLS 1.3 bietet eine verbesserte Vertraulichkeit für Zertifikatsinhalte
Leistung	Langsamer (2-RTT-Handshake)	Schneller (1-RTT; 0-RTT für Wiederaufnahme)	TLS 1.3 reduziert die Latenz, insbesondere in Netzwerken mit hoher Latenz und bei mobilen Clients.
NIST-Mandat	Erforderlich; nur FIPS-konforme Verschlüsselungssammlungen	Erforderlich ab dem 1. Januar 2024 (NIST SP 800-52 Rev. 2)	Beide sind für föderale Systeme erforderlich; TLS 1.3 ist der aktuelle Standard.

Auswahl der Cipher Suite für TLS 1.2

TLS 1.3 verwendet eine feste Liste von fünf AEAD-Verschlüsselungssammlungen; es gibt keine Auswahlmöglichkeit. TLS 1.2 unterstützt eine wesentlich größere Auswahl, darunter auch unsichere Optionen, die explizit deaktiviert werden müssen. Empfohlene TLS-1.2-Verschlüsselungssammlungen gemäß NIST SP 800-52 Rev. 2 (in absteigender Reihenfolge):

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (am besten: ECDHE Forward Secrecy, ECDSA-Zertifikat, AES-256-GCM AEAD)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ECDHE Forward Secrecy, RSA-Zertifikat, AES-256-GCM AEAD)
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

In TLS 1.2 sollten Sie explizit alle Suites deaktivieren, die RC4, DES, 3DES, NULL-Verschlüsselung, EXPORT, MD5 oder anonymen (anon) Schlüsselaustausch enthalten. Deaktivieren Sie außerdem alle RSA-Schlüsselaustausch-Suites (TLS_RSA_*), da diese keine Vorwärtsgeheimhaltung bieten. Vermeiden Sie nach Möglichkeit CBC-Suites aufgrund ihrer Anfälligkeit für Padding-Oracle-Angriffe (POODLE, BEAST).

Schwachstellen: TLS 1.2 und TLS 1.3

TLS 1.2 war Ziel mehrerer aufsehenerregender Angriffe, die zumeist die Unterstützung älterer Algorithmen ausnutzten:

• BEAST (2011): Die Vorhersagbarkeit des CBC IV wurde in TLS 1.0 ausgenutzt; in TLS 1.2 wurde dies teilweise durch die AES-GCM- und AEAD-Verschlüsselungssuiten gemildert.
• POODLE (2014): Ausgenutzt wurde ein SSL 3.0 Padding-Oracle durch Protokoll-Downgrade-Angriffe; behoben durch Deaktivierung von SSL 3.0 und TLS 1.0/1.1.
• Heartbleed (2014): OpenSSL-Speicher-Offenlegungsschwachstelle; nicht in der TLS-Spezifikation selbst, aber betroffen waren TLS 1.2-Implementierungen.
• Waschbärangriff (2020): Zeitbasierter Seitenkanalangriff auf den DHE-Schlüsselaustausch; die Verwendung von ECDHE durch TLS 1.3 eliminiert statisches DH vollständig.
• VERBRECHEN und VERSTÖSSE: nutzte die TLS-Komprimierung aus, um Geheimnisse zu extrahieren; TLS 1.3 entfernt die Komprimierung vollständig.

TLS 1.3 beseitigt die meisten dieser Angriffsflächen, indem es die anfälligen Primitiven (CBC-Modi, DH, Komprimierung, RSA-Schlüsselaustausch) entfernt, anstatt sie durch Patches zu umgehen. TLS 1.3 ist jedoch nicht immun gegen Implementierungsschwachstellen: Fehlkonfigurationen wie vorhersehbare Nonces in AES-GCM, unzureichender Schutz vor 0-RTT-Replay-Angriffen und schwache Schlüsselerzeugung können weiterhin Sicherheitslücken verursachen. Die NIST CVE-Datenbank dokumentiert Implementierungsfehler von TLS 1.3 in bestimmten Produkten. Regelmäßige Patches, Sicherheitsaudits und die Überprüfung der TLS-Konfiguration bleiben auch mit TLS 1.3 unerlässlich.

Bereitstellungsbeispiel: Migration von Enterprise-TLS

Ein Finanzdienstleistungsunternehmen mit 200 öffentlich zugänglichen Dienstleistungen implementiert eine strukturierte TLS-Migration:

1. Prüfung und Inventur: Die Überprüfung der TLS-Konfiguration aller 200 Endpunkte ergab: 12 Dienste verwenden noch TLS 1.0 oder 1.1; 85 Dienste nutzen TLS 1.2 mit RSA-Schlüsselaustausch-Verschlüsselungssuiten (ohne Forward Secrecy); 40 Dienste verwenden schwache CBC-Verschlüsselungssuiten; 63 Dienste nutzen bereits TLS 1.2 mit ECDHE-AEAD-Suites. TLS-Zertifikate: 140 RSA-2048, 60 ECDSA P-256.
2. Sofortige Deaktivierung von TLS 1.0/1.1: Die 12 Dienste, die TLS 1.0/1.1 verwenden, werden innerhalb von 30 Tagen aktualisiert, um diese Versionen zu deaktivieren, was das maximale Risiko in der Umgebung darstellt.
3. Aktivierung von TLS 1.3 auf allen Servern: TLS 1.3 ist auf allen Servern parallel zu TLS 1.2 aktiviert. Moderne Browser und API-Clients verwenden ab sofort TLS 1.3; ältere Clients nutzen weiterhin TLS 1.2.
4. Härtung der TLS 1.2-Verschlüsselungssuite: Alle RSA-Schlüsselaustausch- und CBC-Verschlüsselungssuiten sind in TLS 1.2-Konfigurationen deaktiviert. Lediglich die ECDHE-AEAD-Suites bleiben aktiviert und gewährleisten so die Vorwärtsgeheimhaltung für TLS 1.2-Verbindungen während der Übergangsphase.
5. Zertifikatsmigration: Bei der Zertifikatserneuerung werden RSA-2048-Zertifikate auf ECDSA P-256 migriert. CertSecure Manager Zur Automatisierung der Verlängerung und Bestandsverfolgung. ECDSA P-256 reduziert die Größe des TLS-Handshakes und das Zertifikatsdatenvolumen.
6. TLS 1.2 Ruhestandsplanung: Die Analyse der Zugriffsprotokolle zeigt, dass die Nutzung von TLS 1.2 mit den Client-Updates monatlich sinkt. Es ist geplant, TLS 1.2 zu deaktivieren, sobald die Nutzung unter 1 % der Verbindungen fällt; dies wird innerhalb von 12 Monaten erwartet.

Schlüsselverwaltungsabhängigkeiten für TLS

• TLS-Schutz des privaten Schlüssels: Der private Schlüssel des TLS-Servers ist die sensibelste Komponente einer TLS-Implementierung. Die Kompromittierung dieses Schlüssels ermöglicht die Entschlüsselung vergangener Sitzungen ohne Forward Secrecy (TLS 1.2 RSA-Schlüsselaustausch) und erlaubt Server-Impersonation. Speichern Sie private TLS-Schlüssel nach Möglichkeit in FIPS 140-2 Level 2 oder höher zertifizierten HSMs oder Hardware-Schlüsselspeichern. Siehe HSM als Service.
• Automatisierung des Zertifikatslebenszyklus: TLS-Zertifikate sind Maschinenidentitäten mit Ablaufdatum. Die manuelle Zertifikatsverwaltung in großem Umfang scheitert: Das CA/Browser Forum hat vorgeschrieben, die Gültigkeitsdauer von Zertifikaten bis 2029 auf 47 Tage zu reduzieren. CertSecure Manager Automatisiert die Erkennung, Erneuerung und Durchsetzung von Richtlinien für den gesamten TLS-Zertifikatbestand.
• Währung des Zertifikatsalgorithmus: Gemäß NIST IR 8547 ist die Abschaffung von RSA-2048-Zertifikaten nach 2030 vorgesehen. Organisationen sollten für alle Neuinstallationen ECDSA P-256-Zertifikate ausstellen und RSA-Zertifikate bei der Verlängerung migrieren.

Migrationsherausforderungen

• Inkompatibilität mit Altsystemen: Ältere Systeme, eingebettete Geräte und einige Middleware-Lösungen für Unternehmen unterstützen möglicherweise kein TLS 1.3. Diese müssen aktualisiert oder ersetzt werden, was für Branchen mit umfangreicher Legacy-Infrastruktur kostspielig sein kann.
• Entfernung des RSA-Schlüsselaustauschs: Die Abschaffung des RSA-Schlüsselaustauschs in TLS 1.3 führt zu Funktionsstörungen in Systemen, die darauf angewiesen sind. Netzwerk-Inspektionsgeräte, die TLS-Prüfungen durch Abfangen und erneutes Signieren von Verbindungen durchführen, müssen möglicherweise neu konfiguriert werden, um mit dem temporären Schlüsselaustausch von TLS 1.3 zu funktionieren.
• Änderungen am Handshake, die Anwendungsaktualisierungen erfordern: Die modifizierten Handshake- und Sitzungswiederaufnahmemechanismen von TLS 1.3 erfordern Aktualisierungen der Anwendungslogik in Systemen mit komplexen Authentifizierungs- oder Verbindungsabläufen.
• Ausgleich der Rückwärtskompatibilität während des Übergangs: Die Aufrechterhaltung von TLS 1.2 neben TLS 1.3 während der Migrationsphase ist notwendig, aber nur vorübergehend. TLS 1.2 mit ECDHE-AEAD-Verschlüsselungssuiten bietet während des Übergangs eine akzeptable Sicherheit; reines TLS 1.2 mit RSA-Schlüsselaustausch hingegen nicht und sollte deaktiviert werden, auch wenn TLS 1.2 weiterhin unterstützt wird.

Wie Verschlüsselungsberatung helfen kann

Bei Encryption Consulting unterstützen wir Unternehmen bei der Bewältigung von Herausforderungen im Zusammenhang mit der TLS-Migration mit maßgeschneiderten Lösungen, die auf ihre spezifische Infrastruktur abgestimmt sind. Unsere Dienstleistungen umfassen die Bewertung und Prüfung der TLS-Konfiguration (Identifizierung schwacher Verschlüsselungssammlungen, veralteter Protokollversionen und Zertifikatslücken in Ihrer Umgebung), die Migrationsplanung und -umsetzung (strukturierter Ansatz zur Aktivierung von TLS 1.3 und zur Ablösung schwächerer Konfigurationen mit minimalen Serviceunterbrechungen) sowie das Zertifikatslebenszyklusmanagement mit CertSecure Manager (Automatisierung von Erkennung, Erneuerung und Richtliniendurchsetzung für TLS-Zertifikate, einschließlich der zukünftigen 47-tägigen Zertifikatsgültigkeitsdauer). Unsere PKI-Dienstleistungen decken auch die Zertifizierungsstelleninfrastruktur ab, die TLS-Zertifikate ausstellt, und gewährleisten so ein ordnungsgemäßes Design und eine effektive Verwaltung der Vertrauenskette.

Fazit

TLS ist das grundlegende Protokoll zur Sicherung von Daten während der Übertragung über das Internet. TLS 1.3 ist der aktuelle Standard: schneller als TLS 1.2, obligatorische Vorwärtsgeheimhaltung, verschlüsselter Handshake und keine Altlasten durch veraltete Algorithmen. Unternehmen sollten TLS 1.3 umgehend auf allen Servern aktivieren, TLS 1.0 und 1.1 unverzüglich deaktivieren, TLS 1.2 während der Übergangsphase ausschließlich auf die ECDHE-AEAD-Suiten absichern und die Abschaltung von TLS 1.2 planen, sobald die Analyse älterer Clients bestätigt, dass es nicht mehr benötigt wird.

Die Zertifikatsverwaltung im TLS-Bereich gewinnt zunehmend an Bedeutung: Die ab 2029 geplante Gültigkeitsdauer von 47 Tagen erfordert ein automatisiertes Lebenszyklusmanagement anstelle der manuellen Nachverfolgung. Auch die Algorithmenentwicklung schreitet voran: RSA-2048-Zertifikate sollen nach 2030 abgeschafft werden, weshalb ECDSA P-256 die richtige Wahl für die Ausstellung aller neuen TLS-Zertifikate ist. Weiterführende Informationen finden Sie in unseren Leitfäden zu ECC und SSL/TLS-Zertifikaten.

Häufig gestellte Fragen

Was ist TLS und was schützt es?

TLS ist ein kryptografisches Protokoll, das Vertraulichkeit, Integrität und Authentifizierung für Netzwerkdaten gewährleistet. Es schützt Daten vor Abhören (Verschlüsselung), Manipulation (Integrität durch AEAD) und Identitätsdiebstahl (Serverzertifikatsauthentifizierung durch eine Zertifizierungsstelle). Es wird in HTTPS-, SMTP-, IMAP-, API-, Datenbank- und VPN-Protokollen verwendet.

Worin besteht der Unterschied zwischen TLS 1.2 und TLS 1.3?

TLS 1.3 ist schneller (1-RTT vs. 2-RTT), schreibt Forward Secrecy mittels ECDHE vor, erlaubt nur 5 AEAD-Verschlüsselungssuiten (gegenüber Hunderten in TLS 1.2, einschließlich schwacher), verschlüsselt mehr vom Handshake und entfernt alle Legacy-Algorithmen (RC4, 3DES, RSA-Schlüsselaustausch, CBC, Komprimierung), die in TLS 1.2 Angriffsvektoren darstellten.

Welche Verschlüsselungssammlungen sollten mit TLS 1.2 verwendet werden?

NIST SP 800-52 Rev. 2 empfiehlt ECDHE-AEAD-Suites: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 und TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 werden bevorzugt. Deaktivieren Sie nach Möglichkeit alle RSA-Schlüsselaustausch-Suites (ohne Forward Secrecy), alle RC4/DES/3DES-Suites, MD5/SHA-1-Suites und CBC-Suites.

Was ist Forward Secrecy und warum ist sie für TLS 1.3 erforderlich?

Forward Secrecy bedeutet, dass ein Angreifer, der den langfristigen privaten TLS-Schlüssel kompromittiert, vergangene Sitzungen nicht entschlüsseln kann, da Sitzungsschlüssel nur kurzlebig sind. TLS 1.3 schreibt dies mittels ECDHE für alle Verbindungen vor. Ohne Forward Secrecy (TLS 1.2 RSA-Schlüsselaustausch) könnte ein Angreifer, der den heutigen Datenverkehr aufzeichnet, diesen nachträglich entschlüsseln, wenn er später den privaten Schlüssel erlangt.

Wie sollten Organisationen von TLS 1.2 auf TLS 1.3 migrieren?

Aktivieren Sie TLS 1.3 auf allen Servern parallel zu TLS 1.2 (nicht anstelle davon). Deaktivieren Sie TLS 1.0 und 1.1 umgehend. Beschränken Sie TLS 1.2 auf die ECDHE-AEAD-Protokollsuiten. Überwachen Sie die Verteilung der TLS-Protokolle in den Zugriffsprotokollen. Planen Sie die Abschaltung von TLS 1.2, sobald die Überwachung eine minimale Nutzung durch aktive Clients anzeigt.

Welche Angriffe betreffen TLS 1.2 und wurden sie in TLS 1.3 behoben?

BEAST, POODLE und ähnliche Angriffe nutzten die Unterstützung von TLS 1.2 für CBC-Verschlüsselungssuiten und schwache Algorithmen aus. TLS 1.3 entfernt CBC-Verschlüsselungssuiten vollständig und eliminiert damit diese Angriffsarten. Raccoon zielte auf DHE ab; TLS 1.3 verwendet ausschließlich ECDHE. CRIME nutzte Komprimierung aus; TLS 1.3 entfernt die Komprimierung. TLS 1.3 ist zwar nicht immun gegen Implementierungsfehler, beseitigt aber die anfälligen Primitiven, die die meisten bekannten Angriffe auf Protokollebene ermöglichten.