Entmystifizierung des TLS Handshake: Was es ist und wie es funktioniert

Die Transport Layer Security (TLS) wurde entwickelt, um die Sicherheit der Netzwerkkommunikation zu erhöhen. Sie ist der Unterschied zwischen HTTP und HTTPS beim Surfen im Internet.

Die Verwendung von TLS bedeutet zusätzlichen Aufwand für den Client und den Server, hat aber auch ihre Vorteile:

•     Confidentiality: TLS wraps traffic in an encrypted tunnel.  This makes it impossible for an eavesdropper to read or modify the traffic on its way to its destination.
•     Authentication: TLS proves the identity of the server to the client.  This is helpful in protecting against phishing sites.
•     Integrity: TLS includes protections that help with identifying if data has been modified or corrupted in transit.

All dies sind wertvolle Funktionen beim Surfen im Internet. Aus diesem Grund ist TLS so beliebt und die meisten Besuche auf einer Website beginnen mit einem TLS Handshake.

Was ist der TLS Handshake?

Wie ein Händedruck im wirklichen Leben ist der TLS Handshake eine Einführung. Er stellt fest, dass zwei Computer auf sichere Weise miteinander kommunizieren wollen.

Ein TLS Handshake definiert auch einige der Regeln für dieses Gespräch. Sowohl der Client als auch der Server sind sich einig, dass sie die Vorteile von TLS nutzen wollen, müssen sich aber noch über die Einzelheiten einigen. Ein TLS Handshake bringt sie von einem anfänglichen "Hallo" zu dem Punkt, an dem sie anfangen können, sich privat zu unterhalten.

Bevor wir in die Details des TLS Handshakes eintauchen, ist es wichtig, einige wichtige Begriffe zu verstehen. TLS ist ein sicherheitsorientiertes Protokoll, was bedeutet, dass es eine Menge Kryptographie verwendet. Einige wichtige Begriffe, die man kennen sollte, wenn man über TLS spricht, sind:

• Asymmetric Encryption: Asymmetric or “public key” cryptography uses two related keys: a public and a private key.  Anything encrypted with a public key can be decrypted with the corresponding private key.  Similarly, a digital signature generated with a private key can be validated with the associated public key.
• Symmetric Encryption: Symmetric encryption uses the same key for both encryption and decryption.  This is useful because it is more efficient than encryption with asymmetric cryptography.  The TLS handshake is designed to set up a shared symmetric encryption key.
• Cipher Suites: A cipher suite is a combination of cryptographic algorithms used in the TLS protocol.  This includes an asymmetric encryption algorithm for the handshake, a symmetric encryption algorithm for encrypting the data sent over the connection, a digital signature algorithm, and a hash function used for verifying that data has not been corrupted in transit.
• Digital Certificate: A digital certificate proves the ownership of a public key.  Servers present a digital certificate during the TLS handshake so that the client knows that they’re communicating with the right person.

Einblick in den TLS Handshake

Das Ziel des TLS Handshake ist es, dass sich Client und Server auf sichere Weise auf einen gemeinsamen symmetrischen Verschlüsselungsschlüssel einigen. Zu diesem Zweck verwenden sie die asymmetrische Verschlüsselung, die es ermöglicht, verschlüsselte Nachrichten nur mit einem öffentlichen Schlüssel zu versenden.

Die Einzelheiten des TLS Handshake hängen vom verwendeten asymmetrischen Verschlüsselungsalgorithmus ab. Ein Client und ein Server, die RSA verwenden, durchlaufen die folgenden Schritte:

*Bildquelle

1. Client Hello: The client kicks off the TLS handshake by sending configuration information to the server.  This includes data like the TLS version(s) supported by the client, which cipher suites it can use, and some random data called the “client random”.
2. Server Hello: The server responds with a message including its choices of TLS version and cipher suite, its digital certificate, and the “server random”.
3. Premaster Secret: The digital certificate provided by the server contains its public key, which can be used for encrypting messages sent to the server.  After verifying the validity of the certificate, the client generates another random value called the premaster secret.  Using the server’s public key, the client encrypts this value and sends it to the server.
4. Session Keys: The server uses its private key to decrypt the premaster secret.  At this point, both the client and the server have the client random, server random, and the premaster secret.  From these, they calculate a shared session key.  Since the premaster secret is a secret value – it was only sent in an encrypted form over the network – the session key is secret as well.
5. Client Finished: To complete the TLS handshake, the client sends a message to the server that is encrypted with the session key.  The server decrypts this message and verifies its correctness.  If it matches, the server knows that the client correctly calculated the session key.
6. Server Finished: The server also sends a message encrypted with the shared session key.  Decrypting and verifying this message proves to the client that the server correctly calculated the session key.

Zu diesem Zeitpunkt haben der Client und der Server einen gemeinsamen Verschlüsselungsschlüssel, den nur sie kennen. Für den Rest der Sitzung TLS werden alle Nachrichten mit diesem Sitzungsschlüssel verschlüsselt.

Eine alternative Struktur

Wie bereits erwähnt, kann die Verwendung verschiedener asymmetrischer Verschlüsselungsalgorithmen zu kleinen Änderungen in den Schritten führen. Wenn der Client und der Server beispielsweise Diffie-Hellman anstelle von RSA verwenden, wird der Inhalt der in den Schritten 2 und 3 gesendeten Nachrichten leicht verändert:

• In Schritt 2 sendet der Server ein digital signiertes Paket, das den Zufallswert des Clients, den Zufallswert des Servers und den Diffie-Hellman-Parameter enthält.
• Nach der Validierung der digitalen Signatur antwortet der Client mit einer Nachricht, die seinen Diffie-Hellman-Parameter anstelle eines Premaster-Geheimnisses enthält.

Mit diesen Diffie-Hellman-Parametern und den Client- und Server-Randomwerten können Client und Server einen gemeinsamen, geheimen privaten Schlüssel berechnen. Letztendlich führen Diffie-Hellman und RSA auf leicht unterschiedliche Weise zum gleichen Ergebnis.

Mehr als der einfache Händedruck

Der hier beschriebene Prozess ist der grundlegende TLS Handshake, der in den meisten TLS Sitzungen verwendet wird. Es ist jedoch möglich, zusätzliche Schritte hinzuzufügen, die bestimmte Vorteile bieten.

Der grundlegende TLS Handshake verwendet beispielsweise ein digitales Zertifikat, um den Server gegenüber dem Client zu authentifizieren, aber er authentifiziert den Client nicht gegenüber dem Server. Eine modifizierte Version des TLS Handshake kann das digitale Zertifikat eines Clients auch an den Server senden und so eine gegenseitige Authentifizierung erreichen.