Man-in-the-Middle-Angriff im SSL-Szenario

Question

Ich versuche zu verstehen, welche Auswirkungen ein Man-in-the-Middle-Angriff auf meinen Webserver hätte.

Ich habe ein selbstsigniertes Zertifikat. Dieses Zertifikat kann durch einen Man-in-the-Middle-Angriff gefälscht werden, was bedeutet, dass alles, was ich vom Browser aus sende, abgefangen und geändert wird?

Wenn die Anfrage geändert wird, wird sie vom Webserver nicht entschlüsselt, da das Zertifikat auf dem Server ein anderes ist. Ist das richtig?

Die vom Browser gesendete Anfrage kann abgefangen und möglicherweise umgeleitet werden, die Daten auf meinem Server sind davon jedoch nicht betroffen. Ist das richtig?

Ich fange an, die Theorie hinter den Zertifikaten zu verstehen, aber es wäre großartig, wenn jemand ein Beispiel aus der Praxis für einen Man-in-the-Middle-Angriff liefern und zeigen könnte, welche Probleme er verursacht hat.

Danke

Answer 1

Wie ich bereits in meiner vorherigen Antwort aufIhre Frage, Man-In-The-Middle-Angriffe können (bei Erfolg) sämtliche Daten in ihren Besitz bringen, die über einen verschlüsselten Kanal hin und her gesendet werden.

Zertifikate, sowohl selbst signierte als auch von einer vertrauenswürdigen Root ausgestellte, können gefälscht werden. Lassen Sie sich also nicht in falscher Sicherheit wiegen, wenn Sie Ihren Benutzern ein Zertifikat von einer vertrauenswürdigen Root aus ausstellen. Das einzige Problem, das ich mit einem Zertifikat von einer vertrauenswürdigen Root überwinden muss, istIhren Benutzer dazu zu bringen, meine zu akzeptieren, wenn ich seinen Computer mit ARP vergiftet habe. Wenn Sie an die meisten Endbenutzer denken, wie einfach wäre dies?

Erkennen Sie jetzt die Probleme?

Sobald der Endbenutzer MEIN Zertifikat akzeptiert, gehört die Verbindung von diesem Zeitpunkt an mir und alle Daten laufen über meinen Computer.

Answer 2

Im Grunde genommen passiert Folgendes: Sie haben Ihr Zertifikat selbst signiert und können daher nicht beweisen, dass es gültig ist. Der Datenverkehr wird also problemlos verschlüsselt, aber Sie können nicht beweisen, dass es Ihr eigenes Zertifikat ist. Wenn ein Hacker zwischen Ihre Site und den Computer des Benutzers gelangen und den Datenverkehr abfangen kann, kann er den Datenverkehr entschlüsseln und lesen, was vor sich geht. (Er kann dies auch tun, indem er einen Domänennamen registriert, der Ihrem ähnlich ist, und auf einen Tippfehler wartet oder eine E-Mail versendet, die ihn auf seine Site und nicht auf Ihre weiterleitet.)

User ****** Hacker **** Your website

Der Grund dafür ist, dass er auch ein selbst signiertes Zertifikat vorlegen kann. Dann kommuniziert der Benutzer tatsächlich mit dem Hacker und nicht mit Ihnen. Der Benutzer kann den Unterschied nicht erkennen. Tatsächlich kann der Hacker, wenn er möchte, den Datenverkehr neu verschlüsseln und an Ihre Site zurücksenden und mithilfe der Benutzeranmeldeinformationen seinen eigenen Kommunikationsstream mit Ihrer Site starten. Oder er kann den Datenverkehr einfach im Klartext beobachten, während er hin und her fließt.

Answer 3

Es ist nicht so, dass er den Datenverkehr ändern kann. Der SSL-Handshake beginnt unverschlüsselt und der Server sendet ein SSL-Zertifikat, das der Client ab diesem Zeitpunkt verwenden kann. Wenn der Angreifer von Anfang an dabei ist, kann er dieses ursprüngliche Zertifikat durch sein eigenes ersetzen und dann das vom Server gesendete Zertifikat verwenden, um den Datenverkehr zum/vom Server zu verschlüsseln/entschlüsseln, wobei er sein eigenes Zertifikat verwendet, um es an Sie zu senden.
Wenn das Zertifikat von einer Zertifizierungsstelle signiert ist, ist es etwas schwieriger, es durch ein gefälschtes zu ersetzen, das ebenfalls von einer Zertifizierungsstelle signiert ist. Der Angreifer kann dieses Zertifikat jedoch problemlos durch ein selbst signiertes ersetzen, daher die Warnung.

Answer 4

Bei der Überprüfung eines Zertifikats sind zwei Punkte zu beachten:

• Überprüfen Sie, ob die Nachricht von einer vertrauenswürdigen Stelle stammt, und
• Überprüfen Sie, ob es mit der Identität des Servers übereinstimmt, den Sie kontaktieren möchten.

Von einer Zertifizierungsstelle ausgestellte Zertifikate

DerPublic Key Infrastructure mit X.509-Zertifikatsspezifikationdefiniert die dafür zu implementierende Struktur. Es handelt sich um ein hierarchisches Modell, bei dem Sie einen Baum erhalten, dessen Wurzel die Zertifizierungsstellen (CA) und dessen Blätter die Endentitätszertifikate (insbesondere Serverzertifikate) sind.

Die Stamm-CA-Zertifikate sind in der Regel selbstsigniert. Viele davon sind standardmäßig in Ihrem Betriebssystem oder Browser enthalten. Das ist der „Vertrauensvorschuss“, bei dem Sie darauf vertrauen, dass Ihr Betriebssystem-/Browser-Anbieter die CAs überprüft hat und sicherstellt, dass sie ihre Arbeit richtig machen. Einige der großen kommerziellen CAs sind Verisign, Thawte, …

Eine Zertifizierungsstelle kann dann andere Zertifikate signieren. Sie können ein Zertifikat, das Sie noch nie gesehen haben, überprüfen, indem Sie prüfen, ob es von einer Zertifizierungsstelle signiert wurde, der Sie vertrauen. Es kann auch Zwischenzertifizierungsstellen geben. Beispielsweise wurde das Zertifikat für https://www.google.com/signiert von "Thawte SGC CA", das wiederum von "VeriSign, Inc./Öffentliche primäre Zertifizierungsstelle der Klasse 3" (Ich kürze die Namen hier der Einfachheit halber ab). Die Aufgabe der CA besteht darin, (mit Mitteln außerhalb der PKI) zu überprüfen, ob die Person/Institution, an die sie das Zertifikat ausstellt, der rechtmäßige Eigentümer dieses Hostnamens ist (z. B. www.google.comhier). Die Art und Weise dieser Out-of-Band-Überprüfung variiert. Bei Nicht-EV-Zertifikaten erfolgt dies häufig einfach durch Senden einer E-Mail an die Adresse, unter der der Domänenname registriert ist (verfügbar imWer istVerzeichnis).

Wenn dies erledigt ist und Sie nicht wissen, ob Sie vertrauen können https://www.google.com/, überprüft der Client dieses Zertifikat anhand der vorhandenen Vertrauensanker (die CAs, die häufig von Betriebssystem-/Browseranbietern vorab importiert werden). Wenn Sie eine Verbindung zu herstellen www.google.com, erhält der Browser das Zertifikat und kann dann die Kette bis zum obersten Aussteller durcharbeiten (in jedem Zertifikat gibt es einen Ausstellereintrag), bis er einen findet, dem er vertraut (in diesem Fall das von Verisign). So weit, so gut, das Zertifikat ist vertrauenswürdig. Der zweite Schritt besteht darin, zu überprüfen, ob dieses Zertifikat tatsächlich für diesen Computer ist. Bei HTTPS wird dies dadurch erreicht, dass überprüft wird, ob der Hostname in der alternativen Namenserweiterung des Zertifikats enthalten ist oder als Fallback, ob er im Eintrag „Common Name“ (CN) im eindeutigen Namen des Antragstellers enthalten ist. Dies wird in erklärtRFC 2818 (Serveridentität).

Mögliche Angriffsversuche sind hierbei folgende:

• Die Angreifer fälschen ein Zertifikat (für diesen Hostnamen oder nicht) mit ihrer eigenen Zertifizierungsstelle. Da ihre Zertifizierungsstelle von Ihrem Browser nicht erkannt wird, wird das Zertifikat nicht überprüft. Selbst wenn sie den Namen des Ausstellers fälschen würden, könnten sie die Signatur nicht fälschen (da Sie mit dem öffentlichen Schlüssel die Zertifizierungsstellenzertifikate verwenden, denen Sie bereits vertrauen). Eines der größten Probleme war hier die Stärke der Signatur: Kollisionsangriffe wurden mit dem MD5-Digest-Algorithmus nachgewiesen, daher verwenden Zertifizierungsstellen jetzt stattdessen SHA-1, das als robuster gilt. Wenn Sie RSAwithSHA1 oder DSAwithSHA1 für ausreichend robust halten, sollten Sie hier kein Problem haben.
• Die Angreifer erhalten ein gültiges Zertifikat von einer bekannten Zertifizierungsstelle, aber für einen anderen Hostnamen (was eine Zertifizierungsstelle nicht an jemand anderen aussenden sollte). Nehmen wir an, sie erhalten www.example.com. Sie versuchen, eine Verbindung zu herzustellen www.google.com, sie leiten den Datenverkehr auf ihre Box um, die ein Zertifikat anzeigt, das von einer vertrauenswürdigen Zertifizierungsstelle verifizierbar ist, aber für www.example.com. Hier ist die Überprüfung des Hostnamens wichtig. Ihr Browser warnt Sie, dass Sie nicht mit dem gewünschten Host verbunden sind.

Dieses System soll sicherstellen, dass der Client die Verbindung nicht akzeptiert, wenn ein MITM den Datenverkehr auf seine Maschine umleitet. Dies gilt natürlich nur, wenn der Benutzer die vom Browser angezeigten Warnungen nicht ignoriert.

Selbstsignierte Zertifikate

Das Prinzip ist dasselbe, nur dass Sie die Zertifizierungsstelle sind und dieses selbstsignierte Zertifikat auch direkt das Serverzertifikat sein kann. Wenn Sie Ihr eigenes selbstsigniertes Zertifikat erstellen und auf Ihrem Computer ablegen, können Sie es auch als vertrauenswürdige Zertifizierungsstelle in Ihren Browser importieren. In diesem Fall folgen Sie demselben Verfahren wie oben beschrieben.

Einige Browser, wie beispielsweise Firefox, erlauben es Ihnen, dauerhafte Ausnahmen zu diesen Regeln hinzuzufügen. Wenn Sie auf andere Weise wissen (z. B. der Administrator hat Ihnen das Zertifikat persönlich gegeben), welches Zertifikat für den Computer gilt, mit dem Sie eine Verbindung herstellen möchten, können Sie ihm ausdrücklich vertrauen, auch wenn es nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde oder wenn der Name nicht übereinstimmt. Dazu müssen Sie natürlich a priori und ausdrücklich wissen, welches Zertifikat dieses bestimmte Zertifikat sein soll.

Wenn der Benutzer in beiden Fällen die Warnungen ignoriert und die Umleitung zu einer Verbindung mit einem nicht vertrauenswürdigen Zertifikat akzeptiert, kann der MITM (mit diesem nicht vertrauenswürdigen Zertifikat) den Datenverkehr sehen/umleiten/ändern.