 | TLS-Handshake-Protokoll
 | besteht aus drei Unterprotokollen,
mit denen die Kommunikationspartner
 | Sicherheitsparameter für das TLS-Record-Protokoll austauschen können, |
| sich selbst authentisieren können, |
| ausgehandelte Sicherheitsparameter instanzieren können, |
| Fehlermeldungen austauschen können. |
|
| Das Handshake-Protokoll handelt eines TLS-Sitzung aus, die durch folgende
Parameter spezifiziert ist:
| Sitzung-Identifizierung, |
| Zertifizierung der Gegenstelle, |
| Kompressions-Methode, |
| Cipher-Spec legt die verwendeten Chiffren fest, |
| Master-Secret zur Schlüsselberechnung, |
| Fortsetzungsflag, um neue TLS-Sitzungen zu kreieren. |
|
|
| Change-Cipher-Spec-Protokoll
| Änderung in der
Verschlüsselungsstrategie,
| z.B. um Verschlüsselungsverfahren zu ändern |
| andere Schlüssel verwenden |
| beim Handshake-Verfahren
zur Aufnahme der Datenübertragung |
|
| Change-Cipher-Spec-Nachricht
|
bewirkt beim Empfänger Kopieren der aktuellen Pending-State-Parameter in
Current-State |
|
|
| Alert-Protokoll
| sendet im Fehlerfall Warnung an Gegenstelle |
| Art und Schwere des Fehlers dargestellt |
|
"Fatale" Fehler führen zu Abbruch der Verbindung |
| andere
Sitzungen dürfen fortgesetzt werden |
| Sitzungsidentifikator (session
identifier) muss ungültig
gemacht werden |
| Alert-Nachrichten werden verschlüsselt und
komprimiert übertragen |
|
| Closure-Alert
| garantiert ordnungsgemäßen Abbruch einer Verbindung |
| kein Angriff durch nicht beendete Sitzungen (truncation attack). |
| Closure-Alert kann jeder
Teilnehmer jederzeit auslösen, ehe er Sitzung beendet |
| auslösender
Teilnehmer braucht nicht auf entsprechende Antwort der Gegenstelle zu warten |
| Ein Fehler-Alert kann folgende Nachrichten beinhalten:
| unexpected_message |
| bad_record_mac |
| decryption_failed |
| record_overflow |
| decompression_failure |
| handshake_failure |
| bad_certificate |
| unsupported_certificate |
| certificate_revoked |
| certificate_expired |
| certificate_unknown |
| illegal_parameter |
| unknown_ca |
| access_denied |
| decode_error |
| decrypt_error |
| export_restriction |
| protocol_version |
| insufficient_security |
| internal_error |
| user_canceled |
| no_renegotiation |
|
| Einige dieser Nachrichten legen die schwere des Fehlers fest
| z.B.
bad_record_mac ist stets fatal |
|
| andere lassen dem Sender die Möglichkeit,
diese selbst zu bestimmen |
|
| TLS-Handshake-Protokoll dient dem Aushandeln der o.g.
Sicherheits-Parameter einer Verbindung.
| arbeitet oberhalb des
TLS-Record-Layers |
| besteht aus folgenden Schritten:
| In Hello-Nachrichten wird sich
| über Algorithmen geeinigt und |
|
Zufallszahlen ausgetauscht. |
|
| Danach wird ein Premaster-Secret vereinbart. |
| Client und Server können sich gegeneinander authentifizieren. |
| Danach wird aus dem Master-Secret ein Premaster-Secret abgeleitet. |
| Dem Record-Layer werden Sicherheitsparameter übergeben. |
| Client und Server können sich vergewissern, dass
| Gegenstelle die
gleichen Sicherheitsparameter verwendet |
| kein Angreifer in
Handshake eingemischt hat |
|
|
|
| Angreifer kann u.U. erreichen, dass
| zwei Kommunikationspartner
geringste Sicherheitsstufe aushandeln,
| beispielsweise Port
blockiert oder |
| unauthentifizierte Verbindungen aufbaut |
|
| die
Anwendungsschichten sollten über ausgehandelte Sicherheitsstufe informiert
werden |
|
Der Standard empfiehlt ausdrücklich,
| Daten nicht über 40 Bit Schlüssel-
Algorithmen zu versenden |
| wenn für Benutzer entsprechenden Wert darstellen |
|
|
| Das TLS-Protokoll soll diese Sicherheitsanforderungen unterstützen. |
| Um
Verbindung aufzunehmen,
| sendet Client ein "client hello"-Nachricht
an Server, |
| Server antwortet mit "server hello"-Nachricht
(andernfalls fataler Fehler) |
| In diesen Nachrichten werden Security-Parameter ausgetauscht. |
|
