it-swarm-eu.dev

Ist das Spoofing eines CA-signierten Zertifikats möglich?

Ich hatte noch nie über diese Situation nachgedacht, ich kann mich völlig irren, aber ich werde es trotzdem klären müssen. 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 angreifen, 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?

20
sudhacker

Der Handschlag umfasst folgende (grobe) Schritte:

  1. Der Server sendet seinen öffentlichen Schlüssel.
  2. Der Client verschlüsselt Setup-Informationen mit diesem öffentlichen Schlüssel und sendet sie an den Server zurück.
  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.

Die Antwort auf Ihre Frage lautet also: Da ein Betrüger Schritt 3 nicht ausführen kann (da er nicht über den privaten Schlüssel verfügt), kann er niemals mit Schritt 4 fortfahren. Er hat kein gemeinsames Geheimnis, also kann er ' t Führen Sie den Handschlag durch.

29
gowenfawr

Asudhak, fühle dich nicht schlecht, wenn das etwas verwirrend ist. Das Erfinden von asymmetrische 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, 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 zu verschlüsseln , dass einmal ein geheimes Passwort verwendet wird. Der öffentliche Schlüssel kann nur verschlüsseln , der öffentliche Schlüssel kann nicht entschlüsseln !

Der Client kann dieses verschlüsselte geheime Passwort 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 ein Geheimnis, das niemand sonst kennt !

Mithilfe dieses Geheimnisses 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 von ' Zertifikate ', der die öffentlichen Schlüssel von Organisationen enthält, 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.

9
Jim In Texas

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, das zum Generieren des Master Secret verwendet 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 zu berechnen, das als "Hauptgeheimnis" bezeichnet wird. 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 weitergeleitet wird.

Denken Sie daran, dass bei der asymmetrischen Kryptografie der öffentliche Schlüssel keineswegs ein Geheimnis ist und für einen Angreifer im Allgemeinen (sofern keine anderen Fehler vorliegen) keinen Nutzen hat.

4
dr jimbob

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). (Es gibt eine Antwort mit mehr Details hier zum Beispiel.)

Der unmittelbare Zweck des SSL/TLS-Handshakes besteht darin, ein gemeinsames Pre-Master-Geheimnis zwischen dem Client und dem Server herzustellen. 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 Cipher Suites mit einem DSS Zertifikat): Es findet ein Diffie-Hellman-Schlüsselaustausch 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 die Verschlüsselung, die andere die 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 wird, mit dem er kommunizieren möchte. Dies sind jedoch leicht getrennte Punkte.)

3
Bruno

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

öffentliche 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 eine mit dem privaten Schlüssel verschlüsselte Nachricht entschlüsseln. 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. Die Zertifizierungsstelle sendet eine Bestätigungsnachricht an die mit dem Domainnamen verknüpfte E-Mail-Adresse, um zu beweisen, dass diese Anfrage vom echten Eigentümer des Domainnamens gestellt wurde. Zu diesem Zeitpunkt wartet die Zertifizierungsstelle, bis der Domaininhaber die Anforderung per E-Mail bestätigt.

Zertifikatsignierung

Die Zertifizierungsstelle verschlüsselt den Domänennamen, die Unternehmensinformationen und den öffentlichen Schlüssel des Webservers mit ihrem eigenen privaten Schlüssel. Die Zertifizierungsstelle 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. Der Webserver sendet dieses Zertifikat an den Browser des Benutzers.

Vertrauenswürdige Zertifizierungsstellen

Der Webbrowser enthält eine Liste vertrauenswürdiger Zertifizierungsstellen und ihrer öffentlichen Schlüssel. 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 kennt jetzt die vertrauenswürdigen Unternehmensinformationen, den öffentlichen Schlüssel und den Domainnamen, die dem Webserver zugeordnet werden sollen, der 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 des Zertifikats zum Verschlüsseln seiner Nachrichten verwenden kann, da nur der private Schlüssel des echten Webservers diese Nachricht entschlüsseln kann.

Beachten Sie, dass der Webbrowser bei Verwendung eines nicht vertrauenswürdigen öffentlichen Schlüssels (der die Überprüfung der Zertifizierungsstelle nicht durchläuft) möglicherweise vertrauliche Informationen verschlüsselt und gesendet hat, 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 seine Nachricht mit dem 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.

gemeinsamer geheimer Schlüssel

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 daher darin, einen gemeinsamen geheimen Schlüssel zu verwenden, mit dem eine Nachricht verschlüsselt und auch entschlüsselt werden 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.

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.

Zur weiteren Lektüre:

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

  • Vertrauenskette unter den Zertifizierungsstellen

1
user87763

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, der zum öffentlichen Schlüssel gehört .

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.

0
MaxxVadge

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.

0
sudhacker

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, müssen Sie den öffentlichen Schlüssel weiterhin 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.

0
Lucas Kauffman