TLS (Transport Layer Security)

Transport Layer Security (TLS) ist das zentrale Protokoll für verschlüsselte Kommunikation im Internet. Es sichert die Datenübertragung zwischen Client und Server, sodass Dritte den Inhalt weder mitlesen noch unbemerkt verändern können. TLS ist der direkte Nachfolger von SSL (Secure Sockets Layer) und wird umgangssprachlich häufig noch als SSL bezeichnet, obwohl alle SSL-Versionen seit Jahren als unsicher gelten und nicht mehr verwendet werden sollten.

Protokollversionen im Überblick

Die Entwicklung von TLS begann mit SSL 2.0 (1995) und SSL 3.0 (1996), die beide schwerwiegende Designfehler aufweisen. TLS 1.0 (1999) und TLS 1.1 (2006) waren Verbesserungen, gelten heute aber ebenfalls als veraltet — die IETF hat beide Versionen mit RFC 8996 offiziell für obsolet erklärt. TLS 1.2 (2008) ist weiterhin weit verbreitet und gilt bei korrekter Konfiguration als sicher. TLS 1.3 (2018, RFC 8446) ist der aktuelle Standard und bietet erhebliche Verbesserungen: einen schnelleren Handshake, die Entfernung unsicherer Algorithmen und verpflichtende Forward Secrecy.

Der TLS-Handshake

Bevor verschlüsselte Daten fließen können, müssen sich Client und Server auf eine gemeinsame Cipher-Suite einigen und Schlüssel austauschen. In TLS 1.2 erfordert dieser Handshake zwei Roundtrips (2-RTT): Der Client sendet zunächst eine Liste unterstützter Cipher-Suites, der Server wählt eine aus und sendet sein Zertifikat, anschließend wird der Sitzungsschlüssel ausgehandelt. TLS 1.3 reduziert dies auf einen einzigen Roundtrip (1-RTT) und unterstützt sogar 0-RTT-Resumption für wiederkehrende Verbindungen. Diese Beschleunigung ist nicht nur ein Performance-Vorteil, sondern verringert auch die Angriffsfläche, da weniger unverschlüsselte Nachrichten ausgetauscht werden.

Cipher-Suites und Verschlüsselungsverfahren

Eine Cipher-Suite ist die Kombination aus Schlüsselaustausch, Authentifizierung, symmetrischer Verschlüsselung und Integritätsprüfung. In TLS 1.3 wurden unsichere Optionen konsequent entfernt: Es gibt keinen RSA-Key-Exchange mehr, keinen CBC-Mode und keine MD5- oder SHA-1-basierte Integritätsprüfung. Stattdessen kommen ausschließlich AEAD-Verfahren (Authenticated Encryption with Associated Data) zum Einsatz — konkret AES-128-GCM, AES-256-GCM und ChaCha20-Poly1305. Diese Verfahren kombinieren Verschlüsselung und Integritätsprüfung in einem einzigen Schritt und sind dadurch sowohl sicherer als auch effizienter als die Kombination aus separater Verschlüsselung und HMAC.

Forward Secrecy

Forward Secrecy (Perfect Forward Secrecy, PFS) ist eine Eigenschaft des Schlüsselaustauschs, die sicherstellt, dass vergangene Sitzungen nicht nachträglich entschlüsselt werden können — selbst wenn der private Serverschlüssel kompromittiert wird. Erreicht wird dies durch ephemere Schlüssel: Für jede Verbindung erzeugen Client und Server ein einmaliges Schlüsselpaar über ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), das nach Sitzungsende verworfen wird. In TLS 1.3 ist Forward Secrecy verpflichtend. In TLS 1.2 muss sie durch die Wahl geeigneter Cipher-Suites (ECDHE-basiert) explizit sichergestellt werden. Ohne PFS könnte ein Angreifer, der Netzwerkverkehr aufzeichnet, diesen Jahre später entschlüsseln, wenn er Zugang zum Serverschlüssel erlangt.

Zertifikate und Vertrauenskette

TLS-Verschlüsselung allein schützt nicht vor Man-in-the-Middle-Angriffen — dafür ist die Authentifizierung des Servers über X.509-Zertifikate erforderlich. Eine Zertifizierungsstelle (Certificate Authority, CA) bestätigt die Identität des Servers. Der Browser prüft die Vertrauenskette vom Serverzertifikat über Zwischenzertifikate bis zur Root-CA. Fehler in dieser Kette — abgelaufene Zertifikate, falsche Domainnamen oder fehlende Zwischenzertifikate — führen zu Browserwarnungen und Vertrauensverlust bei Nutzern.

TLS und E-Mail-Sicherheit

TLS schützt nicht nur Webverbindungen, sondern auch die E-Mail-Kommunikation. STARTTLS ermöglicht die opportunistische Verschlüsselung zwischen Mailservern, während MTA-STS (Mail Transfer Agent Strict Transport Security) eine TLS-Verschlüsselung erzwingen kann. Zusammen mit DNSSEC und DANE-TLSA lässt sich die Transportverschlüsselung für E-Mail kryptografisch absichern. Unternehmen sollten neben der TLS-Konfiguration des Webservers auch die E-Mail-Authentifizierung prüfen, da unverschlüsselter E-Mail-Transport ein häufig übersehenes Einfallstor darstellt.

Regulatorische Anforderungen

Verschlüsselung nach dem Stand der Technik ist keine freiwillige Best Practice, sondern eine regulatorische Pflicht. Die DSGVO nennt Verschlüsselung in Art. 32 explizit als technisch-organisatorische Maßnahme. Die NIS2-Richtlinie fordert von betroffenen Unternehmen ein Risikomanagement, das Verschlüsselung und Zugangskontrollen umfasst. Der BSI IT-Grundschutz empfiehlt in seinen Bausteinen die ausschließliche Nutzung von TLS 1.2 und 1.3 mit sicheren Cipher-Suites. Veraltete Protokollversionen oder unsichere Cipher-Suites können bei einem Audit als Abweichung gewertet werden.

Häufige Fehlkonfigurationen

In der Praxis finden wir regelmäßig vermeidbare TLS-Schwächen: aktiviertes TLS 1.0/1.1 auf Webservern und Load Balancern, fehlende Forward Secrecy durch RSA-Key-Exchange in TLS 1.2, schwache Cipher-Suites mit CBC-Mode oder RC4, fehlendes HSTS, wodurch Downgrade-Angriffe möglich werden, und OCSP Stapling, das nicht konfiguriert ist. Jede dieser Schwächen einzeln mag beherrschbar erscheinen — in Kombination ergeben sie jedoch eine Angriffsfläche, die automatisierte Scanner innerhalb von Sekunden identifizieren.

Praxistipp

Ob Ihre TLS-Konfiguration dem aktuellen Stand der Technik entspricht, können Sie mit dem kostenlosen TLS-Cipher-Check in wenigen Minuten prüfen. Das Tool analysiert unterstützte Protokollversionen, Cipher-Suites, Forward Secrecy, HSTS-Konfiguration und bekannte Schwachstellen — basierend auf der SSL Labs API von Qualys. Ergänzend zeigt der SSL/TLS-Zertifikat Check, ob Ihr Zertifikat gültig ist, wann es abläuft und welche Domains es abdeckt.