Funktionsweise
- Client baut eine Verbindung zum Server auf.
- Server authentifiziert sich gegenüber dem Client mit einem Zertifikat
- Client überprüft hierbei die Vertrauenswürdigkeit 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-Schlüsselaustausch 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 Symmetrisches Verschlüsselungsverfahren verschlüsseln
- Schutz von Integrität und Authentizität durch einen Message Authentication Code gewährleistet.
TLS-Protokolle im Protokollstapel
- Im OSI-Modell in Schicht 5 angeordnet.
- Im TCP/IP-Modell ist TLS oberhalb der Transportschichtund unterhalb Anwendungsprotokollen angeordnet
- Spezifikationen wird dies dann zum Beispiel als „HTTP over TLS“ bezeichnet. S
- beide Protokolle zusammengefasst betrachtet werden, wird üblicherweise ein „S“ für Secure angehängt
- TLS arbeitet transparent, so dass es leicht eingesetzt werden kann
- Beispielsweise mit STUNNEL
Aufbau
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
- TLS Record Protocol ist die untere der beiden Schichten und dient zur Absicherung der Verbindung.
- setzt direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste
- Diese können einzeln oder gemeinsam genutzt werden
Ende-zu-Ende-Verschlüsselung
- mittels Symmetrisches Kryptosystem
- verwendeteR Schlüssel wird dabei im Voraus über ein weiteres Protokoll (zum Beispiel das TLS Handshake Protocol) ausgehandelt
- kann nur einmal für die jeweilige Verbindung verwendet werden.
- Es wird symmetrische Verschlüsselung unterstützt (DES, 3DES und AES)
Sicherung der Integrität und Authentizität
- durch einen Message Authentication Codein der Regel HMAC
Aufbau einer TLS-Record-Nachrich
- 1 Byte: Change Cipher Spec = 20 Alert = 21, Handshake = 22, Application Data = 23
- 1 Byte: Protokollversion Major
- 1 Byte: Protokollversion Minor
- 2 Byte: Länge
TLS Handshake Protocol
- Baut auf dem TLS Record Protocol auf und erfüllt die folgenden Funktionen
- Aushandeln zu benutzender kryptografischer Algorithmen und Schlüssel.
- Identifikation und Authentifizierung der Kommunikationspartner
- Basis sind Asymmetrischer Verschlüsselungsverfahren und Public-Key-Infrastruktur
- Server authentifiziert sich gegenüber dem Client
- Optional authentifiziert sich auch der Client gegenüber dem Server
Handshake selbst kann in vier Phasen unterteilt werden
- Client schickt zum Server ein ClientHello, und der Server antwortet dem Client mit einem ServerHello. Die Parameter der Nachrichten sind:
- die höchste vom Client unterstützte TLS-Protokoll-Version
- eine 32 Byte lange Zufallsinformation wird später verwendet pre-master-secret, zum Schutz vor Replay-Attackenm zu bilden
- 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-Schlüsselaustausch) werden die Key-Shares übertragen, die den gemeinsamen Schlüssel definieren.
- Der Server identifiziert sich gegenüber dem Client.
- Hierzu wird per Certificate ein Zertifikat an den Client geschickt, gefolgt von einem CertificateVerify
- CertificateVerify Nachricht enthält eine Unterschrift von zuvor ausgetauschten Nachrichten.
- Server beweist, dass er einen Secret-Key besitzt, der zu dem auf dem Server-Zertifikat enthaltenen passt.
- Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab.
- Das zuvor erhaltene Server-Zertifikat enthält den öffentlichen Schlüssel des Servers
- Wird eine Cipher Suite mit RSA-Schlüsselaustausch verwendet
- 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-Schlüsselaustausch verwendet werden
- dann wird ein gemeinsames pre-master-secret zu generieren.
- Wenn 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.
- Diese Phase schließt den Handshake ab.
- Aus dem vorhandenen pre-master-secret kann das master secret abgeleitet werden
- ein einmaligen Sitzungsschlüssel
- Aus dem master secret werden wiederum Schlüssel abgeleitet
- zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden.
- Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden sind verschlüsselt übertragen
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.
- Protokoll wurde gewählt weil man expliziert keine Record Übertragung wollte.
TLS 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<ref name="schwenk2010">Schwenk, Jörg (2010): Sicherheit und Kryptographie im Internet. Von sicherer E-Mail bis zu IP-Verschlüsselung, herausgegeben von Vieweg+Teubner Verlag / GWV Fachverlage GmbH, Wiesbaden. ISBN 978-3-8348-0814-1.</ref>)
|
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:<ref name="schwenk2010" />
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
- in Abhängigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt.
- Inhaltlich werden sie von TLS nicht näher interpretiert.
Berechnung des Master Secrets
- TLS 1.2 mit Hilfe einer durch eine Cipher Suite spezifizierten Pseudozufallsfunktion das Master Secretberechnet.
- 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.
Quelle