Transport Layer Security (TLS) / Secure Socket Layer (SSL) - Prof. Dr. Norbert
Pohlmann
Transport Layer Security (TLS) / Secure Socket Layer (SSL)
Was ist SSL oder TLS?
Der vorherrschende Ansatz für die Transportverschlüsselung im Web ist die Verwendung von TLS (Transport Layer Security) / SSL (Secure Socket Layer) – TLS/SSL.TLS/SSL ist der Internet-Sicherheitsstandards der Internet Engineering Task Force (IETF) für die Cyber-Sicherheit auf der Transport-Ebene. Dabei ist TLS/SSL anwendungsunabhängig und setzt logisch auf einem Transportprotokoll auf.
Cyber-Sicherheitsfunktionen, die von TLS/SSL (der TLS-Verschlüsselung) angeboten werden, sind:
Außerdem bietet TLS/SSL auch die Komprimierung der Daten an.
Einbindung in die Kommunikationsarchitektur TLS/SSL kann eine Vielzahl höherer Anwendungsprotokolle unterstützen, wie HTTP, SMTP, SIP, IMAP, FTP, Telnet. Die genauen Eigenschaften des TLS/SSL-Kanals werden bei der Einrichtung der verschlüsselten und integritätsgesicherten Kommunikation zwischen Client und Server ausgehandelt und festgelegt. Sie können aber Anwendungsdaten-Fragmentierung und Komprimierung beinhalten, die in Kombination mit Authentifikation von Client und Server sowie Integrität, Authentizität und Vertraulichkeit der Transportdaten angewendet werden. Die TLS/SSL-Schicht ist in zwei Teil-Schichten angeordnet. Den Kern des TLS/SSL-Protokolls bildet eine TLS-Datensatz-Protokollschicht, die einen sicheren Kanal zwischen Client und einem Server implementiert.
Schichteneinordnung der SSL-Verschlüsselung Die TLS/SSL-Schicht befindet sich zwischen der Transport- und Anwendungsschicht. Sie übernimmt zusätzlich die Aufgaben der Sitzungs- und Präsentationsschicht (Schichten 5 und 6) des ISO/OSI-Modells. Ein wesentlicher Vorteil der Sitzungsschicht gegenüber der Transportschicht besteht darin, dass Zustandsinformationen über einen längeren Zeitraum und über verschiedene Einzelverbindungen hinweg gespeichert und für die Verwaltung genutzt werden können. Für das zustandslose HTTP-Protokoll, das für jeden Zugriff auf eine Webseite eine neue TCP-Verbindung aufbauen kann, bedeutet das, dass mehrere solcher Verbindungen zu einer TLS/SSL-Sitzung gebündelt und damit effizienter als die jeweiligen Einzelverbindungen verwaltet werden können. Die TLS/SSL-Protokolle sind erweiterbar und flexibel, um Zukunftssicherheit vor allem bei den Verschlüsselungsalgorithmen zu gewährleisten. TLS/SSL arbeitet transparent, sodass es leicht eingesetzt werden kann, um Anwendungsprotokollen/-diensten, ohne eigene Cyber-Sicherheitsmechanismen, vertrauenswürdige Verbindungen zur Verfügung zu stellen.
Praktische Relevanz von TLS/SSL Da TLS/SSL in allen wichtigen Technologien wie Browsern, Web-Servern, E-Mail-Servern, SIP-Server, usw. eingebunden ist, wird TLS/SSL faktisch als Standard für die Transportverschlüsselung im Internet verwendet.
Aufbau der TLS/SSL-Schicht Die TLS/SSL-Schicht besteht aus zwei Teil-Schichten:
höhere Schicht mit den TLS/SSL-Teil-Protokollen (CCS, Alert, Handshake, Application)
Record-Schicht mit dem Record Layer-Protokoll
Der Client kann durch die Wahl des Ports entscheiden, ob die Kommunikation TLS/SSL-gesichert sein soll oder im Klartext: Zum Beispiel im Bild
Port 80: http-Kommunikation im Klartext
Port 443: http-Kommunikation TLS/SSL-gesichert
TLS/SSL – Record Layer-Protokoll Das Record Layer Protokoll leitet die Klartext-Anwendungsdaten aus der Anwendungsschicht verschlüsselt an die Transportschicht weiter.
Das Record Layer-Protokoll bietet zwei verschiedene Cyber-Sicherheitsdienste, die zusammen oder einzeln genutzt werden können: • Client-to-Server-Verschlüsselung zwischen den beiden Transport-Endpunkten • Sicherung der Nachrichten-Integrität und –Authentizität
Zu den Aufgaben des Record-Protokolls gehören • die Fragmentierung der Klartext-Anwendungsdaten der Anwendungsschicht, • Kompression der resultierenden Fragmente, • Berechnung von HMACs über die (komprimierten)Fragmente und • Verschlüsselung der TLS/SSL-Records (komprimierte Fragment mit HMAC).
Ablauf in der Record-Schicht (TLS 1.2 und kleiner) Die Record-Schicht hat die Aufgabe, Anwendungsdaten in TLS/SSL-Records zu fragmentieren. Optional werden die Fragmente dann komprimiert. Das Komprimierungsverfahren wird beim Handshake ausgehandelt. Diese (komprimierten) Fragmente + Sequenznummer werden dann mit einer HMAC-Funktion gehasht. Die (komprimierten) Fragmente sowie der HMAC werden dann verschlüsselt und als TLS/SSL-Records an die Transportschicht übergeben.
TLS/SSL – Application Data Protokoll Anders als die anderen Protokolle oberhalb des Record Protokolls reicht das Application Data Protokoll die Anwendungsdaten transparent durch. Die Daten werden entsprechend der ausgehandelten Sicherheitsparameter aus dem Handshake Protokoll in dem Record Layer fragmentiert, komprimiert, gegen Verfälschung geschützt und verschlüsselt.
TLS/SSL – ChangeCipherSpec (CCS) Protokoll Das ChangeCipherSpec (CCS) Protokoll wird bei Änderung des kryptografischen Algorithmus beziehungsweise der Parameter genutzt. Es enthält nur eine Meldung bestehend aus einem Byte mit dem Wert 1. CCS bewirkt, dass der Empfänger die während des Handshakes ausgehandelten Sicherheitsparameter für die aktive Sitzung übernimmt.
TLS/SSL – Alert Protokoll Das Alert Protokoll dient der Signalisierung von besonderen Zuständen beziehungsweise Problemen wie Fehler oder Verbindungsabbruch.
TLS/SSL – Handshake Protokoll Die Handshake-Nachrichten ermöglichen den Aufbau einer TLS/SSL-Verbindung. Das Handshake Protokoll dient zur Identifikation und Authentifizierung der Kommunikationspartner sowie zum Aushandeln kryptografischer Algorithmen, Schlüssel und Parameter, die im TLS/SSL Record Layer Protokoll verwendet werden und zum Austausch benötigter vertrauenswürdiger Informationen. Das Handshake Protokoll wird in 4 Phasen unterteilt.
Der Protokollablauf bei TLS/SSL erfolgt in zwei Schritten:
1. Schritt: Verbindungsaufbau, unterteilt in 4 Phasen: – 1. Phase: Aushandlung der Sicherheitsparameter. – 2. Phase: Serverauthentisierung (Optional) und Schlüsselaustausch – 3. Phase: Clientauthentisierung (Optional) und Schlüsselaustausch – 4. Phase: Beendigung des Handshakes
2. Schritt: Transfer-Mode Verschlüsselte und integritätsgesicherte Datenübertragung
TLS 1.3
Im August 2018 wurde mit der RFC 8446 die neue Version TLS 1.3 offiziell veröffentlicht und wird seitdem von den großen Web-Browsern unterstützt. Die Ziele von TLS 1.3 sind eine erhöhte Sicherheit, ein verkürzter Handshake und ein schneller Austausch von Nutzdaten.
Die wichtigsten Neuerungen von TLS 1.3:
Perfect Forward Secrecy Eine wichtige Neuerung ist, dass ein Teil des Protokolls fest definiert ist. Für den Schlüsselaustausch müssen das Elliptic Curve Diffie-Hellman Ephemeral-Verfahren und bewährte DH-Parameter genutzt werden, sodass keine Parameter mehr mit dem Server ausgehandelt werden müssen. Dies bedeutet, dass die kryptografische Charakteristik „Perfect Forward Secrecy (PFS)“ immer umgesetzt wird. Bei der Kompromittierung eines Schlüssels sind nicht auch weitere Schlüssel aus der Vergangenheit kompromittiert, da diese nicht voneinander abhängen. Round-Trip Optimierung (1-RTT-Modus) und Verschlüsselung zu einem früheren Zeitpunkt Verbindungen können in der TLS Version 1.3 sehr viel schneller aufgebaut werden. Bei TLS 1.2 werden für einen Verbindungsaufbau 2-Round-Trips (Kommunikationsschritte) benötigt. TLS 1.3 braucht nur Round-Trip. Damit kann TLS 1.3 viel schneller mit der verschlüsselten HTTPS-Kommunikation beginnen, direkt nach dem ServerHello.
Resumption für schnellere TLS Verbindung (0-RTT-Modus) Wenn ein Client in der Vergangenheit schon mal mit einem Server verbunden war, können beide auf die bereits vorher getroffene Vereinbarung zurückgreifen und den Handshake beschleunigen. Dabei kann ein Zero Round Trip realisiert werden, das heißt, der Client sofort verschlüsselte Daten schicken. Nachteile sind: Bei einem Zero Round Trip ist keine Perfect Forward Secrecy möglich und eine Replay-Attacke könnte umgesetzt werden.
Die Cipher Suites wurden deutlich reduziert Die vielen Cipher Suites aus den vergangenen Versionen wurden sehr strakt reduziert und alle nicht sicheren gestrichen. In TLS 1.3 sind nur fünf neue und aktuelle sichere Cipher Suites definiert:
Besserer Schlüsselaustausch für mehr Integrität Bei der TLS 1.2 wird zunächst ein HMAC über die Klartextdaten gebildet und an die Daten angehängt, bevor beide gemeinsam verschlüsselt werden. In TLS 1.3 unterstützen die Cipher Suites nur noch Authenticated Encryption with Associated Data (AEAD).
Der Handshake zum Verbindungsaufbau mit TLS 1.3
Schritt 1:
Auch bei TLS 1.3 startet der Client mit einem ClientHello. Als Inhalt stehen im ClientHello eine Zufallszahl, die Session-ID, die „Angebote der: Cipher Suites“ des Clients; zusätzlich vermutet der Client, welchen Schlüsselaustauschalgorithmus der Server wohl wählen wird und sendet seinen „DH Public Key A“ mit. Durch eine Vermutung, welcher Schlüsselaustauschalgorithmus verwendet wird, wird ein Round-Trip eliminiert. Wenn der Server die Vermutung nicht bestätigt, ist ein neuer Versuch nötig, was der Server über einen HelloRetryRequest mit den unterstützten Gruppen signalisiert.
Schritt 2: Der Server kann nun aus dem „DH Public Key A“ des Clients und seinem eigenen „DH Public Key B“ bereits den Sitzungsschlüssel berechnen. Er antwortet mit einer ServerHello-Nachricht. Diese enthält eine Zufallszahl, die Session-ID, die vom Server aus den vom Client angebotenen Cipher Suites ausgewählte Cipher Suite (Auswahl einer: Cipher Suite), den gewählten Schlüsselaustauschalgorithmus, den „DH Public Key B“ des Servers, das mit dem Sitzungsschlüssel verschlüsselte Zertifikat des Servers und die Signatur eines Teils der übertragenen Daten. Und da er nun bereits einen Sitzungsschlüssel besitzt, sendet er auch sofort seine „Finished-Nachricht“. Durch die Session-ID erkennt der Client, dass ein wiederaufgenommener Handshake durchgeführt wird. Wenn der Server die vom Client gesendete Sitzungs-ID nicht akzeptiert, sendet er einen anderen Wert für seine Sitzungs-ID. Dies teilt dem Client mit, dass kein wiederaufgenommener Handshake durchgeführt wird. Zu diesem Zeitpunkt verfügen sowohl der Client als auch der Server über das “Master-Secret” und Zufallsdaten, um die für diese Verbindung zu verwendenden Schlüsseldaten zu generieren.
Schritt 3: Der Client erzeugt aus seinem „DH Public Key A“ und dem des Servers „DH Public Key B“ den Sitzungsschlüssel, entschlüsselt damit das Zertifikat und prüft das Zertifikat und die Signatur. Ist die Prüfung erfolgreich, sendet er seine Finished-Nachricht.
Schritt 4 ff: Die Nachrichten der HTTP-Verbindung werden mit dem Sitzungsschlüssel verschlüsselt.
0-RTT-Modus – Sitzungs-IDs Bei einem normalen vollständigen Handshake sendet der Server eine Sitzungs-ID als Teil der ServerHello-Nachricht. Der Client ordnet diese Sitzungs-ID der IP-Adresse und dem TCP-Port des Servers zu, sodass der Client, wenn er sich erneut mit diesem Server verbindet, die Sitzungs-ID verwenden kann, um den Handshake zu verkürzen. Im Server wird die Sitzungs-ID den zuvor ausgehandelten kryptografischen Parametern zugeordnet, insbesondere dem “Master-Secret”. Beide Seiten müssen das gleiche “Master-Secret” haben, sonst schlägt der wiederaufgenommene Handshake fehl. Die Zufallsdaten in den ClientHello- und ServerHello- Nachrichten garantieren praktisch, dass sich die generierten Verbindungsschlüssel von denen der vorherigen Verbindung unterscheiden.
Weitere Informationen zum Begriff “Transport Layer Security (TLS) – Secure Socket Layer (SSL)”:
