Frage:
Ist das Spoofing eines CA-signierten Zertifikats möglich?
sudhacker
2012-09-11 23:51:20 UTC
view on stackexchange narkive permalink

Ich hatte noch nie über diese Situation nachgedacht, ich kann mich völlig irren, aber ich muss es trotzdem klären. Wenn eine Kommunikation mit einem Server beginnt, erhält der Client während des Client-Handshakes eine Kopie des öffentlichen Schlüssels (CA signiert). Jetzt hat der Client vollständigen Zugriff auf diesen öffentlichen Schlüssel, der von der Zertifizierungsstelle signiert ist.

Warum kann man einen Angreifer nicht kippen, seinen eigenen Server einrichten und diesen öffentlichen Schlüssel verwenden, der ein Opfer im Wesentlichen glauben lässt, dass er der eigentliche Server ist? Der Angreifer verfügt natürlich nicht über den privaten Schlüssel, um die Kommunikation zu entschlüsseln, aber das verhindert nicht, dass der Handshake stattfindet. Da das Zertifikat signiert ist und dieses Zertifikat den Browser des Opfers erreicht, heißt es, dass das Zertifikat tatsächlich in Ordnung ist.

Was fehlt mir hier?

Acht antworten:
#1
+29
gowenfawr
2012-09-12 00:00:54 UTC
view on stackexchange narkive permalink

Der Handshake enthält die folgenden (groben) Schritte:

  1. Der Server sendet seinen öffentlichen Schlüssel.
  2. Der Client verschlüsselt die Setup-Informationen mit diesem öffentlichen Schlüssel und sendet ihn zurück an den Server.
  3. Der Server entschlüsselt die Übermittlung des Clients und leitet daraus ein gemeinsames Geheimnis ab.
  4. Weitere Schritte verwenden dieses gemeinsame Geheimnis, um die tatsächlich zu verwendende Verschlüsselung einzurichten.
  5. ol>

    Die Antwort auf Ihre Frage lautet also, da ein Betrüger keinen Schritt ausführen kann 3 (da es keinen privaten Schlüssel hat) kann es niemals mit Schritt 4 fortfahren. Es hat kein gemeinsames Geheimnis, daher kann es den Handshake nicht abschließen.

Perfekte Antwort - Es gibt Fälle, in denen Spoofing der CA möglich ist, aber es ist viel schwieriger, als nur eine Kopie des CA-Zertifikats wiederzuverwenden - zum Beispiel das Spoofing von Microsoft-Zertifikaten während der Flame-Angriffe - http: // news .cnet.com / 8301-10805_3-57446466-75 / Flammenvirus-Verbreitung-durch-Schurken-Microsoft-Sicherheitszertifikate / - aber dies ist der Fall einer ziemlich klugen Verwendung von Schwachstellen in einem Krypto-Algorithmus, die dazu führen, dass das MS-Zertifikat imitieren. Im obigen Beispiel war es tatsächlich ein Terminalserver, keine Zertifizierungsstelle, aber der Angriff würde auf jede Art von Zertifikat funktionieren.
@bethlakshmi, Diese Antwort ist eine gute Vereinfachung des RSA-Schlüsselaustauschs, aber auch (EC) DHE-Verschlüsselungssuiten werden zunehmend verwendet: Der Client verschlüsselt dort nicht mit dem öffentlichen Schlüssel des Servers.
Kann nicht jemand den öffentlichen Schlüssel und die Zertifikatsignatur (da beide verfügbar sind) von step erhalten und sie an den Kunden senden, der vorgibt, die ursprüngliche Website zu sein?
@MarounMaroun können sie das tun, aber der Client verwendet den öffentlichen Schlüssel, um etwas zu verschlüsseln, das an den Server zurückgesendet werden soll.Da der Pretender nicht über den privaten Schlüssel verfügt, kann er diesen nicht entschlüsseln, und die Konversation wird unterbrochen.
@gowenfawr Danke.Theoretisch kann also jemand so tun, als wäre er die ursprüngliche Site, und der Browser hat keine Ahnung davon?Ich meine, in diesem Fall wird das grüne Vorhängeschloss immer noch angezeigt, richtig?
@MarounMaroun nein, du verstehst mich falsch.Sie können so tun, als ob sie es tun, aber die Verbindung schlägt fehl, da Sie mehr als den öffentlichen Schlüssel benötigen, damit sie funktioniert.Jemand kann * versuchen * vorzutäuschen, aber er kann nicht * erfolgreich * sein
@gowenfawr OK, ich werde versuchen, mehr zu erklären, was mir fehlt.Wenn jemand in der Mitte steht, kann er tatsächlich ** alle ** Daten sehen, die vom Server an den Client gesendet wurden.Im Grunde genommen kann er sich alles schnappen und es senden (ich weiß, dass er nichts damit anfangen kann, weil er den geheimen Schlüssel nicht hat).Aber stimmt es bis zu diesem Punkt, dass jemand alle Zertifikatdaten abrufen kann, während er an den Client übertragen wird, und ihn "austricksen" kann?Danke noch einmal!
@MarounMaroun "* ist es wahr, dass jemand alle Zertifikatdaten abrufen kann, während er an den Client übertragen wird *? Ja, wahr." * Und ihn "austricksen"? * "Nein, falsch.
Das ist wirklich einfach, danke!So viele Quellen, die ich gelesen habe, sagen "MitM-Angriffe können durch Untersuchen der Zertifikate verhindert werden", haben aber nie erklärt, was den Angreifer daran hindert, die Zertifikate zu kopieren.
Ich denke in den gleichen Zeilen wie @MarounMaroun.Die von Ihnen beschriebenen Schritte werden während eines Handshakes zwischen Client und Server ausgeführt.Ich verstehe, dass der Betrüger den Datenverkehr nicht entschlüsseln kann, da er nicht über den privaten Schlüssel des Servers verfügt.Findet die Zertifikatsüberprüfung vor diesem Handshake statt?Oder beinhaltet die Zertifikatsüberprüfung den privaten Schlüssel des Servers?Könnten Sie die Zertifikatsüberprüfung in Ihre Schritte einbeziehen?
@ProgramCpp Der "öffentliche Schlüssel", den ich erwähne, ist in der Tat das Zertifikat - ein Zertifikat ist ein signierter öffentlicher Schlüssel.Die Zertifikatsüberprüfung erfolgt also im Rahmen dieses Handshakes.Nachdem der Server dem Client das Zertifikat (das den öffentlichen Schlüssel enthält) übergeben hat, überprüft der Client das Zertifikat.Wenn dies nicht überprüft wird, fährt der Client nicht mit Schritt 2 fort.
Umfasst die Zertifikatsüberprüfung einen privaten Schlüssel?Ich denke, ohne dass ein privater Schlüssel in die Überprüfung einbezogen wird, kann das Zertifikat gefälscht werden.Trick, das Zertifikat ist original.Ich vermisse hier etwas.
@ProgramCpp, Sie vermissen, wie Krypto mit öffentlichem Schlüssel ("asymmetrisch") funktioniert.Das Zertifikat ist eine signierte Kopie des öffentlichen Schlüssels des Servers."Signiert" bedeutet, dass ein vertrauenswürdiger Dritter (CA) seinen privaten Schlüssel verwendet hat, um den öffentlichen Schlüssel des Servers zu stempeln und zu bestätigen, dass er dem gehört, von dem er sagt, dass er es ist.Dieser Stempel, der mit dem privaten Schlüssel der Zertifizierungsstelle erstellt wurde, kann nur mit dem passenden öffentlichen Schlüssel der Zertifizierungsstelle überprüft werden. Dies ist der asymmetrische Teil der Gleichung. Ein Schlüssel muss "erledigt" werden, aber nur der andere Schlüssel kann "rückgängig machen" und umgekehrt.Keine Notwendigkeit und in der Tat keine Verwendung für den privaten Schlüssel eines anderen im Überprüfungsprozess.
Mein Zweifel ist, dass der Hacker den Stempel besitzt, der jedem zugänglich ist, der die Site besucht.Wenn ich den Server besuche, erhalte ich das Zertifikat mit einem Stempel, der mit dem privaten Schlüssel der Zertifizierungsstelle erstellt wurde.Ich werde jetzt das gleiche Zertifikat verwenden, um einen Benutzer auszutricksen.Dieses Zertifikat wird mit dem öffentlichen Schlüssel der Zertifizierungsstelle überprüft.
@ProgramCpp ABER Sie können den Datenverkehr des Benutzers niemals mit diesem öffentlichen Schlüssel ("Zertifikat") entschlüsseln.Sie benötigen den privaten Schlüssel, um alles zu entschlüsseln, was mit dem öffentlichen Schlüssel verschlüsselt ist ("ein Schlüssel muss erledigt werden, aber nur der andere Schlüssel kann rückgängig machen").Ja, Sie stehlen das Zertifikat und geben es dem Benutzer.Ja, sie überprüfen es, es ist gut.Ja, sie verschlüsseln ihren nächsten Verkehr damit.Und NEIN, mit diesem verschlüsselten Datenverkehr können Sie nichts anfangen, da Sie nicht über den privaten Schlüssel verfügen.
Also, ja, sie überprüfen, ob es gut ist.Dies bedeutet, dass die Zertifikatsüberprüfung bestanden wurde.Mein Anliegen war nur die Überprüfung des Zertifikats, nicht die Entschlüsselung des Datenverkehrs, der ohne den geheimen privaten Schlüssel sicher ist.Warum dann die Zertifikatsüberprüfung durchführen?Sie präsentieren nur den öffentlichen Schlüssel.Der Client verschlüsselt mit einem öffentlichen Schlüssel und nur der Server entschlüsselt den Datenverkehr.Was ist dann für die Zertifikatsüberprüfung erforderlich?Danke, dass du meine Fragen geduldig beantwortet hast :)
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (http://chat.stackexchange.com/rooms/65222/discussion-between-gowenfawr-and-programcpp).
#2
+9
Jim In Texas
2012-09-12 01:50:35 UTC
view on stackexchange narkive permalink

Asudhak, fühle dich nicht schlecht, wenn das etwas verwirrend ist. Die Erfindung der asymmetrischen Kryptographie war ein großer Fortschritt in der Mathematik. Es scheint sehr kontraintuitiv, wenn nicht gar unmöglich, wenn man es zum ersten Mal trifft.

Wenn ein Client (häufig ein Webbrowser) und ein Server (häufig ein Webbrowser) einen sicheren Kommunikationskanal einrichten möchten, werden sie Führen Sie einen sogenannten Schlüsselaustausch durch.

Der öffentliche Schlüssel , den der Server dem Client-Programm zur Verfügung stellt, enthält nichts Geheimnisvolles. Die einzige Funktion besteht darin, Informationen zu verschlüsseln.

Der Client generiert ein einmaliges geheimes Passwort, das nur der Webbrowser kennt. Der Client verwendet dann den öffentlichen Schlüssel des Servers, um das einmalige geheime Kennwort zu verschlüsseln. Der öffentliche Schlüssel kann nur verschlüsseln, der öffentliche Schlüssel kann nicht entschlüsseln !

Der Client kann dieses verschlüsselte geheime Kennwort sicher an den Server übertragen. Jeder Mann in der Mitte, der diesen Schlüsselaustausch abfangen könnte, erhält keine nützlichen Informationen, da er dieses vom Client generierte und mit dem öffentlichen Schlüssel des Servers verschlüsselte einmalige Nutzungsgeheimnis mit ziemlicher Sicherheit nicht entschlüsseln kann.

Der Server und nur der Server haben den entsprechenden privaten Schlüssel. Der private Schlüssel des Servers kann nur zum Entschlüsseln verwendet werden. Der private Schlüssel des Servers wird niemals an jemanden übertragen!

Der Server verwendet den privaten Schlüssel, um das vom Client (Webbrowser) generierte einmalige geheime Kennwort zu entschlüsseln.

Der Client und der Server kennen jetzt beide ein Geheimnis, das niemand sonst kennt !

Mit diesem Geheimnis können sie ihre nachfolgenden Konversationen mit jedem herkömmlichen symmetrischen Verschlüsselungsalgorithmus mit einem hohen Maß an Sicherheit für die Sicherheit des Kanals verschlüsseln.

Darüber hinaus verfügt der Client über einen Speicher mit ' Zertifikaten', die die öffentlichen Schlüssel von Organisationen enthalten, denen er vertraut. Der eigentliche TLS-Schlüsselaustausch schlägt fehl, wenn der Server kein digitales Dokument mit der Bezeichnung Zertifikat vorlegt, das einen mit dem privaten Schlüssel der vertrauenswürdigen Organisation verschlüsselten Hashwert enthält. Der Client kann diesen Hash und den vertrauenswürdigen öffentlichen Schlüssel verwenden, um zu wissen, dass dieser Server als vertrauenswürdig eingestuft wird.

Technisch gesehen kann der öffentliche Schlüssel "entschlüsseln", was mit dem privaten Schlüssel verschlüsselt ist, aber diese Funktion wird im Allgemeinen nur zum Signieren verwendet. (dh eine Möglichkeit für den Server, zu überprüfen, ob er den privaten Schlüssel enthält) Dies ist wichtig, da CAs so funktionieren. Sie signieren den öffentlichen Schlüssel des Servers mit ihrem privaten Schlüssel, sodass der Client den öffentlichen Schlüssel verwenden kann, den er für die Zertifizierungsstelle gespeichert hat, um zu überprüfen, ob der öffentliche Schlüssel tatsächlich von der Zertifizierungsstelle stammt. (Und damit hat die Zertifizierungsstelle hoffentlich überprüft, ob der Server der ist, für den sie sich ausgeben).
#3
+4
dr jimbob
2012-09-11 23:58:16 UTC
view on stackexchange narkive permalink

Sie können den TLS-Handshake nicht beenden, da der Client das öffentliche Zertifikat des Servers verwendet und es zum Verschlüsseln eines PreMasterSecret verwendet, mit dem das Master Secret generiert wird.

Der Client antwortet mit einer ClientKeyExchange-Nachricht, die möglicherweise ein PreMasterSecret, einen öffentlichen Schlüssel oder nichts enthält. (Dies hängt wiederum von der ausgewählten Verschlüsselung ab.) Dieses PreMasterSecret wird mit dem öffentlichen Schlüssel des Serverzertifikats verschlüsselt.

Der Client und der Server verwenden dann die Zufallszahlen und PreMasterSecret, um ein gemeinsames Geheimnis namens the zu berechnen "Meistergeheimnis". Alle anderen Schlüsseldaten für diese Verbindung werden aus diesem Hauptgeheimnis (und den vom Client und Server generierten Zufallswerten) abgeleitet, das über eine sorgfältig entworfene Pseudozufallsfunktion übergeben wird.

Denken Sie daran, in Asymmetrische Kryptographie Der öffentliche Schlüssel ist keineswegs ein Geheimnis und im Allgemeinen (unter der Annahme, dass keine anderen Fehler vorliegen) für einen Angreifer nicht von Nutzen.

Ja, aber das öffentliche Zertifikat hat der Angreifer. Was bedeutet, dass das TLS noch richtig abgeschlossen werden kann?
@asudhak - Das öffentliche Zertifikat ist nutzlos. Der private Schlüssel wird benötigt, um den Datenverkehr vom Client zu entschlüsseln und den Handshake abzuschließen. Wenn der Angreifer den Datenverkehr nicht entschlüsseln kann, weil er den öffentlichen Schlüssel eines anderen Benutzers verwendet, schlägt der TLS-Handshake fehl und der Browser gibt eine Warnung aus.
@drjimbob Ich bin gespannt, wie es in einem Browser aussieht, wenn der TLS-Handshake fehlschlägt.
#4
+3
Bruno
2012-09-12 21:42:05 UTC
view on stackexchange narkive permalink

In den vorhandenen Antworten geht es um die Verschlüsselung mit dem öffentlichen Schlüssel des Zertifikats, der nicht immer tatsächlich verwendet wird (insbesondere bei DSA- oder DHE-Verschlüsselungssuiten). (Hier finden Sie beispielsweise eine Antwort mit weiteren Details hier.)

Der unmittelbare Zweck des SSL / TLS-Handshakes besteht darin, ein Pre-Master-Geheimnis für die gemeinsame Nutzung zwischen dem Client und dem Client einzurichten Server. Dieses Pre-Master-Geheimnis wird dann in ein Master-Geheimnis und dann in Verschlüsselungsschlüssel (und MAC) abgeleitet. Dieses Verfahren wird allgemein als Schlüsselaustausch bezeichnet (siehe RFC 4346 Anhang F.1.1).

Um sicherzustellen, dass Sie mit der richtigen Partei kommunizieren, müssen Sie eine Verschlüsselungssuite verwenden, die den Austausch authentifizierter Schlüssel unterstützt. (Anonyme Cipher Suites sind in sinnvollen Konfigurationen standardmäßig deaktiviert.)

Dieser authentifizierte Schlüsselaustausch fällt in zwei Kategorien:

  • RSA-Schlüsselaustausch (z. B. ) TLS_RSA_WITH_AES_128_CBC_SHA ): Der Client verschlüsselt das Pre-Master-Geheimnis mit dem öffentlichen Schlüssel des Servers (im Zertifikat enthalten). Nur der legitime Server kann dies mit seinem privaten Schlüssel entschlüsseln.

  • DHE-Schlüsselaustausch (z. B. TLS_DHE_RSA_WITH_AES_256_CBC_SHA oder Verschlüsselungssuiten mit einem DSS-Zertifikat): a Diffie -Hellman-Schlüsselaustausch findet statt. Es ist normalerweise Ephemeral DH, die Variante mit festen Parametern (DH, nicht DHE) ist sehr selten. (Ein RSA-basiertes Zertifikat impliziert keinen RSA-Schlüsselaustausch.) Der Server signiert seine DH-Parameter und der Client überprüft die Signatur anhand des öffentlichen Schlüssels im Serverzertifikat. Da nur der legitime Server mit seinem privaten Schlüssel signieren konnte, wird der Austausch authentifiziert.

Eine Methode verwendet Verschlüsselung, die andere digitale Signatur, beide unter Verwendung des öffentlichen Schlüssels im Zertifikat. Beide haben das gleiche Endergebnis: ein Pre-Master-Geheimnis, das der Client ausschließlich mit dem Server teilen kann, der den privaten Schlüssel für sein Zertifikat hat.

(Der andere Punkt ist natürlich, dass der Client überprüfen muss, ob er dem Zertifikat vertraut, dass es gültig ist und an den Server ausgestellt wurde, mit dem er kommunizieren möchte, aber dies sind leicht getrennte Punkte.)

Wie wird beim DHE-Schlüsselaustausch das Pre-Master-Geheimnis ausgetauscht?
#5
+1
user87763
2015-09-27 09:37:23 UTC
view on stackexchange narkive permalink

Dies setzt voraus, dass Sie die Grundlagen der Authentifizierung mit öffentlichem Schlüssel kennen und wissen, wie ein Webbrowser über einen Domainnamen mit einem Webserver kommuniziert. Die Interaktion erfolgt zwischen dem Webbrowser des Benutzers und dem Webserver des Unternehmens.

Öffentliche Schlüssel und private Schlüssel

Der Webserver verfügt über einen öffentlichen und einen privaten Schlüssel. Der private Schlüssel kann eine mit dem öffentlichen Schlüssel verschlüsselte Nachricht entschlüsseln. Der öffentliche Schlüssel kann a entschlüsseln Nachricht mit dem privaten Schlüssel verschlüsselt. Die Zertifizierungsstelle verfügt über einen eigenen öffentlichen und einen privaten Schlüssel.

Der Webserver sendet seine Unternehmensinformationen, den öffentlichen Schlüssel und den Domänennamen (der dem SSL-Zertifikat zugeordnet werden soll) an die Zertifizierungsstelle. Das Zertifikat Die Behörde sendet eine Bestätigungsnachricht an die mit dem Domänennamen verknüpfte E-Mail-Adresse, um zu beweisen, dass diese Anforderung vom echten Eigentümer des Domänennamens gestellt wurde. Zu diesem Zeitpunkt wartet die Zertifizierungsstelle, bis der Eigentümer des Domänennamens die Anforderung bestätigt per E-Mail.

Zertifikatsignierung

Die Zertifizierungsstelle verschlüsselt den Domänennamen, die Unternehmensinformationen und den öffentlichen Schlüssel des Webservers mit ihrem eigenen privaten Schlüssel. Das Zertifikat Die Berechtigung sendet das verschlüsselte Ergebnis an den Webserver. Dieses Ergebnis ist das SSL-Zertifikat, eine Textnachricht mit dem Domänennamen, den Unternehmensinformationen und dem öffentlichen Schlüssel des Webservers, die alle mit dem privaten Schlüssel der Zertifizierungsstelle verschlüsselt wurden Webserver sendet thi s Zertifikat an den Browser des Benutzers.

Vertrauenswürdige Zertifizierungsstellen

Im Webbrowser ist eine Liste vertrauenswürdiger Zertifizierungsstellen und ihrer öffentlichen Schlüssel vorinstalliert. Der Webbrowser entschlüsselt das Zertifikat mit dem öffentlichen Schlüssel der entsprechenden Zertifizierungsstelle. Zu diesem Zeitpunkt weiß der Webbrowser, dass das Zertifikat und sein Inhalt vertrauenswürdig sind, da nur eine mit dem privaten Schlüssel der Zertifizierungsstelle verschlüsselte Nachricht mit dem öffentlichen Schlüssel dieser Zertifizierungsstelle kohärent entschlüsselt werden konnte.

Der Webbrowser jetzt kennt die vertrauenswürdigen Unternehmensinformationen, den öffentlichen Schlüssel und den Domänennamen, die dem Webserver zugeordnet werden sollen, was immer noch verdächtig ist. Der Webbrowser bestätigt, dass der Domänenname auf dem Zertifikat mit dem tatsächlichen Domänennamen des Webservers übereinstimmt.

Wenn zu diesem Zeitpunkt die Domänennamen übereinstimmen, stellt der Webbrowser fest, dass der Webserver vertrauenswürdig genug ist, um verschlüsselte Daten an zu senden. Außerdem stellt der Webbrowser zu diesem Zeitpunkt fest, dass er den vertrauenswürdigen öffentlichen Schlüssel verwenden kann des Zertifikats zum Verschlüsseln seiner Nachrichten, da nur der private Schlüssel des echten Webservers diese Nachricht entschlüsseln kann.

Beachten Sie, dass, wenn ein nicht vertrauenswürdiger öffentlicher Schlüssel verwendet wurde (ohne die Überprüfung der Zertifizierungsstelle zu durchlaufen), der Der Webbrowser hat möglicherweise vertrauliche Informationen verschlüsselt und gesendet, um sie nur mit dem privaten Schlüssel eines böswilligen Servers zu entschlüsseln. Mit anderen Worten, es ist unbedingt erforderlich, dass dem öffentlichen Schlüssel vertraut wird, da das Verschlüsseln einer Nachricht damit die einzige Abhörmaßnahme für die vom Webbrowser gesendeten Informationen darstellt.

Im weiteren Verlauf verschlüsselt der Webbrowser Die Nachricht verwendet den vertrauenswürdigen öffentlichen Schlüssel und sendet die verschlüsselte Nachricht an den Webserver. Der Webserver entschlüsselt die Nachricht mit dem echten privaten Schlüssel (falls vorhanden) und liest die entschlüsselte Nachricht erfolgreich.

Shared Secret Key

Wenn der Webserver auf den Webbrowser antwortet, muss diese Nachricht ebenfalls sicher gesendet werden. Der Webbrowser kann kopieren, was der Webserver gerade getan hat (ohne den Prozess der Zertifizierungsstelle), indem er einen öffentlichen Schlüssel und einen privaten Schlüssel für sich selbst generiert und dann seinen öffentlichen Schlüssel an den Webserver sendet. Dies würde eine sichere Verbindung herstellen, die als asymmetrische 2-Wege-Verschlüsselung bezeichnet wird. Eine solche Kommunikation ist jedoch (relativ gesehen) rechenintensiv.

Der Standardansatz besteht also darin, einen gemeinsamen geheimen Schlüssel zu verwenden, der eine Nachricht verschlüsseln und auch entschlüsseln kann. Der Webbrowser generiert einen geheimen Schlüssel, verschlüsselt ihn mit dem vertrauenswürdigen öffentlichen Schlüssel und sendet ihn dann an den Webserver. Wenn der Webserver echt ist, kann er den geheimen Schlüssel erfolgreich entschlüsseln.

At Zu diesem Zeitpunkt verfügen sowohl der Webbrowser als auch der Webserver über einen gemeinsamen geheimen Schlüssel, mit dem sie künftig weitere Kommunikationen verschlüsseln und entschlüsseln können.

Weitere Informationen:

  • Überprüfen der Integrität der Nachricht mit Hash-Funktionen zum Erkennen von Nachrichtenänderungen

  • Vertrauenskette zwischen Zertifizierungsstellen

#6
  0
Lucas Kauffman
2012-09-11 23:55:42 UTC
view on stackexchange narkive permalink

Dass das CA-Zertifikat (öffentlicher Schlüssel) für verifizierte Zertifikate bereits im Browser enthalten ist und dass Ihr Szenario eine SSL-Warnung generieren würde.

Wenn Sie über etwas in der Art von SSH sprechen, sind Sie muss weiterhin den öffentlichen Schlüssel akzeptieren. Wenn Sie nicht überprüfen, ob dieser Schlüssel über einen anderen sicheren Kanal korrekt ist, ist es Ihre eigene Schuld, wenn Sie MITM erhalten.

Wie wird der Browser behaupten, dass das Zertifikat ungültig ist, da ich das Zertifikat einfach vom eigentlichen Server selbst nehme und es dem Browser des Opfers präsentiere? Was ändert sich ?
Das Zertifikat ist im Browser fest codiert. Es wird nie von einem Server abgerufen, daher können Sie es nicht fälschen.
Ich glaube, mit openSSL können Sie tatsächlich Serverzertifikate abrufen: http://fdmanana.wordpress.com/2008/07/01/getting-a-servers-certificate-with-openssl/
Ja, und das erzeugt eine SSL-Warnung.
@LucasKauffman, asudhak spricht über das signierte Public-Key-Zertifikat des Servers, das er tatsächlich von einem Client erhalten könnte. Ich denke, Sie beziehen sich auf das Signaturzertifikat der Zertifizierungsstellen, das im Schlüsselspeicher des Browsers gespeichert ist und mit dem überprüft wird, ob das vom Server gesendete Zertifikat von einer legitimen Zertifizierungsstelle validiert wurde.
Aber das würde immer noch das Gleiche erzeugen, nein? Sie hätten einen öffentlichen Schlüssel von einer Zertifizierungsstelle signiert? Wenn er über SSH spricht, ist dies zwar möglich, Sie müssen jedoch den öffentlichen Schlüssel akzeptieren.
#7
  0
MaxxVadge
2015-02-25 14:22:03 UTC
view on stackexchange narkive permalink

Die Antwort darauf, warum Sie den signierten öffentlichen Schlüssel nicht einfach nehmen und zum Abfangen des Datenverkehrs bei einem Man-in-the-Middle-Angriff verwenden können, lautet, dass Sie (oder der Angreifer) nicht über den entsprechenden privaten Schlüssel verfügen den öffentlichen Schlüssel.

Der Browser empfängt also die Webserver oder den von der Zertifizierungsstelle signierten öffentlichen Schlüssel und verschlüsselt damit sein eigenes Geheimnis, um es an den Webserver zurückzusenden.

Der Webserver verfügt über den entsprechenden privaten Schlüssel, der zum Entschlüsseln der vom Browser zurückgesendeten Daten benötigt wird, die mit dem öffentlichen Schlüssel verschlüsselt wurden. Der Angreifer tut dies nicht, sodass er den Datenverkehr nicht entschlüsseln kann.

#8
  0
sudhacker
2015-03-11 05:05:08 UTC
view on stackexchange narkive permalink

Wie sich herausstellt, habe ich diese Frage 2012 gestellt, aber jetzt im Jahr 2015 gibt es tatsächlich einen Angriff, der dies ermöglicht. Abhängig von der Implementierung können Clients für diesen Angriff anfällig sein, wodurch ein Angreifer, ein MiTM, jedes von ihm gewünschte signierte Zertifikat fälschen kann.

https://www.smacktls.com/ bietet eine ausführliche Erklärung, wie dies aufgrund einer schlechten Implementierung der SSL-Statusmaschine auf dem Client funktioniert.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...