Wie kann ich Charles als Proxy verwenden, um HTTPS-Nachrichten in Wireshark zu entschlüsseln?

6180
an0

Ich weiß, dass ich entschlüsselte HTTPS-Daten direkt in Charles anzeigen kann. Aber ich möchte in Wireshark untergeordnete SSL-Nachrichten anzeigen. Also richte ich Charles als SSL-Proxy ein und verwende dabei mein eigenes Zertifikat und die SSL-Präferenz in Wireshark mit der lokalen IP-Adresse und meinem privaten Schlüssel.

enter image description here enter image description here enter image description here

Die Nachrichten in Wireshark sind jedoch immer noch verschlüsselt.

enter image description here

Was habe ich verpasst?

2
Dies ist keine InfoSec-Frage, sondern eine Anwendungs-Konfigurationsfrage. schroeder vor 9 Jahren 0
@schroeder Wirklich? Ich habe es hier gepostet, weil mehrere ähnliche Beiträge, die ich online gelesen habe, alle von hier stammen. Wo schlägst du mich vor? an0 vor 9 Jahren 1
@ schroeder - Wenn Sie das [Hilfe-Center] (http://security.stackexchange.com/help/on-topic) aktivieren, beziehen sich Fragen zu Sicherheitstools speziell zum Thema. Ich kann leider nicht gegen Ihre enge Abstimmung stimmen. paj28 vor 9 Jahren 0
Interessanterweise wurde dies gerade auf reddit / netsec veröffentlicht. Https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/ paj28 vor 9 Jahren 1
(1) Verwendet Charles für die von ihm erstellten * leaf * -Zertifikate denselben Schlüssel wie für das * root * -Zertifikat, das Sie konfiguriert haben? Ich verwende es nicht und sehe nichts in dem skizzenhaften Dokument. (2) Verwendet Ihre Verbindung einen einfachen RSA-Schlüsselaustausch, NICHT DHE oder ECDHE, auch PFS genannt? (3) Was genau ist in Ihrer PEM-Datei? Wireshark unterstützt nur das OpenSSL "Legacy" PKCS # 1-Formular, NICHT PKCS # 8 und nicht verschlüsselt. Alternativ unterstützt Wireshark P12 / PFX direkt und nur dann, wenn Sie das Passwort angeben. (nitpick) `.ssh` ist ein komischer Ort, um SSL-Schlüssel (oder sogar SSL-CA-Schlüssel) zu platzieren. dave_thompson_085 vor 9 Jahren 0
@ paj28 Cooler Trick! Leider möchte ich den Verkehr zwischen meiner iOS-App und dem Server eines anderen entschlüsseln. an0 vor 9 Jahren 0
@ dave_thompson_085 Danke. (1) Ich denke, Charles nimmt nur einen Schlüssel und keinen Schlüssel. Ich habe folgende Tutorials befolgt: http://0x74696d.com/posts/CharlesSSL/, http://codeblog.shape.dk/blog/2014/01/06/custom-ssl-certificate-with-charles-web-proxy/ . (2) Ich verstehe die Frage nicht, weil ich keine Kenntnisse habe. Wie kann ich das überprüfen? (3) Die PEM-Datei wurde im Anschluss an die obigen Tutorials erstellt. an0 vor 9 Jahren 0
Ok, du bist auf ziemlich fortgeschrittene Sachen hier. Ich denke, Ihre beste Option ist, einen Open-Source-Intercepting-Proxy (wahrscheinlich Zap) zu verwenden und den Quellcode so zu bearbeiten, dass der Sitzungsschlüssel protokolliert wird. Sind Sie sicher, dass Sie sich das rohe SSL ansehen müssen? paj28 vor 9 Jahren 0
@ paj28 Derzeit prüfe ich, warum bei einigen HTTPS-Anforderungen eine Zeitüberschreitung auftritt. Ich habe DNS- und Webserver-Probleme bereits ausgeschlossen. Ich denke, ich muss überwachen, wie die SSL / TCP-Verbindungen erstellt werden, um zu prüfen, ob es sich um ein Verbindungsproblem handelt. an0 vor 9 Jahren 0
Sie kontrollieren den Server? Möglicherweise können Sie den SSL-Sitzungsschlüssel serverseitig protokollieren paj28 vor 9 Jahren 0
@ paj28 Leider nein. an0 vor 9 Jahren 0
(1) Charles verwendet eine .pfx-Datei, die einen cert (oder eine hier nicht zutreffende Kette) * und * -Schlüssel enthält. Das Tutorial, zu dem Sie eine Verknüpfung herstellen, sagt etwa viermal aus, dass Sie sowohl cert als auch key für die gefälschte Zertifizierungsstelle generieren. Aber meine Frage ist der Schlüssel, der in und mit den * Leaf-Zertifikaten verwendet wird, nicht das CA-Zertifikat. (2) Die ausgewählte Chiffriersuite befindet sich in der ServerHello-Nachricht, die Sie in Wireshark sehen sollten. Der Name enthält mehrere Komponenten, die den verwendeten Schlüsselaustausch, die symmetrische Chiffre und den Hash für HMAC (und / oder KDF in TLS1.2) angeben. Aber: ... dave_thompson_085 vor 9 Jahren 1
... (3) Dieses Tutorial erstellt 2 PEM-Dateien, aber ich gehe davon aus, dass Sie ca_key.pem verwendet haben. Wenn Sie OpenSSL 1.0.0 oder höher verwendet haben, schreibt `req -new -keyout` in PKCS # 8-Form und verschlüsselt mit der Standardkonfiguration. Um dies zu "beheben", führen Sie `openssl rsa ausca_oldkey.pem` in dem Verzeichnis, in dem es sich befindet, und verwenden Sie stattdessen ca_oldkey.pem in Wireshark als privaten Server des Servers. Oder wie gesagt, verwenden Sie einfach die .pfx mit Passwort. Wenn es funktioniert, erhalten Sie die Daten über die Verbindung von Ihrem Client zu Charles. Mir ist gerade aufgefallen, dass Sie die Daten in Charles haben. ... dave_thompson_085 vor 9 Jahren 0
... Wenn das Problem bei der Verbindung von Charles zum Server liegt, ist das ganz anders. Sie können dies nur mit dem privaten Schlüssel des * Servers * entschlüsseln (und wieder normalem RSA), und wenn dies nicht Ihr Server ist, erhalten Sie das nicht. Oder fast wie @ paj28 sagt, dass Charles oder ein anderer Proxy das * premaster * oder * master * secret (das bei jeder Sitzung anders ist) protokolliert und dies Wireshark (mit einer Zuordnung zu den Sitzungen) übergibt. dave_thompson_085 vor 9 Jahren 0
@ dave_thompson_085 vielen dank! Ich habe bereits .pfx mit Passwort versucht. Es funktioniert nicht Cipher Suite ist TLS_RSA_WITH_RC4_128_MD5 (0x0004). Was ich bemerkt und nicht verstanden habe, ist: Charles ist der mittlere Mann hier und sein Proxy ist localhost: 8888, aber in Wireshark kann ich keine Kommunikation zwischen localhost und dem Proxy sehen, sondern nur zwischen localhost und dem Remote-Server, dh es scheint, als ob der mittlere Mann überhaupt nicht existiert. Ich kann jedoch alle entschlüsselten Mitteilungen in Charles sehen. Es ist normal? an0 vor 9 Jahren 0
@ dave_thompson_085 Ich habe auch `openssl rsa` ausprobiert, aber es erzeugt genau die gleiche Ausgabe wie die Eingabe. Ich denke, das Format von .pem ist für Wireshark bereits gut. an0 vor 9 Jahren 0
Ich habe nachgesehen und lag teilweise falsch. Die Standardkonfiguration für `req -new [key]` verschlüsselt nicht. Wenn Sie also OpenSSL 0.9.8 verwendet haben, haben Sie das alte Format erhalten. zur Bestätigung überprüfen Sie die erste Zeile: Wireshark möchte "----- BEGIN RSA PRIVATE KEY -----" nicht "----- BEGIN PRIVATE KEY -----". ** localhost ** Wenn Sie meinen, dass Ihre App localhost: 8888 als Proxy verwenden soll, ist dies NICHT das Gleiche wie bei der Verwendung der "lokalen IP-Adresse" 10.0.1.10. localhost ist die IP-Adresse 127.0.0.1 (auch als Loopback bezeichnet) und wird (behandelt als) über eine spezielle Loopback-Schnittstelle geleitet, die keine echte Schnittstelle ist. ... dave_thompson_085 vor 9 Jahren 0
Ich weiß es nicht für MacOSX, aber Wireshark unter Windows kann * Loopback-Verkehr * oder * Verkehr auf einem Rechner nicht mit einem echten (routbaren) IPaddr erfassen, und meine Erfahrung mit anderen Netzerfassungen unter Unix war bisher unberechenbar Möglicherweise müssen Sie Ihre App (en) und Charles auf verschiedenen Computern installieren. ** Outbound ** Ich hatte nicht gemerkt, dass Sie (auch?) versuchen, Verbindungen * von * Charles zu den echten Servern zu entschlüsseln. Mit Charles 'Schlüssel geht das überhaupt nicht. Nur das prä- / master-Geheimnis pro Sitzung könnte Ihnen dabei helfen. dave_thompson_085 vor 9 Jahren 0
@ dave_thompson_085 Ich kann bestätigen, dass mein .pem in gutem Zustand ist. Mit localhost meine ich lokale IP. Ich weiß, dass ich den Verkehr zwischen Charles und Server nicht entschlüsseln kann, ohne dessen Geheimnis zu kennen. Ich möchte nur den Verkehr zwischen meiner App und Charles in Wireshark entschlüsseln. Du meinst also, wenn Charles und Wireshark auf dem gleichen Rechner sind, kann ich das nicht machen? an0 vor 9 Jahren 0
Wenn sich die beiden * Programme * (hier Ihre App und Charles) auf derselben * Windows * -Maschine befinden, habe ich keine Möglichkeit gefunden, dass Wireshark das erfasst. Ich habe unterschiedliche Ergebnisse für andere Captures auf (mehreren) Unixen gesehen, und ich habe keine gute Grundlage, um * MacOSX * zu erraten, was meines Erachtens meistens Unix-ähnlich ist, aber manchmal nicht. Es könnte auch andere Tools geben, die Netzwerkdaten * in einem Dateiformat * erfassen * können, die Wireshark * lesen * kann, wie etwa pcap oder -ng. Aber das ist eine etwas andere Frage als Sie, und nicht wirklich meine Sachkenntnis, sorry. dave_thompson_085 vor 9 Jahren 0
@ dave_thompson_085 trotzdem trotzdem vielen dank! Zumindest habe ich etwas gelernt :) an0 vor 9 Jahren 0

1 Antwort auf die Frage

1
Safaci

Das gleiche Problem hatte ich bei Charles Proxy in Kombination mit Wireshark.

Ich denke, das Problem ist, dass Charles zwei (oder mehr) Zertifikate an den Client sendet (überprüfen Sie die Zertifikatnachricht, die vom Proxy an den Client gesendet wird). Wireshark verwendet dann das erste Zertifikat in dieser Liste, das wahrscheinlich nicht mit dem von Ihnen generierten privaten Schlüssel übereinstimmt.

(Genau das fragt sich Benutzer dave_thompson_85 in den Kommentaren.)

Ich habe dies überprüft, indem ich das Zertifikat von Wireshark extrahiere. Beachten Sie, dass Wireshark das Zertifikat im .derFormat extrahiert . Dann habe ich die .der-Datei in ein .pemZertifikat umgewandelt:

openssl x509 -inform DER -outform PEM -text -in wireshark_charles.der -out wireshark_charles.pem 

Ich habe das auch .pemin ein konvertiert .crt, aber das ist nicht notwendig.

Zertifikat von Charles an den Kunden gesendet

$ openssl x509 -noout -modulus -in wireshark_charles.crt | openssl md5  7a37a32781daf79402623c19ac9c8d7f 

Benutzerdefiniertes Zertifikat in Charles eingerichtet

$ openssl x509 -noout -modulus -in charles_custom.crt | openssl md5  62ea5ed061fca62efaaecbbb0226b08e 

Der entsprechende private Schlüssel

$ openssl rsa -noout -modulus -in charles_custom.pem | openssl md5  62ea5ed061fca62efaaecbbb0226b08e 

Der Modul des von Charles gesendeten Zertifikats stimmt nicht mit dem Modul des benutzerdefinierten privaten Schlüssels überein.

Und wireshark protokolliert dieses Problem auch während der SSL-Dissection:

ssl_decrypt_pre_master_secret wrong pre_master_secret length (128, expected 48) ssl_generate_pre_master_secret: can't decrypt pre master secret 

Charles generiert ein neues Pro-Host-Zertifikat, wobei das benutzerdefinierte Zertifikat als Stammzertifikat verwendet wird. Leider habe ich keinen Weg gefunden, diesen von Charles generierten privaten Schlüssel pro Host zu extrahieren. Ich schlage vor, Burp Proxy zu verwenden. In Burp können Sie auswählen, welche Art von Zertifikat Sie verwenden möchten.