it-swarm.com.de

Warum kann ich den SSL-Verkehr nicht nur mit dem privaten Schlüssel des Clients entschlüsseln?

Ich habe festgestellt, dass ich SSL-Verkehr in Wireshark mit dem privaten Schlüssel des Servers entschlüsseln kann.

Warum reicht der private Schlüssel des Clients nicht aus, um den SSL-Verkehr zu entschlüsseln?

14
Wojtek

Dies liegt daran, dass bei einer SSL/TLS-Verbindung der asymmetrische Schlüsselaustausch den öffentlichen Schlüssel des Servers verwendet, um das Pre-Master-Geheimnis auszutauschen. Ein Client-Zertifikat wird nur dann zur Client-Authentifizierung verwendet, wenn der Server dies anfordert. Das Pre-Master-Geheimnis wird zum Generieren der Sitzungsschlüssel verwendet. Aus diesem Grund benötigen Sie den privaten Schlüssel des Servers, nicht den des Clients.

Typischer SSL/TLS-Schlüsselaustausch :  enter image description here

Beachten Sie, dass beim obigen Austausch nur der Server sein Zertifikat sendet. Die Client-Schlüsselaustauschnachricht ist das Pre-Master-Geheimnis, das mit dem öffentlichen Schlüssel des Servers verschlüsselt ist.

SSL/TLS-Schlüsselaustausch mit Clientauthentifizierung

enter image description here

Im obigen Austausch sehen wir, dass der Server nach dem Senden seines Zertifikats auch eine CertificateRequest-Nachricht bereitstellt. Diese Nachricht fragt den Client nach seinem öffentlichen Zertifikat. Es antwortet mit der ClientKeyExchange-Nachricht wie bei einem typischen Handshake und sendet dann eine ClientVerify-Nachricht, die die Daten des Hash-Schlüsselaustauschs signiert. Der Server verwendet diese Signatur dann, um den Client zu überprüfen.

Der Client oder Server verwendet niemals den öffentlichen Schlüssel des Clients, um Informationen im Handshake zu verschlüsseln. Daher ist es für die Sitzungsentschlüsselung nicht erforderlich.

29
RoraΖ

Da der Client während der Verhandlungsphase 4 den öffentlichen Serverschlüssel zum Verschlüsseln der Kommunikation verwendet (Wikipedia):

4 - Unter Verwendung aller bisher im Handshake generierten Daten erstellt der Client (in Zusammenarbeit mit dem Server, abhängig von der verwendeten Verschlüsselung) das Pre-Master-Geheimnis für die Sitzung und verschlüsselt es mit dem öffentlichen Schlüssel des Servers (bezogen vom Serverzertifikat, gesendet in Schritt 2), und sendet dann das verschlüsselte Pre-Master-Geheimnis an den Server.

Am Ende der Verhandlung generieren beide Seiten einen Sitzungsschlüssel zum Verschlüsseln der Kommunikation.

Ich denke, dass wireshark mit dem privaten Schlüssel des Servers diesen Sitzungsschlüssel während des Handshakes auswählen kann.

Cedric.

5
Infsy

Der private Schlüssel des Clients wird nur bei Verwendung der Clientzertifikatauthentifizierung verwendet und dort nur zum Signieren und nicht zum Entschlüsseln. (bei Verwendung von RSA/DSA-Schlüsseln) (Bei Verwendung von statischem DH ist dies möglicherweise möglich, statisches DH wird jedoch von keinem TLS-Server oder -Client unterstützt.)

2
yyy

Unter der Annahme einer angemessenen Einrichtung der SSL/TLS-Parameter auf der Seite des Servers (oder theoretisch des Clients, aber das ist schwieriger und muss nicht immer funktionieren) sollten Sie mit dem privaten Schlüssel des Servers immer noch keinen Datenverkehr entschlüsseln können, es sei denn, Sie führen einen aktiven Angriff durch.

Es hängt wirklich davon ab, ob Forward Security (FS) zwischen Client und Server ausgehandelt wurde. Es gibt keine Garantie dafür, dass der Client einen Forward-Sicherheitsalgorithmus aushandelt. IE ist notorisch schlecht bei der Auswahl eines FS -Algorithmus) und verlässt sich auf den Server, um die verschiedenen Optionen zu priorisieren. Wenn Sie also beim Einrichten Ihres Algorithmus sehr vorsichtig sind SSL-Optionen auf dem Server UND Ihr Server unterstützt die Priorisierung eines Algorithmus gegenüber einem anderen. Dann ist es möglich, Forward Security auch im IE auszuhandeln.

(Qualsys verfügt über ein hervorragendes Tool, das wichtige Browserverhandlungen mit Websites simuliert.) https://www.ssllabs.com/ssltest/index.html

Im Wesentlichen wählen alle anderen gängigen Browser (Chrome, Firefox, Safari usw.) im Allgemeinen die Weiterleitungssicherheit, wenn der Server dies unterstützt, sodass eine Entschlüsselung nur mit dem privaten Schlüssel des Servers nicht möglich ist.

2
Steve Sether

Die Antwort von Raz gibt einen sehr guten Überblick über Ihre spezielle Situation. Es sollte jedoch erwähnt werden, dass Ihr SSL/TLS schlecht eingerichtet ist, wenn der private Schlüssel des Servers es Ihnen ermöglicht, die Kommunikation tatsächlich zu entschlüsseln, ohne einen MITM-Angriff auszuführen.

Unter der Annahme einer angemessenen Einrichtung der SSL/TLS-Parameter auf der Seite des Servers (oder theoretisch des Clients, aber das ist schwieriger und muss nicht immer funktionieren) sollten Sie mit dem privaten Schlüssel des Servers immer noch keinen Datenverkehr entschlüsseln können, es sei denn, Sie führen einen aktiven Angriff durch.

Die Verwendung von DHE (Diffie-Hellman-Austausch) oder ECDHE (dieselben oben genannten elliptischen Kurven) für den Schlüsselaustausch (Austausch des Hauptgeheimnisses, aus dem die Schlüssel generiert werden) führt zu einer deutlichen Erhöhung der Sicherheit, fast ohne Kosten für Leistung oder Benutzerfreundlichkeit.

1
DRF