TLS (Transport Layer Security) ist das Standardprotokoll für Transportverschlüsselung im Internet. TLS schützt die Übertragung von Daten zwischen zwei Kommunikationspartnern gegen Mitlesen und Manipulation und weist die Identität des Servers über ein digitales Zertifikat nach. TLS ist der Nachfolger von SSL und die Grundlage von HTTPS sowie zahlreicher weiterer verschlüsselter Protokolle. Die aktuelle Version ist TLS 1.3.

Was ist TLS (Transportverschlüsselung)?

TLS ist ein Protokoll, das eine ungesicherte Netzwerkverbindung in eine gesicherte verwandelt. Es setzt auf dem Transportprotokoll TCP auf und liegt unterhalb der eigentlichen Anwendungsprotokolle – ein Webbrowser, ein Mailprogramm oder eine App muss die Verschlüsselung deshalb nicht selbst implementieren, sondern übergibt die Daten an TLS und erhält eine geschützte Verbindung zurück.

Diese Architektur erklärt die enorme Verbreitung. TLS ist nicht auf einen Anwendungsfall zugeschnitten, sondern ein universeller Baustein, der sich unter praktisch jedes Protokoll schieben lässt. Aus HTTP wird HTTPS, aus SMTP wird SMTP mit STARTTLS, aus LDAP wird LDAPS. Für Anwender ist das Ergebnis meist nur an Details sichtbar – dem Schloss-Symbol im Browser oder dem Präfix „https“ in der Adresszeile.

Wichtig ist eine Klarstellung, die in der Praxis häufig fehlt: Das Schloss-Symbol belegt eine verschlüsselte Verbindung zum Server, nicht die Vertrauenswürdigkeit des Betreibers. Da Zertifikate kostenlos und automatisiert zu erhalten sind, verfügen auch Phishing-Seiten praktisch immer über gültiges TLS. Verschlüsselung sagt etwas darüber aus, dass niemand mitliest – nicht darüber, mit wem man spricht.

Wie unterscheidet sich TLS von SSL?

TLS ist der direkte Nachfolger von SSL (Secure Sockets Layer) und unterscheidet sich davon in erster Linie durch Alter und Sicherheitsniveau. SSL wurde in den 1990er Jahren entwickelt; mit der Standardisierung durch die Internet Engineering Task Force wurde das Protokoll 1999 in TLS umbenannt. Alle SSL-Versionen gelten seit Jahren als gebrochen und dürfen nicht mehr eingesetzt werden.

Im Sprachgebrauch hat sich die alte Bezeichnung dennoch gehalten. Wer von einem „SSL-Zertifikat“ spricht, meint praktisch immer ein X.509-Zertifikat für TLS; Produktnamen wie SSL-VPN oder OpenSSL tragen den historischen Begriff ebenfalls weiter. Fachlich korrekt ist die Bezeichnung TLS-Zertifikat – ein Punkt, der in Ausschreibungen und Sicherheitskonzepten für Klarheit sorgt, weil sich daran auch die geforderte Protokollversion festmachen lässt.

Wie funktioniert der TLS-Handshake?

Der TLS-Handshake ist die Aushandlungsphase zu Beginn jeder Verbindung, in der sich beide Seiten auf Verfahren einigen, der Server seine Identität nachweist und gemeinsame Sitzungsschlüssel entstehen. Er läuft in vier logischen Schritten ab:

Aushandlung der Verfahren: Der Client übermittelt die von ihm unterstützten Protokollversionen und Verschlüsselungsverfahren; der Server wählt daraus aus. Diese Auswahl bestimmt das Sicherheitsniveau der gesamten Verbindung.
Authentifizierung des Servers: Der Server sendet sein Zertifikat samt Zertifikatskette. Der Client prüft, ob die Kette zu einer vertrauenswürdigen Wurzelinstanz führt, ob das Zertifikat gültig ist und ob es auf den aufgerufenen Namen ausgestellt wurde.
Schlüsselaustausch: Beide Seiten erzeugen über ein Diffie-Hellman-Verfahren einen gemeinsamen Sitzungsschlüssel, ohne diesen jemals zu übertragen. Da die dafür verwendeten Schlüssel nur für diese eine Sitzung gelten, bleiben aufgezeichnete Verbindungen auch dann geschützt, wenn der private Schlüssel des Servers später bekannt wird.
Übergang zur verschlüsselten Übertragung: Beide Seiten bestätigen den Abschluss; ab diesem Punkt sind alle Nutzdaten verschlüsselt und gegen Veränderung gesichert.

TLS 1.3 hat diesen Ablauf deutlich gestrafft. Der Handshake benötigt nur noch eine Übertragungsrunde statt zweier, große Teile der Aushandlung sind selbst verschlüsselt, und veraltete Verfahren wurden nicht optional gestellt, sondern vollständig entfernt. Der Sitzungsschlüsselaustausch mit Vorwärtsgeheimhaltung ist nicht mehr wählbar, sondern verpflichtend – eine Fehlkonfiguration in diesem Punkt ist damit ausgeschlossen.

Die optionale Gegenrichtung heißt gegenseitige Authentifizierung oder mTLS: Dabei weist auch der Client seine Identität über ein Zertifikat nach. In Zero-Trust-Architekturen und bei Schnittstellen zwischen Systemen ist dieses Verfahren verbreitet, weil es Zugriffe an ein geprüftes Gerät oder einen geprüften Dienst bindet statt nur an ein Passwort.

Welche Schutzziele erfüllt TLS (Transportverschlüsselung) – und welche nicht?

TLS erfüllt drei Schutzziele: Vertraulichkeit, Integrität und Authentizität der Gegenstelle. Die Nutzdaten sind auf dem Übertragungsweg verschlüsselt, Veränderungen werden erkannt, und die Identität des Servers ist über sein Zertifikat nachgewiesen.

Ebenso wichtig ist, was TLS nicht leistet. Es schützt Daten ausschließlich während der Übertragung, nicht im gespeicherten Zustand auf den beteiligten Systemen. Es sagt nichts über die Vertrauenswürdigkeit oder Absicht des Gegenübers aus. Es schützt nicht vor kompromittierten Endgeräten – ein Schadprogramm auf dem Client liest Daten vor der Verschlüsselung. Und es verbirgt nicht sämtliche Metadaten: Welcher Server kontaktiert wurde, wann und in welchem Umfang, bleibt für Beobachter des Netzwerkverkehrs weitgehend erkennbar.

Der praktisch folgenreichste Punkt betrifft die Zwischenstationen. TLS sichert jeweils eine Verbindung zwischen zwei Punkten. Führt der Weg einer Nachricht über mehrere Systeme – etwa Mailserver, Weiterleitungsdienste, Reverse Proxies oder Anwendungsserver –, liegen die Daten an jeder dieser Stationen unverschlüsselt vor, bevor sie für den nächsten Abschnitt erneut verschlüsselt werden.

Worin unterscheiden sich TLS und Ende-zu-Ende-Verschlüsselung?

TLS verschlüsselt den Transportweg zwischen zwei Punkten, Ende-zu-Ende-Verschlüsselung verschlüsselt den Inhalt zwischen Absender und Empfänger. Der Unterschied entscheidet darüber, ob der Betreiber eines Dienstes die übertragenen Inhalte lesen kann.

Merkmal	TLS (Transportverschlüsselung)	Ende-zu-Ende-Verschlüsselung
Geschützter Abschnitt	Jeweils eine Verbindung zwischen zwei Systemen	Vom Absendergerät bis zum Empfängergerät
Zugriff des Betreibers	Inhalte liegen auf dem Server im Klartext vor	Betreiber sieht nur verschlüsselte Inhalte
Schlüsselhoheit	Beim Serverbetreiber	Bei den Kommunikationspartnern
Wirkung bei Serverkompromittierung	Inhalte sind offengelegt	Inhalte bleiben geschützt
Typischer Einsatz	Websites, Schnittstellen, Datenübertragung allgemein	Messenger, verschlüsselte E-Mail, vertrauliche Kollaboration

Beide Verfahren stehen nicht in Konkurrenz, sondern werden kombiniert: Auch ein Ende-zu-Ende-verschlüsselter Dienst überträgt seine Daten zusätzlich über TLS, weil dies Metadaten schützt und Manipulationen am Transportweg verhindert. Umgekehrt genügt TLS allein nicht, wenn der Serverbetreiber selbst außerhalb des Vertrauensbereichs liegt oder wenn ein kompromittierter Server nicht zur Offenlegung sämtlicher Inhalte führen soll.

Für Organisationen mit besonderen Vertraulichkeitsanforderungen – etwa in Behörden, Kliniken oder bei Betreibern kritischer Infrastruktur – ist diese Unterscheidung der zentrale Prüfpunkt bei der Auswahl von Kommunikationsdiensten. Die Frage lautet nicht, ob eine Verbindung verschlüsselt ist, sondern wer die Inhalte an welcher Stelle im Klartext sehen kann.

Wie sich dienstliche Kommunikation über die reine Transportverschlüsselung hinaus absichern lässt, zeigt Teamwire in einer Demo oder im kostenlosen Test.

Welche TLS-Versionen gelten als sicher?

Als sicher gelten derzeit TLS 1.2 in geeigneter Konfiguration und TLS 1.3. Alle älteren Versionen sind wegen bekannter Schwachstellen abgekündigt und sollten deaktiviert sein.

Version	Veröffentlichung	Status
SSL 2.0 und 3.0	1995 und 1996	Gebrochen, seit Jahren untersagt
TLS 1.0	1999	Abgekündigt, nicht mehr einsetzen
TLS 1.1	2006	Abgekündigt, nicht mehr einsetzen
TLS 1.2	2008	Sicher bei geeigneter Konfiguration
TLS 1.3	2018	Empfohlener Stand, veraltete Verfahren entfernt

Der Zusatz „bei geeigneter Konfiguration“ ist bei TLS 1.2 wesentlich. Die Version erlaubt eine große Bandbreite an Verfahren, darunter auch längst überholte. Eine sichere Konfiguration beschränkt sich auf Verfahren mit authentifizierter Verschlüsselung, erzwingt Vorwärtsgeheimhaltung und schließt schwache Verfahren aus. TLS 1.3 nimmt diese Entscheidungen dem Betreiber ab, indem die betreffenden Optionen gar nicht mehr existieren – der wesentliche Grund, warum eine Umstellung auch dort lohnt, wo TLS 1.2 formal noch zulässig ist.

Für den deutschsprachigen Raum liefert die Technische Richtlinie TR-02102-2 des Bundesamts für Sicherheit in der Informationstechnik konkrete Vorgaben zu Versionen, Verfahren und Schlüssellängen. Sie wird regelmäßig fortgeschrieben und ist die übliche Referenz in Ausschreibungen und Sicherheitskonzepten.

Welche Rolle spielen Zertifikate bei TLS?

Zertifikate sind der Mechanismus, mit dem TLS die Identität eines Servers nachweist. Ein X.509-Zertifikat verbindet einen Domainnamen mit einem öffentlichen Schlüssel und ist von einer Zertifizierungsstelle signiert, der das Betriebssystem oder der Browser vertraut. Aus dieser Signaturkette – vom Serverzertifikat über Zwischeninstanzen bis zur Wurzelinstanz im Vertrauensspeicher – ergibt sich die Vertrauensbeziehung.

Zertifikate unterscheiden sich nach Prüftiefe. Bei domainvalidierten Zertifikaten wird lediglich die Verfügungsgewalt über die Domain geprüft; organisationsvalidierte und erweitert validierte Zertifikate prüfen zusätzlich die Existenz und Identität der Organisation. Für die technische Verschlüsselungsstärke ist die Prüftiefe ohne Bedeutung – sie betrifft ausschließlich die Aussagekraft der Identitätsangabe.

Operativ verursachen zwei Themen den meisten Aufwand. Erstens die Gültigkeitsdauer: Zertifikatslaufzeiten wurden über die Jahre stufenweise verkürzt, und diese Entwicklung setzt sich fort. Manuelle Erneuerung ist dadurch keine tragfähige Praxis mehr; abgelaufene Zertifikate zählen zu den häufigsten vermeidbaren Ausfallursachen. Zweitens der Widerruf: Kompromittierte Zertifikate müssen für ungültig erklärt werden, wobei die dafür verwendeten Verfahren technisch im Wandel sind. Ergänzend protokollieren öffentliche Transparenzregister ausgestellte Zertifikate und ermöglichen Organisationen, unberechtigte Ausstellungen auf eigene Domains zu erkennen – ein Werkzeug, das im Monitoring erstaunlich selten genutzt wird.

Wo wird TLS (Transportverschlüsselung) eingesetzt?

TLS wird überall dort eingesetzt, wo Daten über ein Netzwerk übertragen werden – weit über Websites hinaus. Typische Einsatzbereiche sind:

Web und Anwendungen: HTTPS für Websites, Portale, Schnittstellen und Cloud-Dienste
E-Mail: Transportverschlüsselung zwischen Mailservern sowie zwischen Client und Server
Verzeichnisdienste und Authentifizierung: verschlüsselte Verbindungen zu Verzeichnis- und Anmeldediensten
DNS: verschlüsselte Namensauflösung über DNS over TLS und verwandte Verfahren
Fernzugriff: VPN-Lösungen auf TLS-Basis sowie Fernwartungsverbindungen
Maschinenkommunikation: Schnittstellen zwischen Systemen, häufig mit gegenseitiger Authentifizierung
Moderne Transportprotokolle: Das Protokoll QUIC, Grundlage aktueller Webübertragung, nutzt den Handshake von TLS 1.3

Bei E-Mail zeigt sich dabei eine typische Einschränkung besonders deutlich. Die Verschlüsselung wirkt jeweils nur zwischen zwei benachbarten Servern; auf jedem Zwischenschritt liegt die Nachricht im Klartext vor. Ob überhaupt verschlüsselt übertragen wird, hängt zudem von der Konfiguration beider Seiten ab und war lange nicht erzwingbar – ein Grund, warum E-Mail für vertrauliche Inhalte ohne zusätzliche Inhaltsverschlüsselung als ungeeignet gilt.

Welche Schwachstellen und Angriffe betreffen TLS?

Angriffe auf TLS richten sich fast nie gegen die zugrunde liegende Kryptografie, sondern gegen Implementierungen, Konfigurationen und das Zertifikatssystem. Vier Kategorien sind praktisch relevant.

Herabstufungsangriffe versuchen, Client und Server zur Nutzung einer veralteten Version oder eines schwachen Verfahrens zu bewegen. Wirksame Gegenmaßnahme ist das Abschalten alter Versionen – nicht deren Beibehaltung „für den Notfall“. Implementierungsfehler in Krypto-Bibliotheken haben in der Vergangenheit schwerwiegende Folgen gehabt; sie betreffen nicht das Protokoll, sondern dessen Umsetzung, und machen zügiges Patchen der eingesetzten Bibliotheken zur Pflicht.

Angriffe auf das Vertrauensmodell zielen auf die Zertifizierungsstellen. Wird eine solche Stelle kompromittiert oder stellt sie fälschlich ein Zertifikat für eine fremde Domain aus, lassen sich Verbindungen unbemerkt umleiten und mitlesen. Transparenzregister und die Überwachung eigener Domains begrenzen dieses Risiko. Konfigurationsfehler sind schließlich die mit Abstand häufigste Ursache realer Schwächen: veraltete Versionen aktiv, schwache Verfahren zugelassen, unvollständige Zertifikatsketten, abgelaufene Zertifikate oder fehlende Erzwingung verschlüsselter Verbindungen.

Eine eigene Betrachtung verdient die Aufbrechung von TLS durch Sicherheitskomponenten im eigenen Netz. Firewalls und Web-Gateways entschlüsseln den Verkehr, um ihn zu prüfen, und verschlüsseln ihn anschließend erneut. Das ist ein legitimes Verfahren zur Erkennung von Schadsoftware, schafft aber einen Punkt, an dem sämtlicher Datenverkehr im Klartext vorliegt – mit entsprechenden Anforderungen an Absicherung, Protokollierung, Zweckbindung und Mitbestimmung.

Welche Anforderungen an TLS ergeben sich aus Regulierung und Standards?

Regulatorisch wird TLS selten namentlich vorgeschrieben, aber regelmäßig über den Umweg des Standes der Technik verlangt. Art. 32 DSGVO nennt Verschlüsselung ausdrücklich als geeignete technische Maßnahme; unverschlüsselte Übertragung personenbezogener Daten über öffentliche Netze gilt als Verstoß gegen die Sicherheitspflicht und begründet bei einem Vorfall regelmäßig ein Organisationsverschulden. Details zur Umsetzung gehören deshalb auch in die Maßnahmenbeschreibung eines Auftragsverarbeitungsvertrags und in die Dokumentation zur DSGVO-Konformität.

Auf Standardebene adressiert ISO 27001 das Thema über die Maßnahme zur Nutzung von Kryptografie, die eine dokumentierte Regelung zu Verfahren, Schlüsselverwaltung und Geltungsbereich verlangt. NIS-2 führt Kryptografie und Verschlüsselung unter den Mindestmaßnahmen für Risikomanagement auf. Für den öffentlichen Sektor und für Ausschreibungen ist die Technische Richtlinie des BSI der übliche Referenzpunkt.

Praktisch übersetzt sich das in wenige überprüfbare Anforderungen: aktuelle Protokollversionen, Beschränkung auf empfohlene Verfahren, gültige und automatisiert erneuerte Zertifikate, Erzwingung verschlüsselter Verbindungen sowie eine regelmäßige, dokumentierte Überprüfung der Konfiguration.

Was bedeutet Quantencomputing für TLS?

Quantencomputing bedroht nicht die Verschlüsselung der Nutzdaten selbst, sondern den Schlüsselaustausch und die digitalen Signaturen von TLS. Die heute verwendeten Verfahren beruhen auf mathematischen Problemen, die ein hinreichend leistungsfähiger Quantencomputer effizient lösen könnte – während die symmetrische Verschlüsselung der eigentlichen Daten durch längere Schlüssel vergleichsweise einfach abzusichern ist.

Konkret relevant ist das schon heute wegen eines Angriffsmusters, das ohne Quantencomputer auskommt: Verschlüsselter Datenverkehr lässt sich aufzeichnen und speichern, um ihn später zu entschlüsseln. Für Informationen mit langer Schutzbedürftigkeit – Gesundheitsdaten, Ermittlungsakten, Konstruktionsunterlagen – ist der Zeitpunkt der Entschlüsselung weniger entscheidend als die Frage, wie lange sie schützenswert bleiben.

Die Antwort der Standardisierung sind quantensichere Verfahren, die in TLS zunächst hybrid eingeführt werden: Ein klassisches und ein quantensicheres Verfahren werden kombiniert, sodass die Verbindung geschützt bleibt, solange mindestens eines von beiden hält. Große Browser und Serverbetreiber haben mit der Umstellung begonnen. Für Organisationen empfiehlt sich derzeit vor allem eine Bestandsaufnahme: Wo werden welche Verfahren eingesetzt, welche Daten benötigen langfristigen Schutz, und wie kryptografisch flexibel sind die eingesetzten Systeme. Der Stand der Verfahren und ihrer Verbreitung ändert sich schnell und sollte vor Festlegungen geprüft werden.

Zusammenfassung: Wichtige Punkte zu TLS

TLS (Transport Layer Security) ist das Standardprotokoll für Transportverschlüsselung und die Grundlage von HTTPS sowie zahlreicher weiterer Protokolle.
TLS ist der Nachfolger von SSL; alle SSL-Versionen sind gebrochen, die Bezeichnung „SSL-Zertifikat“ hat sich sprachlich dennoch gehalten.
Der Handshake handelt Verfahren aus, prüft das Serverzertifikat und erzeugt Sitzungsschlüssel; TLS 1.3 verkürzt ihn und entfernt veraltete Optionen vollständig.
TLS schützt Vertraulichkeit, Integrität und Authentizität der Gegenstelle – nicht gespeicherte Daten, nicht kompromittierte Endgeräte und nicht sämtliche Metadaten.
TLS sichert jeweils nur einen Abschnitt: An jeder Zwischenstation liegen die Daten im Klartext vor, bevor sie erneut verschlüsselt werden.
Der Unterschied zur Ende-zu-Ende-Verschlüsselung entscheidet darüber, ob der Betreiber eines Dienstes die Inhalte lesen kann; beide Verfahren werden kombiniert eingesetzt.
Als sicher gelten TLS 1.2 in geeigneter Konfiguration und TLS 1.3; ältere Versionen sind abgekündigt und zu deaktivieren.
Das Schloss-Symbol belegt keine Vertrauenswürdigkeit des Betreibers – auch Phishing-Seiten verfügen praktisch immer über gültige Zertifikate.
Reale Schwächen entstehen fast immer durch Konfigurations- und Implementierungsfehler, nicht durch die Kryptografie selbst.
Quantensichere Verfahren werden derzeit hybrid in TLS eingeführt; für langfristig schutzbedürftige Daten ist eine Bestandsaufnahme der eingesetzten Verfahren angeraten.