TLS einfach erklärt: So funktioniert Transport Layer Security

Wenn du eine Website über HTTPS öffnest, eine App mit einem Server kommuniziert oder dein E-Mail-Programm Nachrichten abruft, steckt häufig TLS dahinter. Transport Layer Security schützt Daten während der Übertragung vor Mitlesen und Manipulation. Gleichzeitig hilft das Verfahren dabei zu prüfen, ob du tatsächlich mit dem vorgesehenen Server verbunden bist.

TLS arbeitet dabei weitgehend unsichtbar im Hintergrund. Browser, Apps und Server handeln die Verschlüsselung automatisch aus, bevor die eigentlichen Daten übertragen werden. Trotzdem lohnt es sich zu verstehen, was dabei passiert. Denn eine TLS-Verbindung schützt zwar den Transportweg, macht eine Website oder einen Onlinedienst aber nicht automatisch vertrauenswürdig.

Was ist TLS?

TLS steht für „Transport Layer Security“ und ist ein kryptografisches Protokoll zur Absicherung von Netzwerkverbindungen. Es wird zwischen zwei Kommunikationspartnern eingesetzt, beispielsweise zwischen deinem Browser und einem Webserver.

Eine TLS-Verbindung soll drei zentrale Aufgaben erfüllen:

• Vertraulichkeit: Übertragene Daten werden verschlüsselt und sollen von Dritten nicht mitgelesen werden können.
• Integrität: Manipulationen an übertragenen Daten sollen erkannt werden.
• Authentifizierung: Der Client kann prüfen, mit welchem Server er verbunden ist. Eine Authentifizierung des Clients ist ebenfalls möglich, wird im normalen Webbetrieb aber selten über ein Client-Zertifikat durchgeführt.

Der Begriff „Transport Layer Security“ kann dabei etwas irreführend sein. TLS ist nicht einfach ein Protokoll der Transportschicht beziehungsweise der OSI-Schicht 4. Klassisches TLS arbeitet normalerweise oberhalb von TCP und unterhalb eines Anwendungsprotokolls wie HTTP.

Bei moderner Kommunikation über QUIC sieht die technische Umsetzung etwas anders aus. Dort wird TLS 1.3 direkt als Bestandteil des Verbindungsaufbaus genutzt. Das ist beispielsweise bei HTTP/3 der Fall.

Was schützt eine TLS-Verbindung?

Eine TLS-Verbindung bildet einen geschützten Kommunikationskanal zwischen zwei Endpunkten. Bei einer HTTPS-Verbindung sind das normalerweise dein Browser und der Webserver.

Angenommen, du meldest dich auf einer Website an. Ohne Transportverschlüsselung könnten Benutzername, Passwort und weitere Daten theoretisch im Klartext über beteiligte Netzwerke übertragen werden. TLS sorgt dafür, dass daraus verschlüsselte Daten werden, die ohne die passenden Schlüssel nicht sinnvoll gelesen werden können.

TLS schützt gleichzeitig vor unbemerkten Änderungen während der Übertragung. Würde ein Angreifer versuchen, verschlüsselte Datenpakete zu verändern, schlägt die Integritätsprüfung fehl.

Dazu kommt die Authentifizierung des Servers. Dein Browser prüft dessen digitales Zertifikat und kontrolliert unter anderem, ob es für den aufgerufenen Namen gültig ist und ob eine vertrauenswürdige Zertifikatskette vorhanden ist.

Was TLS nicht leisten kann

Die Grenzen dieser Absicherung sind mindestens genauso wichtig. TLS schützt in erster Linie die Verbindung zwischen zwei Endpunkten.

Ist dein PC beispielsweise mit Schadsoftware infiziert, kann TLS das Auslesen deiner Daten auf diesem Gerät nicht verhindern. Auch der empfangende Webserver kann die entschlüsselten Informationen natürlich verarbeiten.

Eine verschlüsselte Verbindung bedeutet ebenfalls nicht, dass der Betreiber einer Website automatisch seriös ist. Auch eine Phishing-Seite kann ein gültiges TLS-Zertifikat besitzen. Das Zertifikat bestätigt in erster Linie die technische Identität beziehungsweise Zuordnung des angesprochenen Dienstes und ermöglicht eine verschlüsselte Verbindung.

So funktioniert der TLS-Handshake

Bevor verschlüsselte Nutzdaten übertragen werden können, müssen Client und Server gemeinsame Sicherheitsparameter festlegen. Dieser Vorgang wird als TLS-Handshake bezeichnet.

Bei aktuellem TLS 1.3 läuft der Ablauf vereinfacht folgendermaßen ab.

1. Der Client startet die Verbindung

Der Client sendet zunächst eine „ClientHello“-Nachricht. Darin teilt er dem Server unter anderem mit, welche TLS-Versionen und kryptografischen Verfahren er unterstützt.

Bei TLS 1.3 enthält diese Nachricht normalerweise bereits Informationen für die spätere kryptografische Schlüsseleinigung. Dadurch lässt sich der Verbindungsaufbau gegenüber älteren TLS-Versionen beschleunigen.

2. Der Server antwortet

Der Server schickt eine „ServerHello“-Nachricht zurück und legt damit die gemeinsam verwendbaren Parameter fest.

Anschließend weist er normalerweise seine Identität mit einem digitalen Zertifikat nach. Zusätzlich signiert der Server Bestandteile des Handshakes mit seinem privaten Schlüssel. Der Client kann diese Signatur mithilfe des öffentlichen Schlüssels aus dem Zertifikat überprüfen.

Damit lässt sich feststellen, ob der Kommunikationspartner tatsächlich über den zum Zertifikat gehörenden privaten Schlüssel verfügt.

3. Beide Seiten leiten gemeinsame Schlüssel ab

Ein häufiger Irrtum ist, dass der Client einfach einen fertigen Sitzungsschlüssel mit dem öffentlichen Schlüssel des Servers verschlüsselt und an diesen schickt. Dieser Ablauf entspricht nicht dem üblichen Schlüsselaustausch von TLS 1.3.

Client und Server führen stattdessen eine kryptografische Schlüsseleinigung durch. Dabei werden gemeinsame geheime Werte erzeugt beziehungsweise abgeleitet, ohne dass der spätere symmetrische Verkehrsschlüssel einfach über das Netzwerk übertragen werden muss.

TLS 1.3 verwendet dafür moderne Verfahren, typischerweise auf Basis von Diffie-Hellman beziehungsweise Elliptic Curve Diffie-Hellman.

4. Der Handshake wird geprüft

Beide Seiten berechnen aus dem bisherigen Handshake Prüfdaten und bestätigen damit, dass der Verbindungsaufbau nicht manipuliert wurde.

Ist diese Prüfung erfolgreich abgeschlossen, stehen die benötigten Sitzungsschlüssel bereit. Ab diesem Zeitpunkt können die eigentlichen Anwendungsdaten geschützt übertragen werden.

Warum TLS symmetrische und asymmetrische Kryptografie kombiniert

Beim TLS-Verbindungsaufbau kommen unterschiedliche kryptografische Techniken zum Einsatz. Sie erfüllen verschiedene Aufgaben.

Asymmetrische Kryptografie eignet sich unter anderem zur Authentifizierung. Ein Server besitzt dabei einen privaten Schlüssel, der geheim bleiben muss, und einen dazugehörigen öffentlichen Schlüssel.

Für den eigentlichen Datenverkehr werden dagegen symmetrische Verfahren eingesetzt. Client und Server besitzen passende Sitzungsschlüssel, mit denen Daten sehr effizient verschlüsselt und entschlüsselt werden können.

TLS 1.3 nutzt dabei sogenannte AEAD-Verfahren. AEAD steht für „Authenticated Encryption with Associated Data“. Verschlüsselung und Integritätsschutz werden dabei miteinander kombiniert.

Zu den für TLS 1.3 vorgesehenen Verfahren gehören beispielsweise AES-GCM und ChaCha20-Poly1305. Welches Verfahren tatsächlich verwendet wird, handeln Client und Server während des Verbindungsaufbaus aus.

Welche Aufgabe hat ein TLS-Zertifikat?

Ein TLS-Zertifikat verbindet eine Identität mit einem öffentlichen Schlüssel. Bei Websites handelt es sich normalerweise um ein X.509-Zertifikat.

Wenn du eine HTTPS-Seite öffnest, prüft dein Browser mehrere Punkte. Dazu gehören unter anderem:

• Passt das Zertifikat zum aufgerufenen Hostnamen?
• Befindet sich das Zertifikat innerhalb seines gültigen Zeitraums?
• Lässt sich eine vertrauenswürdige Zertifikatskette aufbauen?
• Ist die kryptografische Signatur der Zertifikatskette gültig?

Zertifikate werden häufig von sogenannten Certificate Authorities, kurz CA, ausgestellt. Browser und Betriebssysteme besitzen Vertrauensspeicher mit Stammzertifikaten anerkannter Zertifizierungsstellen.

Der Webserver sendet beim Verbindungsaufbau normalerweise sein eigenes Zertifikat sowie gegebenenfalls benötigte Zwischenzertifikate. Der Browser kann daraus eine Zertifikatskette bis zu einer vertrauenswürdigen Stammzertifizierungsstelle bilden.

Warum trotzdem oft von SSL-Zertifikaten gesprochen wird

Bei Hosting-Anbietern und in Weboberflächen findest du noch häufig den Ausdruck „SSL-Zertifikat“. Technisch ist dieser Begriff inzwischen überholt.

Moderne Websites verwenden TLS und kein altes SSL-Protokoll. Das Zertifikat selbst ist außerdem kein spezielles „SSL-Zertifikat“. Es handelt sich normalerweise um ein X.509-Zertifikat, das für die Authentifizierung innerhalb einer TLS-Verbindung eingesetzt wird.

Der Ausdruck SSL-Zertifikat hat sich im allgemeinen Sprachgebrauch allerdings so stark etabliert, dass er weiterhin häufig verwendet wird.

TLS und SSL: Wo liegt der Unterschied?

SSL steht für „Secure Sockets Layer“ und war der Vorgänger von TLS. Die letzten öffentlich eingesetzten SSL-Versionen sind schon seit langer Zeit technisch überholt und dürfen nicht mit einer modernen TLS-Verbindung gleichgesetzt werden.

Wenn heute jemand von „SSL-Verschlüsselung“ spricht, ist damit in vielen Fällen eigentlich TLS gemeint.

Das ist bei Produktnamen oder Hosting-Paketen nicht unbedingt problematisch. Bei der technischen Konfiguration sollte die Unterscheidung aber eindeutig sein. SSL 2.0 und SSL 3.0 sowie TLS 1.0 und TLS 1.1 gehören nicht mehr in eine moderne Serverkonfiguration.

TLS 1.2 und TLS 1.3 im Vergleich

TLS 1.2 erschien 2008 und hat sich über viele Jahre als Standard für verschlüsselte Internetverbindungen etabliert. Bei einer sorgfältigen Konfiguration kann TLS 1.2 weiterhin sicher eingesetzt werden.

TLS 1.3 wurde technisch deutlich aufgeräumt. Veraltete kryptografische Verfahren wurden entfernt und der Handshake vereinfacht. Dadurch sinkt die Gefahr, dass unsichere Altverfahren versehentlich weiterhin angeboten werden.

Ein weiterer Unterschied betrifft die Cipher Suites. Bei TLS 1.2 beschreibt eine Cipher Suite mehrere Bestandteile der Verbindung, darunter Verschlüsselung, Authentifizierung und Schlüsselaustausch.

TLS 1.3 trennt diese Aufgaben stärker voneinander. Die dort definierten Cipher Suites legen im Wesentlichen das AEAD-Verschlüsselungsverfahren und die für die Schlüsselableitung verwendete Hashfunktion fest.

Auch der Verbindungsaufbau wurde optimiert. Eine normale neue TLS-1.3-Verbindung kann unter günstigen Bedingungen mit weniger Kommunikationsschritten aufgebaut werden als viele ältere TLS-Verbindungen.

Für bereits bekannte Gegenstellen kennt TLS 1.3 außerdem Verfahren zur Wiederaufnahme einer früheren Sitzung. In bestimmten Fällen ist sogenanntes 0-RTT möglich, bei dem Anwendungsdaten besonders früh übertragen werden. 0-RTT besitzt allerdings besondere Sicherheitsanforderungen, weil solche Daten prinzipiell wiederholt werden können. Es eignet sich deshalb nicht bedenkenlos für jede Art von Anfrage.

Welche TLS-Version sollte verwendet werden?

Für aktuelle Systeme sind TLS 1.2 und TLS 1.3 relevant. Wenn Client und Server TLS 1.3 unterstützen, sollte diese Version bevorzugt werden. Das Bundesamt für Sicherheit in der Informationstechnik empfiehlt beide Versionen, wobei TLS 1.3 bevorzugt eingesetzt werden sollte.

TLS 1.0 und TLS 1.1 gelten dagegen als veraltet und sollten nicht mehr ausgehandelt werden. Das gilt ebenso für SSL 2.0 und SSL 3.0.

Interessant ist dabei eine Änderung aus dem Jahr 2026: TLS 1.3 selbst trägt weiterhin die Versionsnummer 1.3, die technische Spezifikation wurde aber überarbeitet. Seit Juli 2026 beschreibt RFC 9846 die aktuelle TLS-1.3-Spezifikation und ersetzt den ursprünglichen RFC 8446 aus dem Jahr 2018.

Das bedeutet nicht, dass mit RFC 9846 ein „TLS 1.4“ erschienen wäre. Die Protokollversion bleibt TLS 1.3. Der Standard wurde präzisiert und aktualisiert.

Für normale Anwender gibt es deshalb meistens nichts manuell einzustellen. Ein aktueller Browser und ein ordentlich konfigurierter Server handeln selbstständig eine geeignete gemeinsame TLS-Version aus.

TLS und HTTPS sind nicht dasselbe

TLS und HTTPS werden häufig in einem Atemzug genannt, bezeichnen aber unterschiedliche Dinge.

HTTP ist das Protokoll, mit dem Browser und Webserver Webinhalte austauschen. Wird HTTP durch TLS geschützt, entsteht HTTPS.

Vereinfacht lässt sich das so darstellen:

HTTP + TLS = HTTPS

TLS ist allerdings nicht auf Websites beschränkt. Andere Anwendungsprotokolle können ebenfalls TLS verwenden.

HTTPS ist damit ein besonders bekannter Einsatzbereich von TLS, aber nicht dessen einzige Anwendung.

Wo wird TLS eingesetzt?

TLS begegnet dir an vielen Stellen, selbst wenn du davon nichts bemerkst.

Websites

Der bekannteste Anwendungsfall ist HTTPS. Dabei schützt TLS die Kommunikation zwischen Browser und Webserver.

Anmeldedaten, Formulare, Cookies und übertragene Webseiteninhalte werden dadurch während des Transports verschlüsselt.

E-Mail

TLS kann Verbindungen zwischen E-Mail-Programmen und Mailservern absichern. Das betrifft beispielsweise SMTP zum Versenden sowie IMAP oder POP3 zum Abrufen von Nachrichten.

Dabei darf Transportverschlüsselung nicht mit Ende-zu-Ende-Verschlüsselung verwechselt werden. Eine per TLS transportierte E-Mail liegt auf beteiligten Mailservern normalerweise wieder entschlüsselt vor. Für eine echte Ende-zu-Ende-Verschlüsselung des Nachrichteninhalts werden andere Verfahren benötigt.

Auch zwischen Mailservern kann TLS eingesetzt werden. Wie verbindlich die Verschlüsselung dort abgesichert ist, hängt jedoch vom verwendeten Verfahren und von der jeweiligen Serverkonfiguration ab.

Apps und Programmierschnittstellen

Viele Programme kommunizieren im Hintergrund über HTTPS mit Webdiensten und APIs. Auch dabei übernimmt TLS den Schutz des Transportwegs.

Das betrifft Desktopprogramme genauso wie Smartphone-Apps, Cloud-Dienste, Synchronisationsprogramme und viele andere Netzwerkdienste.

HTTP/3 und QUIC

HTTP/3 verwendet nicht mehr die klassische Kombination aus HTTP, TLS und TCP. Stattdessen basiert HTTP/3 auf QUIC.

QUIC integriert TLS 1.3 in seinen Verbindungsaufbau. Die bekannten Sicherheitsziele von TLS wie Authentifizierung und das Ableiten kryptografischer Schlüssel bleiben dabei erhalten.

Weitere Netzwerkprotokolle

TLS kann auch in zahlreichen anderen Anwendungen eingesetzt werden. Bei VoIP schützt TLS beispielsweise je nach Protokoll die Signalisierung. Die eigentlichen Audio- oder Videodaten können dagegen über andere verschlüsselte Verfahren wie SRTP transportiert werden.

Deshalb ist die pauschale Aussage „VoIP wird mit TLS verschlüsselt“ zu ungenau. Entscheidend ist immer, welcher Teil der Kommunikation über welches Protokoll abgesichert wird.

Wie erkennst du TLS im Browser?

Bei einer normalen Website ist HTTPS der wichtigste sichtbare Hinweis. Die Adresse beginnt mit https://, auch wenn aktuelle Browser diesen Teil der URL teilweise nur noch verkürzt darstellen.

Die genaue Darstellung einer sicheren Verbindung unterscheidet sich zwischen Browsern und Browser-Versionen. Das früher verbreitete Schloss-Symbol ist deshalb kein verlässliches allgemeines Erkennungsmerkmal mehr.

Über die Website- beziehungsweise Verbindungsinformationen des Browsers kannst du normalerweise weitere Details zur Verbindung und zum Zertifikat aufrufen.

Entscheidender ist, ob der Browser eine Zertifikatswarnung anzeigt. Bei abgelaufenen Zertifikaten, falschen Hostnamen oder anderen schwerwiegenden Problemen wird der Aufruf einer Website normalerweise deutlich beanstandet.

Eine solche Warnung solltest du besonders bei Anmeldeseiten, Onlineshops oder anderen Seiten mit vertraulichen Daten nicht einfach ignorieren.

Warum kann eine TLS-Verbindung fehlschlagen?

Damit eine TLS-Verbindung zustande kommt, müssen mehrere Bedingungen erfüllt sein. Fehler können deshalb sowohl auf dem Client als auch auf dem Server entstehen.

Typische Ursachen sind:

• ein abgelaufenes oder noch nicht gültiges Zertifikat,
• ein Zertifikat, das nicht zum aufgerufenen Servernamen passt,
• eine unvollständige oder nicht vertrauenswürdige Zertifikatskette,
• keine gemeinsam unterstützte TLS-Version,
• keine kompatiblen kryptografischen Verfahren,
• eine falsche Uhrzeit oder ein falsches Datum auf dem Client,
• veraltete Betriebssysteme oder Programme,
• eine fehlerhafte Serverkonfiguration,
• ein Proxy oder eine Sicherheitssoftware, die TLS-Verbindungen untersucht.

Gerade bei sehr alten Geräten kann die fehlende Unterstützung moderner TLS-Versionen zum Problem werden. Ein Server, der nur TLS 1.2 und TLS 1.3 akzeptiert, kann keine sichere Verbindung mit einem Client herstellen, der ausschließlich TLS 1.0 unterstützt.

Die Lösung sollte in einem solchen Fall nicht darin bestehen, den modernen Server dauerhaft auf unsichere Altprotokolle zurückzustellen. Sinnvoller ist es, den veralteten Client zu aktualisieren oder zu ersetzen.

Was Website-Betreiber bei TLS beachten sollten

Wer einen Webserver oder anderen öffentlich erreichbaren Dienst betreibt, sollte TLS nicht einfach aktivieren und danach vergessen.

TLS 1.3 sollte unterstützt werden. TLS 1.2 kann für kompatible Clients weiterhin sinnvoll sein, sofern nur geeignete kryptografische Verfahren zugelassen werden. TLS 1.0, TLS 1.1 und die alten SSL-Versionen gehören abgeschaltet.

Ebenso wichtig ist die Zertifikatsverwaltung. Zertifikate besitzen eine begrenzte Gültigkeitsdauer und müssen rechtzeitig erneuert werden. Bei automatisierten Lösungen sollte trotzdem kontrolliert werden, ob die Verlängerung tatsächlich funktioniert.

Nach Änderungen an Webserver, Reverse Proxy, CDN oder Zertifikaten empfiehlt sich eine erneute Prüfung der TLS-Konfiguration. So lassen sich fehlende Zwischenzertifikate, unerwünschte Altprotokolle oder andere Konfigurationsfehler früh erkennen.

Bei gemanagtem Webhosting übernimmt der Anbieter einen großen Teil dieser Arbeit. Trotzdem sollte HTTPS für die gesamte Website aktiviert sein und eine automatische Zertifikatserneuerung funktionieren.

Macht TLS eine Internetverbindung sicher?

TLS löst einen sehr konkreten Teil des Sicherheitsproblems: Es schafft einen geschützten Kanal zwischen Kommunikationspartnern.

Das verhindert, dass Daten auf dem Transportweg einfach im Klartext mitgelesen oder unbemerkt verändert werden. Gleichzeitig liefert die Serverauthentifizierung eine technische Grundlage dafür, dass der Client mit dem vorgesehenen Dienst kommuniziert.

TLS schützt aber weder vor unsicheren Passwörtern noch vor Schadsoftware, Datenlecks auf einem Server oder betrügerischen Websites. Auch ein Angreifer kann für seine eigene Domain ein gültiges Zertifikat erhalten und eine technisch einwandfreie HTTPS-Verbindung anbieten.

Genau deshalb sollte HTTPS als notwendige Voraussetzung für eine sichere Website betrachtet werden, nicht als Qualitäts- oder Vertrauenssiegel.

Fazit: TLS gehört zur Basis sicherer Netzwerkverbindungen

TLS ist einer der Gründe, warum sich vertrauliche Daten über öffentliche Netzwerke übertragen lassen, ohne sie unverschlüsselt auf die Reise zu schicken. Verschlüsselung, Integritätsschutz und Authentifizierung greifen dabei ineinander.

Für aktuelle Systeme sind TLS 1.2 und vor allem TLS 1.3 relevant. SSL sowie TLS 1.0 und TLS 1.1 sollten heute nicht mehr verwendet werden. Als normaler Nutzer musst du dafür meist nichts konfigurieren: Aktuelle Software und ein gepflegtes Betriebssystem sind die wichtigste Grundlage.

Bei eigenen Servern sieht es anders aus. Dort würde ich TLS 1.3 aktivieren, TLS 1.2 nur mit zeitgemäßer Konfiguration zusätzlich anbieten und sämtliche älteren Protokollversionen deaktivieren.