TLS (Transport Layer Security) ist ein kryptographisches Protokoll, das verwendet wird, um die Sicherheit und Integrität der Kommunikation über Computernetzwerke, insbesondere über das Internet, zu gewährleisten. Es schützt Daten, die zwischen einem Client (z. B. einem Webbrowser) und einem Server (z. B. einer Website) ausgetauscht werden, indem es Verschlüsselung, Authentifizierung und Integrität bereitstellt. TLS ist der Nachfolger von SSL (Secure Sockets Layer) und stellt sicher, dass sensible Informationen wie Passwörter, Kreditkartendaten oder persönliche Nachrichten während der Übertragung vor dem Abhören und der Manipulation durch Dritte geschützt sind.
Der Ablauf einer TLS-Verschlüsselung (Transport Layer Security) besteht aus mehreren Schritten, die zwischen dem Client (z.B. einem Browser) und dem Server (z.B. einer Website) ablaufen. Der TLS-Handshake ist dabei der wichtigste Teil dieses Prozesses, da hier die Parameter für die sichere Verbindung festgelegt und des Sitzungsschlüssel ausgetauscht werden.
TLS-Handshake
Der gesamte Prozess des TLS-Handshakes hat im Wesentlichen zum Ziel, einen sicheren Sitzungsschlüssel (Session Key) zwischen Client und Server zu berechnen, ohne dass dieser Schlüssel jemals direkt über das Netzwerk übertragen wird. Mit diesem Sitzungsschlüssel wird dann die eigentliche Datenübertragung symmetrisch verschlüsselt.
Client Hello
Der Prozess beginnt, wenn der Client eine sichere Verbindung aufbauen möchte. Der Client sendet eine Client Hello Nachricht an den Server. Diese Nachricht enthält die Versionsnummern der vom Client unterstützten TLS-Protokolle (z. B. TLS 1.2 oder TLS 1.3), die vom Client unterstützten Cypher Suites (z. B. AES, RSA, ECC) und ein Client Random (Zufallszahl) kombiniert mit einem Zeitstempel, was später zur Berechnung des Sitzungsschlüssels verwendet wird.
Server Hello
Der Server antwortet mit einer Server Hello Nachricht, die die ausgewählte TLS-Version (normalerweise die höchste gemeinsame Version), einen gemeinsam unterstützten Verschlüsselungsalgorithmus aus der Liste der Cipher Suites, die im Client Hello angeboten werden, ein Server Random (Zufallszahl mit Zeitstempel) und das digitale Zertifikat enthält, das den öffentlichen Schlüssel des Servers bereitstellt und von einer Certification Authority (CA) signiert wurde, enthält. Dadurch wird die Identität des Servers sichergestellt.
Schlüsselaustausch (Key Exchange)
Ist der kleinste gemeinsame Nenner gefunden und eine Schnittmenge vorhanden, wird nun je nach gewähltem Verschlüsselungsverfahren der Sitzungsschlüssel ausgehandelt. Es gibt zwei Hauptvarianten des Schlüsselaustauschs: RSA und Diffie-Hellman.
Im oben gezeigten Beispiel hat man sich auf TLS 1.2 geeinigt und verwendet die Cipher Suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Diese Cipher Suite bietet eine starke Kombination aus Effizienz, Sicherheit und Datenintegrität. Sie verwendet Perfect Forward Secrecy (PFS) durch den ECDHE-Schlüsselaustausch (Elliptic Curve Diffie-Hellman Ephemeral), starke symmetrische Verschlüsselung mit AES-128 und GCM (für die eigentliche Datenverschlüsselung), sowie eine verlässliche Hashing-Funktion mit SHA-256. Sie ist eine der häufig verwendeten Cipher Suites, besonders in modernen TLS-Implementierungen.
RSA-Schlüsselaustausch
Bei Verwendung von RSA verschlüsselt der Client eine Zufallszahl (Premaster Secret) mit dem öffentlichen Schlüssel des Servers (aus dem Serverzertifikat) und sendet diese verschlüsselte Zahl an den Server. Der Server entschlüsselt diese Zahl mit seinem privaten Schlüssel.
Das Premaster Secret ist eine der Hauptkomponenten für die Berechnung des Master Secret. Dieses Master Secret wird zusammen mit dem Client Random und dem Server Random verwendet, um den endgültigen symmetrischen Sitzungsschlüssel zu erzeugen, mit dem die verschlüsselte Kommunikation stattfindet.
Diffie-Hellman oder Elliptische Kurven Diffie-Hellman (ECDHE)
Beide Parteien berechnen unabhängig voneinander einen gemeinsamen geheimen Wert, indem sie ihre eigenen geheimen Schlüssel mit dem ausgetauschten öffentlichen Schlüssel der anderen Partei kombinieren.
Im Gegensatz zu RSA, bei dem der Client ein Premaster Secret erzeugt und dieses verschlüsselt an den Server sendet, vermeidet Diffie-Hellman genau diesen Ansatz. Stattdessen basiert DH auf einem mathematischen Verfahren, das die Berechnung eines gemeinsamen Sitzungsschlüssels ermöglicht, ohne dass ein solches Geheimnis über das Netzwerk übertragen wird.
Sowohl das Client Hello als auch das Server Hello sowie der Schlüsselaustausch erfolgen unverschlüsselt. Diese Nachrichten sind Teil des TLS-Handshakes und werden verwendet, um die Verschlüsselungsparameter auszuhandeln, bevor die eigentliche verschlüsselte Kommunikation beginnt.
Berechnung des Sitzungsschlüssels
RSA-Verfahren
Nachdem sowohl der Client als auch der Server das Premaster Secret erhalten haben, verwenden sie es zusammen mit den Zufallszahlen des Clients und des Servers (die in den ersten Nachrichten ausgetauscht wurden), um den symmetrischen Sitzungsschlüssel zu berechnen. Mit diesem Schlüssel wird die eigentliche Datenübertragung verschlüsselt.
Diffie-Hellman-Verfahren
Beim Diffie-Hellman-Verfahren erzeugen Client und Server jeweils einen privaten Zufallswert und tauschen ihre öffentlichen Schlüssel aus. Beide Parteien berechnen dann durch mathematische Operationen den gemeinsamen Sitzungsschlüssel (ohne Verwendung eines Premaster Secret). Zusammen mit den Zufallswerten des Clients und des Servers wird dieser Sitzungsschlüssel für die symmetrische Verschlüsselung der eigentlichen Datenübertragung abgeleitet.
Die Change Cipher Spec Nachrichten signalisieren, dass die Kommunikationspartner bereit ist, ab jetzt auf die neu ausgehandelten Cipher (Verschlüsselungsschemata) zu wechseln. Es bedeutet, dass der Handshake abgeschlossen ist und ab diesem Punkt die Kommunikation zwischen Client und Server verschlüsselt wird.
Die Encrypted Handshake Message, die nach den Change Cipher Spec Nachrichten gesendet wird, sind der verschlüsselte Teil des Handshakes und zeigen an, dass die Verhandlung erfolgreich abgeschlossen wurde und beide Parteien nun verschlüsselte Nachrichten austauschen können. Der Inhalt dieser Nachrichten ist bereits verschlüsselt und beinhalten einen einen Hashwert der bisherigen Kommunikation, um zu bestätigen, dass nichts verändert wurde. Diese Nachrichten werden auch Client Finished und Server Finished genannt.
Sichere Verbindung
Damit ist der TLS-Handshake abgeschlossen. Client und Server haben den gleichen Sitzungsschlüssel und können die folgenden Daten symmetrisch verschlüsseln. Ab diesem Zeitpunkt ist die Kommunikation verschlüsselt und beide Parteien verwenden denselben Sitzungsschlüssel zum Ver- und Entschlüsseln der Nachrichten.
Was genau ist eine Sitzung im Kontext von TLS?
Die Gültigkeit des Sitzungsschlüssels endet, wenn die Sitzung geschlossen wird - dies geschieht normalerweise entweder nach einer bestimmten Zeit (Timeout) oder wenn der Client oder der Server die Verbindung beendet. In vielen modernen TLS-Implementierungen wird der Sitzungsschlüssel nur für eine Sitzung verwendet, was durch Perfect Forward Secrecy (PFS) gewährleistet wird, wenn Diffie-Hellman (DHE oder ECDHE) für den Schlüsselaustausch verwendet wird. Diese Eigenschaft stellt sicher, dass jede Sitzung einen neuen, unabhängigen Schlüssel hat, selbst wenn derselbe Client und derselbe Server eine neue Verbindung aufbauen. Auf diese Weise bleiben vergangene Sitzungen sicher, selbst wenn ein privater Langzeitschlüssel kompromittiert wird.
Der Begriff Sitzung wird häufig auch in einem breiteren Kontext verwendet, z.B. im Zusammenhang mit der Navigation auf einer Website. Aus Sicht des Benutzers kann das Anklicken verschiedener Links oder das Laden neuer Seiten als eine kontinuierliche Sitzung wahrgenommen werden. Technisch gesehen kann jedoch jede dieser Interaktionen zu neuen TLS-Sitzungen führen, wenn neue Verbindungen aufgebaut werden müssen. Dies ist beispielsweise der Fall, wenn ein Browser für jede HTTP-Anfrage eine neue Verbindung zum Server aufbaut.
Um die Performance zu verbessern, gibt es den Mechanismus des TLS Session Resumption. Das bedeutet, dass nach einer erfolgreichen TLS-Verbindung die Sitzungsparameter (einschließlich des Sitzungsschlüssels) zwischengespeichert werden können, so dass bei einer erneuten Verbindung zwischen demselben Client und Server nicht der gesamte TLS-Handshake noch einmal durchlaufen werden muss. Dies spart Zeit, da keine neuen Sitzungsschlüssel berechnet werden müssen. Diese Wiederaufnahmen sind jedoch immer temporär und unterliegen Sicherheitsrichtlinien, um eine unbegrenzte Gültigkeit der Sitzung zu verhindern.
