Auch genannt: TLS
Transport Layer Security (TLS) ist ein Sicherheitsprotokoll für Datenverbindungen zwischen zwei Endpunkten, etwa einem Browser und einem Webserver. Es soll verhindern, dass Dritte übertragene Daten mitlesen, unbemerkt verändern oder Nachrichten im Namen eines anderen Kommunikationspartners fälschen. Die IETF beschreibt TLS 1.3 ausdrücklich als ein Protokoll für Client-Server-Kommunikation mit diesem Schutzanspruch.RFC 8446: TLS 1.3
TLS schützt den Übertragungsweg, nicht den Inhalt oder die Vertrauenswürdigkeit eines Dienstes als Ganzes. Eine korrekt abgesicherte Verbindung kann also weiterhin zu einer irreführenden Website führen oder Daten an einen Dienst übertragen, der sie später schlecht verarbeitet. Umgekehrt ersetzt ein Passwort oder eine Anmeldung keine geschützte Verbindung: Sie sind andere Bausteine der Sicherheit.
Wer eine Website über eine sichere Adresse aufruft, baut vor der ersten fachlichen Anfrage in der Regel zunächst eine TLS-Verbindung auf. Der Browser und der Server einigen sich dabei auf Sicherheitsparameter und erzeugen Schlüssel für diese Verbindung. Erst danach werden die Daten der Anwendung übertragen. Bei HTTP über TLS sendet der Client nach abgeschlossenem Handshake seine HTTP-Anfrage; die HTTP-Daten laufen als TLS-Anwendungsdaten.RFC 2818: HTTP Over TLS
Das Bild eines geschützten Tunnels ist hilfreich, aber unvollständig. TLS verschlüsselt nicht einfach nur eine Nachricht mit einem festen Schloss. Die beteiligten Seiten handeln den Schutz für eine konkrete Verbindung aus. Der Server weist sich dabei typischerweise mit einem Zertifikat aus; der Client prüft, ob die vorgelegte Identität zu dem Namen passt, den er erreichen wollte. Diese Namensprüfung ist wichtig, weil Verschlüsselung allein nicht belegt, dass der Browser mit dem beabsichtigten Server spricht.
Der Ablauf beginnt mit einer Nachricht des Clients, die unter anderem unterstützte TLS-Versionen und kryptografische Möglichkeiten nennt. Der Server antwortet mit den gewählten Parametern. In TLS 1.3 umfasst der Handshake außerdem Serverparameter sowie einen Authentisierungsblock mit Zertifikat, Zertifikatsnachweis und der Nachricht „Finished“.RFC 8446, Abschnitt 4
Aus dem vereinbarten Schlüsselaustausch leiten beide Seiten passende geheime Verkehrsschlüssel ab, ohne diese Schlüssel als Klartext über das Netz zu senden. Anschließend schützt die TLS-Record-Schicht die einzelnen Datenabschnitte. Sie verbindet Verschlüsselung mit einer Integritätsprüfung, sodass Manipulationen erkannt werden sollen. Der genaue Schutz hängt von Version, Implementierung und ausgehandelten Algorithmen ab; deshalb ist TLS kein Anlass, Zertifikatswarnungen zu ignorieren oder veraltete Konfigurationen beizubehalten.
Das Zertifikat ist dabei kein Beweis für die Qualität eines Unternehmens. Es bindet im technischen Vertrauensmodell einen öffentlichen Schlüssel an eine Identität und wird im Rahmen einer Zertifikatskette geprüft. Für Webverbindungen gehört zusätzlich die Prüfung des Hostnamens dazu. Ohne diesen Abgleich könnte ein Angreifer zwar ein eigenes Zertifikat vorlegen, aber nicht überzeugend als die angefragte Domain auftreten.RFC 9325: TLS/DTLS Recommendations
TLS verfolgt drei zentrale Schutzziele: Vertraulichkeit, Integrität und Authentisierung der Gegenstelle, soweit diese über Zertifikate oder andere Verfahren erfolgt. Vertraulichkeit bedeutet, dass Mitlesende den Nutzinhalt nicht ohne Weiteres verstehen sollen. Integrität bedeutet, dass veränderte Daten erkannt werden sollen. Die Authentisierung hilft dem Client einzuschätzen, ob er den erwarteten Server erreicht. Die IETF nennt diese Eigenschaften als typische Ziele von TLS-Deployments.RFC 9325, Abschnitt 1
Was TLS nicht leistet, ist genauso wichtig: Es entfernt keine Schadsoftware vom Endgerät, prüft nicht, ob ein Online-Shop seriös ist, und entscheidet nicht, welche Daten eine Anwendung speichern darf. Es verschlüsselt auch nicht automatisch alle Metadaten einer Kommunikation. Für die praktische Sicherheit kommen daher weitere Maßnahmen hinzu: aktuelle Software, sorgfältige Serverkonfiguration, gültige Zertifikate, sichere Anwendungslogik und ein wachsamer Umgang mit Warnmeldungen.
Eine Person öffnet https://shop.beispiel.de in einem WLAN. Der Browser löst zunächst die Domain auf und stellt anschließend eine Verbindung zum Server her. Im TLS-Handshake kontrolliert er unter anderem, ob das Serverzertifikat für den aufgerufenen Namen geeignet und vertrauenswürdig ist. Bei einem problematischen Zertifikat zeigt der Browser eine Warnung; diese Warnung ist kein bloßes Komfortproblem, sondern betrifft die Serveridentität.
Besteht die Prüfung, können Produktseite, Warenkorb und Anmeldung über die geschützte Verbindung übertragen werden. Das ist insbesondere in fremden oder öffentlichen Netzen relevant, weil andere Teilnehmer den Inhalt nicht einfach mitlesen oder unterwegs verändern sollen. Dennoch bleibt die Person dafür verantwortlich, die richtige Adresse und den Anbieter zu prüfen. Ein Schloss-Symbol zeigt eine geschützte Transportverbindung an, keine Empfehlung für den Shop.
Aktuelle Empfehlungen raten dazu, alte Protokollversionen nicht mehr auszuhandeln. RFC 8996 stuft TLS 1.0 und TLS 1.1 als überholt ein; beide unterstützen zentrale heutige Schutzmechanismen nicht ausreichend und vergrößern durch zusätzliche Versionen das Risiko von Fehlkonfigurationen.RFC 8996: Deprecating TLS 1.0 and TLS 1.1 RFC 9325 verfolgt ebenfalls das Ziel, den Einsatz von TLS 1.3 zu fördern, lässt aber TLS 1.2 dort relevant, wo eine Umstellung noch nicht praktikabel ist.RFC 9325: TLS/DTLS Recommendations
Für Betreiber folgt daraus keine einzelne magische Einstellung. Sie müssen die tatsächlich unterstützten Versionen, Zertifikate und kryptografischen Verfahren in ihrer Umgebung prüfen und Software aktuell halten. Für Nutzende ist die wichtige Konsequenz einfacher: Zertifikatswarnungen nicht wegklicken, Browser aktuell halten und sensible Eingaben nur an der erwarteten Adresse vornehmen.
TLS ist das allgemeine Sicherheitsprotokoll für eine Verbindung. HTTPS bezeichnet die Anwendung von HTTP über TLS: HTTP ist ein zustandsloses Anwendungsschicht-Protokoll für Anfragen und Antworten, TLS schützt dabei die Verbindung.RFC 9110: HTTP Semantics Eine Domain ist wiederum der lesbare Name, zu dem der Browser eine Verbindung aufbauen möchte. Das Serverzertifikat und die Hostnamenprüfung verbinden diesen Namen mit der erwarteten Gegenstelle.
Auch TLS und die allgemeine Verschlüsselung sind nicht deckungsgleich. Verschlüsselung ist ein übergeordneter Mechanismus, mit dem Daten unlesbar gemacht werden können. TLS kombiniert Verschlüsselung mit einem Handshake, Schlüsselaustausch, Integritätsschutz und – bei der üblichen Webnutzung – der Prüfung einer Serveridentität.