Transport Layer Security (TLS) / Secure Socket Layer (SSL) - Prof. Dr. Norbert Pohlmann

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:

• Authentifikation von Server und Client unter Verwendung von asymmetrischen Verschlüsselungsverfahren und elektronischen Zertifikaten.
• Vertrauliche Client-to-Server Datenübertragung mithilfe symmetrischer Verschlüsselungsverfahren unter der Nutzung eines gemeinsamen Sitzungsschlüssels.
• Sicherstellung der Integrität der transportierten Daten unter Verwendung des HMAC-Verfahrens.
• 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 IT-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:

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
  TLS_AES_128_CCM_8_SHA256

Siehe auch: Mode of Operation für Blockverschlüsselungsverfahren

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)”:

„Sicherheit zwischen Klick und Webseite – TLS/SSL: Eine Frage der Implementierung“

„Nicht abschließend – TLS-Sicherheit in der Praxis“

„Seeming Secure Layer – Erschreckende Sicherheitsdefizite bei Internet-Anwendungen“

„Selbstverteidigung – Verschlüsselung als Mittel gegen die Überwachung“

„Benutzererkennung im WLAN – Grenzen der doppelten Authentikation“

„Moderne Kommunikation zwischen Effizienz und Sicherheit. Eine kurze Geschichte der Interaktion“

„Lehrbuch Cyber-Sicherheit“

„Übungsaufgaben und Ergebnisse zum Lehrbuch Cyber-Sicherheit“

„Bücher im Bereich Cyber-Sicherheit und IT-Sicherheit zum kostenlosen Download“

„Vorlesungen zum Lehrbuch Cyber-Sicherheit“

„Europe gets its identity back“

„Actually attacks and principal strategies for cybersecurity“

„Sicherheit mit digitaler Selbstbestimmung – Self-Sovereign Identity (SSI)“

„Künstliche Intelligenz (KI) und Cybersicherheit“

„Forschungsinstitut für Internet-Sicherheit (IT-Sicherheit, Cyber-Sicherheit)“

„Master-Studiengang Internet-Sicherheit (IT-Sicherheit, Cyber-Sicherheit)“

„Marktplatz IT-Sicherheit“

„Marktplatz IT-Sicherheit: IT-Notfall“

„Marktplatz IT-Sicherheit: IT-Sicherheitstools“

„Marktplatz IT-Sicherheit: Selbstlernangebot“

„Marktplatz IT-Sicherheit: Köpfe der IT-Sicherheit“

„Vertrauenswürdigkeits-Plattform“

Summary

Article Name

Transport Layer Security (TLS) / Secure Socket Layer (SSL)

Description

Transport Layer Security (TLS) / Secure Socket Layer (SSL) der vorherrschende Internet-Sicherheitsstandard der Internet Engineering Task Force (IETF) für die Cyber-Sicherheit auf der Transport-Ebene. TLS/SSL ist anwendungsunabhängig und setzt logisch auf einem Transportprotokoll auf.

Author

Prof. Norbert Pohlmann

Publisher Name

Institut für Internet-Sicherheit – if(is)

Publisher Logo