TLS

Kurz: “Transport Layer Security” — das Protokoll, das verschlüsselte und authentifizierte Verbindungen im Internet ermöglicht, z. B. bei HTTPS. Nachfolger von SSL.

Genauer: TLS läuft zwischen Transport- und Anwendungsschicht und sorgt für drei Dinge: Vertraulichkeit (Verschlüsselung der Daten), Integrität (Erkennung von Manipulation) und Authentizität (Identitätsnachweis des Servers über ein Zertifikat). Der Verbindungsaufbau läuft über den TLS-Handshake, bei dem Client und Server sich auf eine Cipher Suite einigen und Schlüssel austauschen. Die eigentliche Datenübertragung nach dem Handshake läuft über das TLS Record Protocol.

Im Detail

Der TLS-Handshake läuft (vereinfacht, TLS 1.3) in wenigen Schritten ab, bevor überhaupt Nutzdaten fließen:

Client -> Server:  ClientHello (unterstützte Cipher Suites, Zufallszahl)
Server -> Client:  ServerHello + Zertifikat + Schlüsselaustausch-Daten
Client:            prüft Zertifikat gegen vertrauenswürdige CAs (Zertifikatskette)
Client & Server:   leiten daraus gemeinsam einen Sitzungsschlüssel ab
Ab jetzt:           alle Daten laufen verschlüsselt über das TLS Record Protocol

TLS 1.3 (aktueller Standard) schafft diesen Handshake in nur einer einzigen Roundtrip-Runde (ein Hin und Her zwischen Client und Server), während TLS 1.2 dafür noch zwei Runden brauchte — das macht jeden neuen Verbindungsaufbau spürbar schneller, was bei vielen kurzen HTTPS-Requests (typisch für moderne Webseiten mit vielen Assets) in Summe relevant ist.

Ein zentrales Missverständnis: TLS schützt die ÜBERTRAGUNG zwischen Client und Server, nicht die Daten davor oder danach. Ein Formular, das per HTTPS übertragen wird, ist während der Übertragung geschützt — sobald die Daten aber auf dem Server ankommen und z. B. unverschlüsselt in einer Datenbank landen, greift TLS nicht mehr; dafür braucht es zusätzlich Verschlüsselung “at rest” (siehe Verschlüsselung). Ebenso schützt TLS nicht davor, dass der Server selbst (oder wer auch immer Zugriff darauf hat) die Klartextdaten einsehen kann — TLS verhindert nur, dass ein Dritter AUF DEM WEG mitliest.

Mutual TLS als Erweiterung

Im normalen TLS-Handshake weist sich nur der Server per Zertifikat aus, der Client bleibt zunächst anonym (die eigentliche Authentifizierung des Nutzers passiert typischerweise erst später auf Anwendungsebene, z. B. per Login-Formular). Bei “Mutual TLS” (mTLS) weisen sich BEIDE Seiten per Zertifikat aus — üblich in Machine-to-Machine-Kommunikation zwischen internen Diensten, wo nicht nur der Server, sondern auch der anfragende Client kryptografisch zweifelsfrei identifiziert werden muss, bevor überhaupt eine Verbindung zustande kommt. In Microservice-Architekturen wird mTLS häufig automatisiert über einen “Service Mesh” (z. B. Istio) verwaltet, sodass jeder interne Dienst automatisch ein eigenes, kurzlebiges Zertifikat erhält, ohne dass Entwickler die Zertifikatsverwaltung manuell pflegen müssen.

Weitere Protokolle über TLS

TLS ist nicht auf HTTPS beschränkt — praktisch jedes Protokoll, das ursprünglich unverschlüsselt konzipiert wurde, hat inzwischen eine TLS-gesicherte Variante: SMTP-über-TLS für verschlüsselten E-Mail-Versand zwischen Mailservern, FTPS als verschlüsselte Variante des alten FTP, oder LDAPS für verschlüsselte Verzeichnisdienst-Abfragen. Das Muster ist dabei immer dasselbe: Das ursprüngliche Anwendungsprotokoll bleibt inhaltlich unverändert, läuft aber komplett innerhalb einer TLS-verschlüsselten Verbindung, statt direkt und unverschlüsselt über TCP — ein Grund, warum TLS oft als eigene, universelle “Sicherheitsschicht” beschrieben wird, die sich praktisch jedem bestehenden Protokoll nachträglich hinzufügen lässt.

0-RTT bei wiederkehrenden Verbindungen

TLS 1.3 führt eine weitere Beschleunigung namens “0-RTT” (Zero Round Trip Time) ein, für Verbindungen zu einem Server, mit dem bereits kürzlich eine Sitzung bestand: Der Client kann bei einer erneuten Verbindung bereits verschlüsselte Nutzdaten in seiner allerersten Nachricht mitschicken, ohne auf eine Antwort des Servers zu warten. Das spart einen kompletten Umlauf und beschleunigt wiederholte Verbindungen spürbar, bringt aber ein subtiles Sicherheitsrisiko mit sich: Ohne zusätzliche Schutzmaßnahmen könnte ein Angreifer eine abgefangene 0-RTT-Nachricht ein zweites Mal einspielen (Replay-Angriff) — Server, die 0-RTT unterstützen, müssen deshalb selbst sicherstellen, dass eine wiederholt eingespielte Anfrage keine schädlichen Doppel-Effekte auslöst (z. B. keine doppelte Zahlungsabbuchung).

Siehe auch: SSL, Handshake, HTTPS