TLS-Handshake

Eine sichere Verbindung wird über einen Proxy mittels des TLS-Handshakes hergestellt, wobei Client und Endserver (entweder der Origin-Server oder der Proxy selbst, je nach Konfiguration) Identitäten authentifizieren und kryptografische Parameter aushandeln, um einen verschlüsselten Kommunikationskanal zu schaffen. Dieser Prozess gewährleistet Datenvertraulichkeit, -integrität und -authentizität für Anwendungen, die über Netzwerke kommunizieren.

Verständnis des TLS-Handshakes

Das Transport Layer Security (TLS)-Protokoll ist grundlegend für die Sicherung der Internetkommunikation. Es arbeitet oberhalb der Transportschicht (TCP) und bietet Ende-zu-Ende-Verschlüsselung und Authentifizierung. Der TLS-Handshake ist die anfängliche Aushandlungsphase, in der Client und Server die kryptografischen Parameter vereinbaren und eine sichere Sitzung aufbauen, bevor Anwendungsdaten ausgetauscht werden.

Die Hauptziele des TLS-Handshakes sind:
* Authentifizierung: Überprüfung der Identität des Servers (und optional des Clients) mittels digitaler Zertifikate.
* Schlüsselaustausch: Sichere Vereinbarung eines gemeinsamen geheimen Schlüssels für die symmetrische Verschlüsselung.
* Cipher-Suite-Aushandlung: Auswahl der Algorithmen für Verschlüsselung, Hashing und Schlüsselaustausch.

Schritte des direkten TLS-Handshakes

Bei einer direkten Verbindung ohne Proxy läuft der TLS-Handshake wie folgt ab:

1. Client Hello: Der Client initiiert den Handshake, indem er eine Client Hello-Nachricht sendet. Diese Nachricht enthält:
   • Unterstützte TLS-Versionen.
   • Eine Liste der unterstützten Cipher Suites.
   • Eine zufällige Byte-Sequenz (Client Random).
   • Unterstützte Kompressionsmethoden.
   • Server Name Indication (SNI) für virtuelles Hosting.
2. Server Hello: Der Server antwortet mit einer Server Hello-Nachricht und wählt aus:
   • Die zu verwendende TLS-Version.
   • Eine ausgewählte Cipher Suite aus der Liste des Clients.
   • Eine zufällige Byte-Sequenz (Server Random).
3. Zertifikat: Der Server sendet sein digitales Zertifikat, das seinen öffentlichen Schlüssel enthält und von einer Zertifizierungsstelle (CA) signiert ist. Der Client überprüft dieses Zertifikat.
4. Server Key Exchange (Optional): Falls die gewählte Cipher Suite dies erfordert (z. B. für Diffie-Hellman Ephemeral), sendet der Server Parameter für den Schlüsselaustausch.
5. Server Hello Done: Der Server signalisiert, dass er seinen Teil des anfänglichen Handshakes abgeschlossen hat.
6. Client Key Exchange: Der Client generiert ein Pre-Master-Secret, verschlüsselt es mit dem öffentlichen Schlüssel des Servers (aus dessen Zertifikat) und sendet es an den Server.
7. Change Cipher Spec (Client): Der Client sendet eine Change Cipher Spec-Nachricht, die anzeigt, dass alle nachfolgenden Nachrichten mit den ausgehandelten Schlüsseln und der Cipher Suite verschlüsselt werden.
8. Verschlüsselte Handshake-Nachricht (Client): Der Client sendet eine Finished-Nachricht, verschlüsselt mit dem neu etablierten symmetrischen Schlüssel, um die Integrität des Handshakes zu überprüfen.
9. Change Cipher Spec (Server): Der Server sendet seine eigene Change Cipher Spec-Nachricht.
10. Verschlüsselte Handshake-Nachricht (Server): Der Server sendet seine Finished-Nachricht, ebenfalls verschlüsselt.
11. Anwendungsdaten: Beide Parteien können nun verschlüsselte Anwendungsdaten austauschen.

Proxy-Typen und TLS-Handshake-Interaktion

Proxys modifizieren, wie der TLS-Handshake initiiert und verarbeitet wird, basierend auf ihrem Betriebsmodus.

Forward-Proxy (nicht-abfangend)

Ein Forward-Proxy fungiert als Vermittler für Clients, die auf externe Ressourcen zugreifen möchten. Für HTTPS-Verkehr arbeitet ein nicht-abfangender Forward-Proxy typischerweise als TCP-Tunnel. Der Client konfiguriert sich explizit für die Nutzung des Proxys.

Mechanismus:
Der Client sendet eine HTTP CONNECT-Anfrage an den Proxy, um einen TCP-Tunnel zum Origin-Server aufzubauen. Sobald der Tunnel etabliert ist, führen Client und Origin-Server den TLS-Handshake direkt durch diesen Tunnel durch. Der Proxy leitet verschlüsselte Bytes weiter, ohne sie zu entschlüsseln.

TLS-Handshake-Ablauf:
1. Client zum Proxy (TCP): Der Client stellt eine TCP-Verbindung zum Proxy her.
2. Client CONNECT-Anfrage: Der Client sendet eine HTTP CONNECT-Anfrage an den Proxy, die den Hostnamen und Port des Origin-Servers angibt (z. B. CONNECT example.com:443 HTTP/1.1).
3. Proxy zum Origin-Server (TCP): Der Proxy stellt eine TCP-Verbindung zum angegebenen Origin-Server her.
4. Proxy 200 OK: Wenn die Verbindung zum Origin-Server erfolgreich ist, antwortet der Proxy dem Client mit HTTP/1.1 200 Connection established.
5. Client zum Origin-Server (TLS über Tunnel): Der Client initiiert nach Erhalt des 200 OK den standardmäßigen TLS-Handshake direkt mit dem Origin-Server durch den etablierten TCP-Tunnel.
6. Proxy-Weiterleitung: Der Proxy leitet alle nachfolgenden verschlüsselten Bytes transparent zwischen Client und Origin-Server weiter. Er nimmt nicht am TLS-Handshake teil und entschlüsselt den Verkehr auch nicht.

Code-Beispiel: Client CONNECT-Anfrage

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
Proxy-Connection: Keep-Alive

Proxy-Antwort

HTTP/1.1 200 Connection established

Reverse-Proxy (TLS-Terminierung)

Ein Reverse-Proxy steht vor einem oder mehreren Origin-Servern und fängt Client-Anfragen ab, die für diese Server bestimmt sind. Für HTTPS-Verkehr führt ein Reverse-Proxy oft eine TLS-Terminierung durch.

Mechanismus:
Der Reverse-Proxy empfängt die HTTPS-Anfrage des Clients, beendet die TLS-Verbindung, entschlüsselt den Verkehr und stellt dann eine neue Verbindung (die TLS-verschlüsselt sein kann oder auch nicht) zum Backend-Origin-Server her.

TLS-Handshake-Ablauf:
1. Client zum Reverse-Proxy (TLS-Handshake 1):
* Der Client führt einen standardmäßigen TLS-Handshake direkt mit dem Reverse-Proxy durch.
* Der Reverse-Proxy präsentiert dem Client sein eigenes digitales Zertifikat.
* Ein sicherer, verschlüsselter Kanal wird zwischen dem Client und dem Reverse-Proxy aufgebaut.
2. Reverse-Proxy-Entschlüsselung: Der Reverse-Proxy entschlüsselt die Anfrage des Clients.
3. Reverse-Proxy zum Origin-Server (TLS-Handshake 2 oder HTTP):
* Der Reverse-Proxy initiiert dann eine neue Verbindung zum entsprechenden Backend-Origin-Server.
* Diese Verbindung kann reines HTTP sein (üblich in vertrauenswürdigen internen Netzwerken) oder eine weitere TLS-verschlüsselte Verbindung (für Ende-zu-Ende-Verschlüsselung).
* Wird TLS verwendet, agiert der Reverse-Proxy als Client und führt einen zweiten TLS-Handshake mit dem Origin-Server durch, der sein eigenes Zertifikat präsentiert.
4. Origin-Verarbeitung: Der Origin-Server verarbeitet die Anfrage und sendet die Antwort zurück an den Reverse-Proxy.
5. Reverse-Proxy-Verschlüsselung: War die Verbindung zum Client TLS-verschlüsselt, verschlüsselt der Reverse-Proxy die Antwort erneut unter Verwendung der Client-seitigen TLS-Sitzungsschlüssel.
6. Reverse-Proxy zum Client: Die verschlüsselte Antwort wird an den Client zurückgesendet.

Transparenter Proxy (MITM TLS-Abfangen)

Ein transparenter Proxy fängt den Verkehr ab, ohne dass der Client explizit für dessen Nutzung konfiguriert ist. Für HTTPS beinhaltet dies typischerweise einen Man-in-the-Middle (MITM)-Ansatz.