TLS: Wie all diese Bausteine in Sekundenbruchteilen zusammenspielen

30.07.2026 · 6 Min. Lesezeit

In den vergangenen vier Artikeln haben wir uns Stück für Stück die Bausteine erarbeitet, aus denen sich sichere Kommunikation im Internet zusammensetzt: symmetrische Verschlüsselung, bei der beide Seiten denselben geheimen Schlüssel benutzen und die dafür sehr schnell ist; asymmetrische Verschlüsselung, mit der sich das Problem der Schlüsselverteilung über ein Schlüsselpaar aus öffentlichem und privatem Schlüssel lösen lässt; digitale Signaturen, mit denen sich Echtheit und Unversehrtheit einer Nachricht beweisen lassen; und Zertifikate, mit denen ein öffentlicher Schlüssel überhaupt erst vertrauenswürdig mit einer Identität verknüpft wird. In diesem letzten Artikel der Reihe wollen wir uns anschauen, wie all diese Bausteine tatsächlich zusammenspielen, wenn du in deinem Browser eine Adresse mit “https” aufrufst – ein Vorgang, der sich “TLS-Handshake” nennt und der, obwohl dabei eine ganze Menge passiert, in aller Regel innerhalb weniger hundert Millisekunden abgeschlossen ist, bevor du auch nur die erste Zeile der Webseite zu sehen bekommst.

Was TLS überhaupt ist

TLS steht für “Transport Layer Security” und ist im Grunde ein Regelwerk, das genau festlegt, wie zwei Kommunikationspartner – etwa dein Browser und der Server einer Webseite – eine sichere Verbindung miteinander aufbauen, bevor die eigentlichen Daten fließen. Das kleine “s” in “https” steht dabei für nichts anderes als “secure” und bedeutet konkret, dass die gewohnte Kommunikation über das Hypertext Transfer Protocol, kurz HTTP, zusätzlich durch genau diese TLS-Schicht abgesichert wird. Wichtig zu verstehen ist dabei: TLS ist keine einzelne Technik, sondern eher ein choreografierter Ablauf, bei dem die vier Bausteine aus den vorherigen Artikeln jeweils genau an der Stelle zum Einsatz kommen, an der sie ihre jeweiligen Stärken ausspielen können.

Der erste Kontakt: Client Hello und Server Hello

Der Verbindungsaufbau beginnt damit, dass dein Browser – in der Fachsprache auch “Client” genannt – dem Server eine erste Nachricht schickt, üblicherweise als “Client Hello” bezeichnet. Darin teilt der Browser dem Server unter anderem mit, welche Verschlüsselungsverfahren und welche Version des TLS-Protokolls er unterstützt, denn im Laufe der Jahre haben sich hier durchaus mehrere Varianten und Verbesserungen angesammelt, und beide Seiten müssen sich zunächst auf eine gemeinsame Basis einigen. Der Server antwortet daraufhin mit einem “Server Hello”, in dem er aus den vom Browser vorgeschlagenen Optionen diejenigen auswählt, die er selbst ebenfalls unterstützt und bevorzugt.

Zusammen mit dieser Antwort schickt der Server außerdem sein Zertifikat mit, jenes Dokument also, das wir im letzten Artikel kennengelernt haben und das seinen öffentlichen Schlüssel fest mit dem Namen der Webseite verknüpft, bestätigt durch die Signatur einer Zertifizierungsstelle. Dein Browser nimmt dieses Zertifikat entgegen und prüft nun genau das, was wir bereits ausführlich besprochen haben: Er verfolgt die Vertrauenskette vom Zertifikat des Servers über eine mögliche Zwischenzertifizierungsstelle bis hinauf zu einem Root-Zertifikat, das bereits vertrauenswürdig in seinem eigenen Speicher hinterlegt ist. Nur wenn diese gesamte Kette lückenlos aufgeht, betrachtet der Browser den öffentlichen Schlüssel des Servers als authentisch und macht mit dem Verbindungsaufbau überhaupt weiter. Andernfalls zeigt er dir jene bekannten Warnmeldungen an, die vor einer möglicherweise unsicheren Verbindung warnen.

Der eigentliche Clou: die Erzeugung eines gemeinsamen Sitzungsschlüssels

Jetzt kommt der Moment, in dem sich symmetrische und asymmetrische Kryptographie die Hände reichen. Erinnern wir uns kurz an den ersten Artikel dieser Reihe: Symmetrische Verschlüsselung ist deutlich schneller und effizienter als asymmetrische Verschlüsselung, eignet sich also viel besser dafür, die eigentliche, oft sehr umfangreiche Kommunikation zu verschlüsseln – etwa den gesamten Inhalt einer Webseite samt Bildern. Ihr großes Problem war allerdings, dass beide Seiten vorab denselben geheimen Schlüssel besitzen müssen, was sich zwischen zwei einander unbekannten Parteien im Internet nicht ohne Weiteres bewerkstelligen lässt. Genau dieses Problem löst TLS nun, indem es die asymmetrische Kryptographie ausschließlich dafür einsetzt, sich am Anfang der Verbindung auf einen gemeinsamen, zufällig erzeugten symmetrischen Schlüssel zu einigen, den sogenannten Sitzungsschlüssel.

Vereinfacht ausgedrückt läuft das so ab, dass beide Seiten Zufallswerte austauschen und daraus, unter Zuhilfenahme des öffentlichen Schlüssels aus dem Serverzertifikat, gemeinsam einen Sitzungsschlüssel berechnen, den ein Lauscher, der die Verbindung nur von außen mitverfolgt, nicht rekonstruieren kann – schließlich fehlt ihm dafür der private Schlüssel des Servers. In modernen TLS-Versionen kommt dabei meist ein noch etwas raffinierteres Verfahren zum Einsatz, das dafür sorgt, dass selbst dann, wenn der private Schlüssel des Servers irgendwann in der Zukunft einmal in falsche Hände geraten sollte, alte, bereits aufgezeichnete Verbindungen trotzdem nicht nachträglich entschlüsselt werden können. Diese Eigenschaft nennt sich “Forward Secrecy”, zu Deutsch etwa “zukunftsgerichtete Geheimhaltung”, und wäre für sich genommen schon einen eigenen, vertiefenden Artikel wert. Für unser Verständnis an dieser Stelle reicht es aber vollkommen aus, festzuhalten: Am Ende dieses Schritts besitzen sowohl dein Browser als auch der Server denselben symmetrischen Sitzungsschlüssel, ohne dass dieser jemals unverschlüsselt über die Leitung übertragen wurde.

Ab jetzt übernimmt die schnelle symmetrische Verschlüsselung

Sobald dieser gemeinsame Sitzungsschlüssel etabliert ist, wechselt die Verbindung vollständig auf symmetrische Verschlüsselung, üblicherweise mit dem bereits erwähnten Verfahren AES. Die gesamte weitere Kommunikation – der Inhalt der Webseite, Formulardaten, die du eingibst, alles, was sonst noch zwischen dir und dem Server hin- und herfließt – wird ab diesem Zeitpunkt ausschließlich mit diesem schnellen, effizienten symmetrischen Verfahren verschlüsselt. Das ist auch der Grund, warum das anfängliche Handshake-Verfahren mit seinen vergleichsweise aufwendigeren asymmetrischen Berechnungen nur einmal zu Beginn der Verbindung durchlaufen werden muss und nicht etwa für jedes einzelne übertragene Datenpaket erneut – genau dieses Zusammenspiel aus den Stärken beider Verfahren hatten wir bereits am Ende des ersten Artikels dieser Reihe angekündigt.

Wo die digitale Signatur zusätzlich noch mitspielt

Neben der Prüfung des Zertifikats, die wir bereits besprochen haben, kommt während des Handshakes an einer weiteren Stelle noch einmal eine digitale Signatur zum Einsatz: Der Server signiert einen Teil der ausgetauschten Handshake-Daten mit seinem privaten Schlüssel, um zu beweisen, dass er tatsächlich im Besitz des privaten Schlüssels ist, der zu dem zuvor vorgelegten Zertifikat gehört. Ohne diesen zusätzlichen Schritt könnte ein Angreifer theoretisch versuchen, einfach ein fremdes, aber gültiges Zertifikat mitzuschicken, ohne selbst über den zugehörigen privaten Schlüssel zu verfügen. Dein Browser prüft diese Signatur mit dem öffentlichen Schlüssel aus dem Zertifikat, ganz nach dem Verfahren, das wir im entsprechenden Artikel dieser Reihe bereits ausführlich durchgerechnet haben. Erst wenn auch diese Prüfung erfolgreich verläuft, ist wirklich zweifelsfrei belegt, dass am anderen Ende der Verbindung tatsächlich der rechtmäßige Besitzer des Zertifikats sitzt.

Der gesamte Ablauf im Überblick

Fassen wir den Weg noch einmal in seiner Gesamtheit zusammen, dieses Mal mit dem vollständigen Bild vor Augen: Dein Browser und der Server einigen sich zunächst auf gemeinsam unterstützte Verfahren. Der Server weist sich mit seinem Zertifikat aus, dessen Vertrauenswürdigkeit dein Browser anhand der Vertrauenskette bis zu einem hinterlegten Root-Zertifikat überprüft. Der Server beweist zusätzlich mittels einer digitalen Signatur, dass er tatsächlich im Besitz des zum Zertifikat passenden privaten Schlüssels ist. Auf dieser Vertrauensbasis einigen sich beide Seiten unter Zuhilfenahme asymmetrischer Kryptographie auf einen gemeinsamen, geheimen symmetrischen Sitzungsschlüssel. Und ab diesem Moment übernimmt die deutlich schnellere symmetrische Verschlüsselung die eigentliche, oft sehr umfangreiche Kommunikation für den Rest der Verbindung. Jeder einzelne dieser Schritte greift dabei auf genau eines der Prinzipien zurück, die wir in dieser Artikelreihe von Grund auf hergeleitet haben.

Ein Blick zurück auf die gesamte Reihe

Damit schließt sich der Kreis dieser fünfteiligen Reihe. Wir sind vom grundlegenden Problem der symmetrischen Verschlüsselung ausgegangen, dem Schlüsselverteilungsproblem, haben mit der asymmetrischen Kryptographie und ihrem mathematischen Fundament eine Lösung dafür gefunden, haben gesehen, wie sich dieselbe Technik auch umgekehrt für digitale Signaturen einsetzen lässt, haben mit Zertifikaten das übrig gebliebene Vertrauensproblem gelöst, und haben nun zum Schluss gesehen, wie all diese Bausteine gemeinsam jene alltägliche, unscheinbare Verbindung ermöglichen, die du vermutlich schon Dutzende Male benutzt hast, während du diese Artikelreihe gelesen hast. Was am Anfang wie reine Mathematik wirkte, ist am Ende genau das Fundament, auf dem praktisch das gesamte Vertrauen im heutigen Internet ruht.