Get oder Post

[Christian Seiler]

Hallo Sven,

HTTPS funktioniert nun so: [...] Über diese TCP-Verbindung wird nun ein TLS/SSL-Handshake durchgeführt und somit ein verschlüsselter, authentifizierter (!) Tunnel zwischen Browser und Server aufgebaut. Über diesen Tunnel wandern dann ganz normale die HTTP-Requests.
Router dazwischen bekommen wieder nur Quell-IP, Quell-Port, Ziel-IP, Ziel-Port mit.

Naja, wie ist denn sichergestellt, dass eben die Router -  nehmen wir mal an, jemand würde dort ordentlich mitschneiden - nichts mitkriegen? Zum Aufbau der verschlüsselten Verbindung müssen die Schlüssel ja erst mal ausgetauscht werden, womit sich die Verschlüsselung erübrigt, denn was bringt denn Verschlüsselung, wenn ich meinem Feind vorher den Schlüssel gebe?

Das ist das geniale an asymmetrischen Verschlüsselungsverfahren: Es müssen nur die öffentlichen Schlüssel ausgetauscht werden, die privaten Schlüssel behält jeder für sich. Damit kann jemand so viele übertragene Schlüssel abfangen, wie er will, er wird daraus den privaten Schlüssel nicht ableiten können (unter der Voraussetzung, dass das Verschlüsselungsverfahren keine systematischen Fehler aufweist und die Schlüssellänge groß genug ist, dass ein Versuch länger brauchen würde, als das Alter des Universums oder so ähnlich). Und dann können beide einen gemeinsamen, symmetrischen Schlüssel austauschen, der für die eigentliche Kommunikation verwendet wird (asymmetrische Verschlüsselung ist zu langsam dafür).

Außer asymmetrischen Verschlüsselungsverfahren gibt's übrigens noch die Möglichkeit, ein Schlüsseltauschverfahren einzusetzen, z.B. Diffie-Hellman. Damit kann zwischen zwei Parteien ein Schlüssel ausgetauscht werden, ohne dass der komplette Schlüssel jemals über die Leitung wandern würde, beide Parteien hinterher jedoch den gleichen Schlüssel haben.

Zwei mögliche Probleme:

1. Man-in-the-middle-Attacken, d.h. der Client tauscht in Wirklichkeit mit dem Router aus und der wiederum mit dem Server und der Router würde jegliche Kommunikation dazwischen immer hin- und herkopieren und dabei aber auch mitschneiden. Für diesen Fall gibt es wie erwähnt Zertifikate, damit sich zumindest der Server authentifizieren kann (es gibt auch Client-Zertifikate, und die Browser unterstützen diese auch, allerdings habe ich noch niemanden gesehen, der das tatsächlich einsetzt; für die Client-Authentifizierung wird dann meistens doch so etwas "profanes" wie ein Passwort verwendet).

2. Fehler in der Handshake-Implementierung bzw. im Design des Handshake-Verfahrens. Dies ist ein kryptographish sehr heikler Punkt, da sehr viele (auch sehr schlaue) Leute da schon sehr viel falsch gemacht haben. Ich habe selbst viel zu wenig Ahnung und Erfahrung, als dass ich es mir zutrauen würde, so ein Verfahren beurteilen oder gar entwerfen zu können. Das Verfahren jedoch, das zum Beispiel bei TLS eingesetzt wird, wurde von vielen Sicherheitsexperten überprüft und meines Wissens hat bisher keiner eine Schwäche darin gefunden, d.h. wenn die TLS-Implementierung sauber ist, sollte TLS eine annehmbare Sicherheit bieten.

Viele Grüße,
Christian