Get oder Post

[Der Martin]

Hallo,

ich glaube, so langsam vestehe ich das Prinzip zumindest ansatzweise, auch wenn mir einiges noch wie schwarze Magie vorkommt. Allein aus den Daten, die beim Diffie-Hellman-Handshake ausgetauscht werden, kann man also noch nicht die nachher übertragenen Daten entschlüsseln. Das muss ich mir wohl in einer ruhigen Stunde nochmal durch den Kopf gehen lassen, denn es kommt mir intuitiv irgendwie paradox vor.

Der Witz ist jetzt nun, dass jemand sich ja in die Kommunikation zwischen beiden Partnern einklinken könnte und nicht nur lauschen, sondern auch die Kommunikation verändert könnte. Was könnte so ein Angreifer bei DH machen? Ganz einfach: er könnte selbst mit beiden Partnern jeweils DH durchführen; d.h. (Alice und Bob wollen kommunizieren, Eve will das abfangen) Alice denkt, sie würde mit Bob einen Schlüssel austauschen, da die Kommunikation abgefangen wird, tauscht sie jedoch einen Schlüssel mit Eve aus. Genauso denkt Bob, er würde einen Schlüssel mit Alice austauschen, tauscht aber selbst wiederum einen mit Eve aus. D.h Eve hat dann zwei Schlüssel, einen für die Kommunikation mit Alice, einen für die Kommunikation mit Bob. Nun kann sie die Daten zwischen beiden Verbindungen nur noch hin- und herkopieren und kann dabei alles mitlauschen - sie kann sogar soweit gehen, dass sie die Daten sogar verändern kann.
Bildlich gesprochen:
[...]

Soweit kann ich folgen. Schön gezeichnet übrigens.  ;-)

Wie können nun Zertifikate helfen, Man-in-the-Middel zu vermeiden? Ganz einfach: Es werden nicht nur die DH-Informationen übertragen, die DH-Informationen werden zusätzlich noch mit dem eigenen privaten Schlüssel signiert.

Halt: Was heißt "signiert"? Eine Verschlüsselung kann es ja in dieser Phase des Handshakes noch nicht sein. Und gebe ich damit nicht gerade wieder den privaten Schlüssel preis, der die Geschichte bis hierher "sicher" gemacht hat?

Wenn der Client nun eine Nachricht vom Server erhält, die zum einen die notwendigen DH-Informationen des Servers, zum anderen jedoch auch eine digitale Signatur mit dem privaten Schlüssel des Servers, kann sie mit Hilfe des öffentlichen Schlüssels des Servers überprüfen, ob die digitale Signatur wirklich authentisch ist, d.h. wirklich vom Sever kommt.

Na gut - aber bei unserem "Woman-in-the-middle"-Szenario würde sich Eve doch Alice gegenüber als Bob ausgeben, also auch sein Zertifikat weiterreichen, ohne sich um dessen Inhalt kümmern zu müssen.

Eine zweite Möglichkeit wäre das von Dir angesprochene: Er könnte das Zertifikat vom Server durchreichen. Problem ist hierbei nur, dass der Angreifer dann dem Client ja seine eigenen DH-Parameter zukommen lassen müsste, um sich einklinken zu können. Nur kann der Angreifer die natürlich nicht mit dem privaten Schlüssel des Servers signieren, weil er diesen nicht besitzt.

Ja, aber das ist doch wurscht - der Client kennt ja den *privaten* Schlüssel des Servers auch nicht, also kann er doch gar nicht feststellen, ob der "echt" ist.

*in stiller Verwunderung*
 Martin