Wie SSL/TLS Handshake funktioniert

Verschlüsselung der Daten

Der Handshake-Prozess wird zwangsläufig von einem Informationsaustausch über die unterstützten kryptografischen Technologien begleitet – dies ist notwendig, damit sich Server und Client auf die für beide Parteien beste Cipher-Suite einigen können. Der Server überträgt sein SSL-Zertifikat an den Client, sobald es vereinbart wurde.

Die symmetrische Verschlüsselung verhindert das Mitlesen der Daten durch Dritte. Und selbst wenn Pakete abgefangen werden, können sie nicht verändert werden, da jede Nachricht einen MAC-Code enthält, der die Integrität der Daten überprüft.

Wie SSL/TLS-Handshaking funktioniert

Wenn Sie sich das SSL-Handshaking als einen Dialog zwischen einem Server und einem Client vorstellen, würde der Prozess wie folgt aussehen

1. Der Client fordert den Server auf, eine sichere Verbindung herzustellen, und bietet eine Cipher Suite an, die er "versteht", sowie eine kompatible Version von SSL/TLS.
2. Der Server prüft die gesendete Cipher Suite, vergleicht sie mit seiner eigenen und sendet dem Client eine Antwort mit einer Zertifikatsdatei und einem öffentlichen Schlüssel.
3. Der Client prüft das Zertifikat und bietet, wenn es in Ordnung ist, an, den privaten Schlüssel zu überprüfen. Dazu erzeugt er ihn und verschlüsselt den gemeinsamen geheimen Schlüssel mit dem zuvor gesendeten öffentlichen Schlüssel des Servers.
4. Der Server nimmt den Schlüssel an und verifiziert ihn mit seinem privaten Schlüssel. Anschließend wird ein Master Secret erstellt, das zur Verschlüsselung der ausgetauschten Informationen verwendet wird.

Der Client sendet dann eine Testnachricht an den Server, die mit einer zuvor ausgearbeiteten Methode verschlüsselt wurde, und der Server entschlüsselt und analysiert sie. Damit ist der SSL/TLS-Handshake abgeschlossen, und Client und Server können weiter Informationen austauschen.

Wenn die Sitzung beendet wird und der Client den Server einige Zeit später erneut kontaktiert, muss das "Handshake"-Verfahren nicht erneut durchlaufen werden – alle zuvor generierten Daten und das Hauptgeheimnis bleiben gültig. Der gesamte Vorgang dauert nur wenige Sekunden und ist für den Benutzer völlig unbemerkt.



Diffie-Hellman-Algorithmus in TLS Handshake 1.2

Die Version 1.2 des TLS-Protokolls erschien 2008 als umfassende Aktualisierung des Protokolls 1.1 mit einem verbesserten Mechanismus, der es den Parteien ermöglicht, sich auf Listen der unterstützten Verschlüsselungsmethoden zu einigen. Sie sieht folgendermaßen aus:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Hier:

• TLS – Datenübertragungsprotokoll;
• ECDHE – ein temporärer (ephemerer) Schlüssel;
• ECDSA – Authentifizierungsalgorithmus;
• AES 128 GCM – symmetrischer Verschlüsselungsalgorithmus;
• SHA256 – Hash-Algorithmus für Daten.

Dabei handelt es sich um den Diffie-Hellman-Algorithmus, der jedoch inzwischen als veraltet gilt und kaum noch verwendet wird.

TLS Cipher Suite 1.3

Diese Version des Protokolls erblickte 2018 das Licht der Welt und wurde in einigen Punkten erheblich verbessert:

• Schlüsselaushandlungsprozesse, Authentifizierungsprozesse und Cipher Suites wurden getrennt;
• wurde eine Regel hinzugefügt, die besagt, dass digitale Signaturen obligatorisch sind;
• HKDF-Schlüsselabfragefunktion implementiert;
• Die Verbindungsprozesse wurden beschleunigt;
• Datenkomprimierung, nicht authentifizierte Nachrichtenchiffren und Neuaushandlung, die der vorherigen Version des Protokolls eine gewisse Anfälligkeit verliehen, wurden verboten;
• Hinzufügung von ChaCha20 Stream Cipher mit Poly1305 MAC Code, effizienten Ed25519 und Ed448 digitalen Signieralgorithmen und entsprechenden Schlüsselaustauschprotokollen Curve25519 und Curve448.

Das TLS 1.3-Handshake-Verschlüsselungspaket sieht folgendermaßen aus

TLS_AES_256_GCM_SHA384

Dementsprechend hier:

• TLS-Protokoll;
• AES-256 im GCM-Modus – Algorithmus zur Verschlüsselung und Authentifizierung mit zusätzlichen Daten (AEAD);
• SHA384 – Algorithmus zur Erzeugung einer Hash-Schlüsselfunktion (HKFD).

Das TLS 1.3-Protokoll hat eine Vielzahl von Änderungen und Verbesserungen erfahren, die sich positiv auf die Sicherheit und die Leistung von Handshake-Prozessen auswirken. Die Authentifizierung selbst nimmt deutlich weniger Zeit in Anspruch. Die Handshake-Geschwindigkeit hat sich fast verdoppelt, und das Protokoll weist keine Schwachstellen mehr auf, die früher Systemadministratoren zu schaffen machten.

Schlussfolgerung

Die sicherste Option ist das Verschlüsselungsprotokoll TLS 1.3, das jedoch nur bedingt abwärtskompatibel ist. Wenn eine Verbindung hergestellt wird, tauschen Client und Server Versionen des Protokolls aus, und es wird diejenige ausgewählt, mit der beide Parteien arbeiten können. In der Praxis stellte sich jedoch heraus, dass eine Reihe von Servern, auf denen das alte TLS 1.2-Protokoll lief, die Verbindung sofort abbrachen, wenn der "Handschlag"-Prozess über das TLS 1.3-Protokoll stattfand. Dieses Phänomen wurde als Ossifikation bezeichnet und verursachte in den ersten Jahren Probleme bei der Implementierung des neuen Protokolls. Heutzutage gibt es dieses Problem so gut wie nicht mehr, und die Server selbst sind weitgehend auf TLS 1.3 umgestiegen, so dass wir dessen Verwendung empfehlen.