Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

Funktionsweise

Der Client baut eine Verbindung zum Server auf

Der Server authentifiziert sich gegenüber dem Client mit einem Zertifikat
Der Client überprüft hierbei die Vertrauenswürdigkeit des X.509-Zertifikats und ob der Servername mit dem Zertifikat übereinstimmt
Optional kann sich der Client mit einem eigenen Zertifikat auch gegenüber dem Server authentifizieren
Dann schickt entweder der Client dem Server eine mit dem öffentlichen Schlüssel des Servers verschlüsselte geheime Zufallszahl, oder die beiden Parteien berechnen mit dem Diffie-Hellman ein gemeinsames Geheimnis
Aus dem Geheimnis wird dann ein kryptographischer Schlüssel abgeleitet
Dieser Schlüssel wird in der Folge benutzt, um alle Nachrichten der Verbindung mit einem symmetrischen Verschlüsselungsverfahren zu verschlüsseln und zum Schutz von Nachrichten-Integrität und Authentizität durch einen Message Authentication Code abzusichern

TLS-Protokolle im Protokollstapel

Im OSI-Modell ist TLS in Schicht 5 (der Sitzungsschicht) angeordnet

Im TCP/IP-Modell ist TLS oberhalb der Transportschicht (zum Beispiel TCP) und unterhalb Anwendungsprotokollen wie HTTP oder SMTP angesiedelt
In den Spezifikationen wird dies dann zum Beispiel als „HTTP over TLS“ bezeichnet
Sollen jedoch beide Protokolle zusammengefasst betrachtet werden, wird üblicherweise ein „S“ für Secure dem Protokoll der Anwendungsschicht angehängt (zum Beispiel HTTPS)
TLS arbeitet transparent, so dass es leicht eingesetzt werden kann, um Protokollen ohne eigene Sicherheitsmechanismen abgesicherte Verbindungen zur Verfügung zu stellen
Zudem ist es erweiterbar, um Flexibilität und Zukunftssicherheit bei den verwendeten Verschlüsselungstechniken zu gewährleisten

Das TLS-Protokoll besteht aus zwei Schichten:

TLS Handshake Protocol	TLS Change Cipher Spec Protocol	TLS Alert Protocol	TLS Application Data Protocol
TLS Record Protocol

TLS Record Protocol

Das TLS Record Protocol ist die untere der beiden Schichten und dient zur Absicherung der Verbindung

Es setzt direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste, die einzeln oder gemeinsam genutzt werden können:

Ende-zu-Ende-Verschlüsselung mittels symmetrischer Algorithmen
Der verwendete Schlüssel wird dabei im Voraus über ein weiteres Protokoll (zum Beispiel das TLS Handshake Protocol) ausgehandelt und kann nur einmal für die jeweilige Verbindung verwendet werden
TLS unterstützt für die symmetrische Verschlüsselung unter anderem DES, Triple DES und AES
Sicherung der Nachrichten-Integrität und Authentizität durch einen Message Authentication Code, in der Regel HMAC

Außerdem werden zu sichernde Daten in Blöcke von maximal 16.384 (2¹⁴) Byte fragmentiert und beim Empfänger wieder zusammengesetzt

Dabei schreibt der Standard vor, dass die Blockgröße diesen Wert nicht übersteigt, außer der Block ist komprimiert oder verschlüsselt – dann darf die Blockgröße um 1024 Byte (bei Kompression) bzw. 2048 Byte (bei Verschlüsselung) größer sein
Auch können die Daten vor dem Verschlüsseln und vor dem Berechnen der kryptografischen Prüfsumme komprimiert werden
Das Komprimierungsverfahren wird ebenso wie die kryptografischen Schlüssel mit dem TLS Handshake-Protokoll ausgehandelt

Der Aufbau einer TLS-Record-Nachricht lautet wie folgt: Content Type (1 Byte: Change Cipher Spec = 20, Alert = 21, Handshake = 22, Application Data = 23) | Protokollversion Major (1 Byte) | Protokollversion Minor (1 Byte) | Länge (1 Short bzw

zwei Byte)

TLS Handshake Protocol

Das TLS Handshake Protocol baut auf dem TLS Record Protocol auf und erfüllt die folgenden Funktionen, noch bevor die ersten Bits des Anwendungsdatenstromes ausgetauscht wurden:

Aushandeln zu benutzender kryptografischer Algorithmen und Schlüssel
TLS unterstützt auch eine unverschlüsselte Übertragung
Identifikation und Authentifizierung der Kommunikationspartner auf Basis asymmetrischer Verschlüsselungsverfahren und Public-Key-Kryptografie
Dieser Schritt ist optional eine Zwei-Wege-Authentifizierung (in diesem Fall wird manchmal von mutual TLS gesprochen), für gewöhnlich authentifiziert sich aber nur der Server gegenüber dem Client

Der Handshake selbst kann in vier Phasen unterteilt werden:

Der Client schickt zum Server ein ClientHello, und der Server antwortet dem Client mit einem ServerHello

Die Parameter der Nachrichten sind:

- die Version (die höchste vom Client unterstützte TLS-Protokoll-Version)
- eine 32 Byte lange Zufallsinformation (4 Byte Timestamp + 28 Byte lange Zufallszahl), die später verwendet wird, um das pre-master-secret zu bilden (sie schützt damit vor Replay-Attacken)
- eine Session-ID
- die zu verwendende Cipher Suite (Algorithmen für Schlüsselaustausch, Verschlüsselung und Authentifizierung)
- Optional den gewünschten FQDN für die Unterstützung von Server Name Indication
- in der TLS 1.3 Version (mit Diffie-Hellman) werden hier auch schon die Key-Shares übertragen, die den gemeinsamen Schlüssel definieren
Der Server identifiziert sich gegenüber dem Client

Hierzu wird per Certificate ein X.509v3-Zertifikat an den Client geschickt, gefolgt von einem CertificateVerify (in einigen TLS Versionen)
Die CertificateVerify Nachricht enthält eine Unterschrift von zuvor ausgetauschten Nachrichten
Damit beweist der Server, dass er einen Secret-Key besitzt, der zu dem auf dem Server-Zertifikat enthaltenen Public-Key passt
Der Client prüft das Zertifikat und die Unterschrift
Bei Misserfolg bricht der Client die Verbindung ab
Außerdem kann der Server optional per CertificateRequest ein Zertifikat zur Client-Authentifizierung anfordern
Diese Phase darf nur weggelassen werden, wenn eine anonyme Cipher Suite ohne Authentifizierung verwendet wird

Das zuvor erhaltene Server-Zertifikat enthält den öffentlichen Schlüssel des Servers

Wird eine Cipher Suite mit RSA-Schlüsselaustausch verwendet (siehe Abbildung), so wird das vom Client generierte pre-master-secret mit diesem öffentlichen Schlüssel verschlüsselt und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden
Alternativ kann hier auch der Diffie-Hellman verwendet werden, um ein gemeinsames pre-master-secret zu generieren
Werden die Diffie-Hellman-Geheimnisse von Server und Client während des Handshakes frisch und zufällig ausgehandelt, sind die Voraussetzungen für Perfect Forward Secrecy erfüllt
Nach der Übertragung des pre-master-secrets identifiziert sich der Client mittels Zertifikat gegenüber dem Server, sofern dieser einen CertificateRequest geschickt hat
Dazu schickt der Client per Certificate das Client-Zertifikat, gefolgt von einem CertificateVerify. Die CertificateVerify Nachricht enthält eine Unterschrift aller zuvor ausgetauschten Nachrichten
Damit beweist der Client gegenüber dem Server, dass er einen Secret-Key besitzt, der zu dem auf dem Client-Zertifikat enthaltenen Public-Key passt
Ab hier ist dem Server also bekannt, mit wem er kommuniziert

Diese Phase schließt den Handshake ab

Aus dem vorhandenen pre-master-secret kann das master secret abgeleitet werden, das einen einmaligen Sitzungsschlüssel () darstellt
Aus dem master secret werden wiederum Schlüssel abgeleitet, die zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden
Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch verschlüsselt übertragen
Falls sich der Server nicht im Schritt 2 via CertificateVerify authentifiziert hat, ist dem Client erst nach dem Erhalt der ersten verschlüsselten Nachricht bekannt, dass er mit dem rechtmäßigen Besitzer des Zertifikats kommuniziert

TLS Change Cipher Spec Protocol

Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht

Diese Nachricht ist ein Byte groß und besitzt den Inhalt 1
Durch diese Nachricht teilt der Sender dem Empfänger mit, dass er in der aktiven Sitzung auf die im Handshake Protocol ausgehandelte Cipher Suite wechselt
Ein wesentlicher Grund für die Definition eines eigenen Protokolls für diese Nachricht besteht darin, dass TLS-Implementierungen mehrere Nachrichten eines Protokolls in einem Record (also einer TLS-Dateneinheit) zusammenfassen können
Für die Nachricht „Change Cipher Spec“ ist das unerwünscht
Weil Records verschiedener Protokolle nicht zusammengefasst werden dürfen, ist das Problem durch Definition eines eigenen Protokolls gelöst

TLS Alert Protocol

Das Alert Protocol unterscheidet etwa zwei Dutzend verschiedene Mitteilungen

Eine davon teilt das Ende der Sitzung mit (close_notify)
Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten Zertifikate
Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden

Der Aufbau einer Fehlermeldung lautet wie folgt: AlertLevel (1 Byte: Warning = 1, Fatal = 2) | AlertDescription (1 Byte: close_notify = 0, […], no_renegotiation = 100)

In der Spezifikation von TLS werden die folgenden schweren Fehlertypen definiert:

unexpected_message	Unpassende Nachricht wurde empfangen
bad_record_mac	Ein falscher MAC wurde empfangen
decompression_failure	Dekomprimierungsalgorithmus empfing unkorrekte Daten
handshake_failure	Absender konnte keine akzeptable Menge von Sicherheitsparametern bearbeiten
illegal_parameter	Ein Feld in der Handshake-Nachricht lag außerhalb des erlaubten Bereichs oder stand im Widerspruch mit anderen Feldern

In der Spezifikation von TLS werden die folgenden Warnungen definiert

close_notify	Teilt Empfänger mit, dass Absender keine weiteren Nachrichten auf dieser Verbindung senden wird Muss von jedem Partner einer Verbindung als letzte Nachricht gesendet werden
no_certificate	Kann als Antwort auf eine Zertifikatanforderung gesendet werden, falls passendes Zertifikat nicht verfügbar ist. (Wurde in TLS 1.0 entfernt)
bad_certificate	Empfangenes Zertifikat war unvollständig oder falsch
unsupported_certificate	Der Typ des empfangenden Zertifikats wird nicht unterstützt
certificate_revoked	Zertifikat wurde vom Unterzeichner zurückgerufen
certificate_expired	Zertifikat ist abgelaufen
certificate_unknown	Andere, nicht genau spezifizierte Gründe sind beim Bearbeiten des Zertifikats aufgetreten, die dazu führen, dass das Zertifikat als ungültig gekennzeichnet wurde

In der Spezifikation von TLS 1.0 wurden folgende Warnungen ergänzt

decryption_failed	Entschlüsselung fehlgeschlagen
record_overflow
unknown_ca	Unbekannte oder nicht vertrauenswürdige CA
access_denied	Zugriff verweigert
decode_error	Decodierungsfehler
decrypt_error	Entschlüsselungsfehler
export_restriction	Exportbeschränkung
protocol_version	Veraltete Version von TLS/SSL
insufficient_security	Unzureichende Sicherheit
internal_error	Interner Fehler
user_canceled	Abbruch durch Benutzer
no_renegotiation

TLS Application Data Protocol

Die Anwendungsdaten werden über das Record Protocol transportiert, in Teile zerlegt, komprimiert und in Abhängigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt

Inhaltlich werden sie von TLS nicht näher interpretiert

Berechnung des Master Secrets

Aus dem pre-master-secret wird in früheren Protokollversionen mit Hilfe der Hashfunktionen SHA-1 und MD5, in TLS 1.2 mit Hilfe einer durch eine Cipher Suite spezifizierten Pseudozufallsfunktion das Master Secret berechnet

In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein
Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das Master Secret immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt
In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt

TMP