Get oder Post

[Christian Seiler]

Hallo Martin,

1. Man-in-the-middle-Attacken [...] Für diesen Fall gibt es wie erwähnt Zertifikate, damit sich zumindest der Server authentifizieren kann

aber was hilft das, wenn der "böse lauschende Router" dazwischenhängt und auch das Zertifikat einfach durchreicht? Mir ist das nämlich immer noch nicht wirklich klar. Wenn ein Lauscher, z.B. ein manipulierter Router, tatsächlich alles von Anfang an mitschneidet, hat er die gleiche Information wie Server und Client und kann damit auch die gesamte abgehörte Kommunikation entschlüsseln. Schließlich bekommt er den Verbindungsaufbau und alle Daten, die dabei ausgetauscht werden, aus erster Hand mit. Oder worin besteht nun die Sicherheit?

Ok, dann erst einmal zur Klarstellung: Ein Zertifikat ist stark vereinfacht gesagt ein öffentlicher Schlüssel, der von einer Zertifizierungsstelle digital unterschrieben wurde. Das heißt also, dass die Zertifizierungsstelle den öffentlichen Schlüssel beglaubigt hat, d.h. wenn man ein Zertifikat erhält, das von einer Zertifizierungsstelle, der man vertraut, unterzeichnet wurde, dann kann man sicher [1] sein, dass der öffentliche Schlüssel wirklich zum Gegenüber gehört. Das heißt, wenn ich mich mit einem TLS-Server verbinde und erhalte dann ein Zertifikat, dann sagt mir das zwei Dinge:

1. Der öffentliche Schlüssel des Servers ist der, der im Zertifikat
      unterzeichnet wurde.
2. Die Zertifizierungsstelle XYZ, der ich vertraue, hat das Zertifikat
      unterzeichnet.

Was hat das für Konsequenzen? Zum öffentlichen Schlüssel gehört ein privater Schlüssel. Wenn jetzt jemand etwas mit diesem privaten Schlüssel signiert und mir schickt, dann kann ich die Signatur dieser Nachricht mit dem öffentlichen Schlüssel des Zertifikats verifizieren. Ich kann also sicher sein, dass die Nachricht mit dem zum öffentlichen Schlüssel zugehörigen privaten Schlüssel signiert wurde. Da ich haber weiß, dass der öffentliche Schlüssel authentisch ist, weiß ich auch, dass die Nachricht authentisch ist.

Jetzt betrachte Dir zum Beispiel noch einmal den Diffie-Hellman-Schlüsseltauschalgorithmus. Was passiert denn dort genau (ohne die ganze Zertifizierungsgeschichte)?

Beide Seiten schicken sich gegenseitig ein paar Informationshäppchen, aus denen sie dann einen gemeinsamen Schlüssel berechnen können. Du fragst nun: Was, wenn jemand mitliest? Die einfache Antwort: der hat Pech gehabt. Wenn jemand *ausschließlich* mitliest, hat er keine Möglichkeit, herauszufinden, welchen Schlüssel sich beide ausgetauscht haben, das ist eben gerade der Witz an Diffie-Hellman. Wenn Dich die zugehörige Mathematik näher interessiert: Im verlinkten Wikipedia-Eintrag wird's erklärt.

Gut, Lauschen alleine ist bei DH schonmal aus Prinzip ausgeschlossen, dann bleibt die Frage, wozu dann die ganzen Zertifikate noch gut sein sollen?

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:

Normalfall:

+-------+ (1) DH: Austausch von Schlüssel K                  +-----+
| Alice |<-------------------------------------------------->| Bob |
|       | (2) Kommunikation abgesichert durch Schlüssel K    |     |
|       |<-------------------------------------------------->|     |
+-------+                                                    +-----+

Man-in-the-Middle:

+-------+ (1) DH: Austausch von Schlüssel K1                 +-----+
| Alice |<-------------------------------------------------->| Eve |
|       | (3) Kommunikation "abgesichert" durch Schlüssel K1 |     |
|       |<-------------------------------------------------->|     |
+-------+                                                    +-----+
                                                              ^   ^
                                                              |   |
+-------+ (2) DH: Austausch von Schlüssel K2                  /   |
| Bob   |<----------------------------------------------------    |
|       | (4) Kommunikation "abgesichert durch Schlüssel K2       /
|       |<--------------------------------------------------------
+-------+

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. 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. D.h. der Server würde dem Client zwei Häppchen übermitteln: 1) Sein Zertifikat, damit der Client das überprüfen kann, 2) Seine DH-Parameter, die er mit seinem privaten Schlüssel signiert hat. Was könnte ein Angreifer tun? Er könnte zum einen ein anderes Zertifikat schicken, das zu *seinem* privaten Schlüssel passt und dann mit seinem privaten Schlüssel die DH-Parameter signieren. Woran scheitert dies? Eine Zertifizierungsstelle sollte im Idealfall einem Angreifer natürlich kein Zertifikat ausstellen, auch wenn das in der Vergangenheit leider bereits vorgekommen ist. Damit kann sich der Angreifer höchstens selbst ein Zertifikat ausstellen, aber der Zertifizierungsstelle "Angreifer" traut der Client selbstverständlich nicht, damit kann der Angriff bemerkt werden. 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. Damit kann der Server keine Nachricht erzeugen, die DH-Parameter enthalten würde, die der Client akzeptieren würde. Damit scheitert auch diese Art von Angriff.

TLS funktioniert übrigens nicht nur mit Diffie-Hellman, es gibt auch die Möglichkeit, RSA zu verwenden. Das Verfahren ist nur etwas aufwändiger zu erklären, da ich dann tiefer in Details von TLS einsteigen müsste, die ich beim vergleichsweise einfachen Konzept "signierte DH-Parameter" einfach weglassen kann. TLS versucht nämlich eine ganze Menge teilweise richtig raffinierter Attacken auf das Handshake-Verfahren vorzubeugen und geichzeitig flexibel genug zu sein, dass man TLS später durch weitere (bessere) Verfahren erweitern kann.

Viele Grüße,
Christian

[1] Natürlich gibt's nie absolute Sicherheit, aber bei hinreichend großen Schlüssellängen gibt es aktuell keine bekannte Möglichkeit, gute digitale Unterschriftsverfahren auszuhebeln.