Entschlüsseln Sie den SSL-Verkehr mit dem Befehlszeilenprogramm openssl 8

464
David B

Für meine letzten Schritte in meinem Skript folgte ich diesem Schritt, um den Client-Verschlüsselungsschlüssel zu erhalten, mit dem die Entschlüsselung durchgeführt werden kann.

client.random xxd -p crnd.bin

5b689404b500456eef2f1a79ec782eb3eeaac3a8d7c02ae03c8426f363b1 8a33

server.random xxd - srnd.bin

5b6894043bb1289e158b0278ef66dc53c9fa71e75e900739af2657cd4476 ec1e

(Echo -n-Tastenerweiterung; cat srnd.bin crnd.bin)> master_seed.key
xxd -p master_seed.key

6b657920657870616e73696f6e 5b6894043bb1289e158b0278ef66dc53c9 fa71e75e900739af2657cd4476ec1e 5b689404b500456eef2f1a79ec782e b3eeaac3a8d7c02ae03c8426f363b18a33 note: as before the spaces are not there I added them for clarity  key=$(cat master_secret.hex)  openssl dgst -sha256 -mac hmac -macopt hexkey:$key <master_seed.key -binary >a1 openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a1 -binary >a2 openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a2 -binary >a3 openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a3 -binary >a4 ## cat a1 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k1 cat a2 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k2 cat a3 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k3 cat a4 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k4 cat k1 k2 k3 k4 | head -c104 | xxd -p -c104 > k1_k4.hex truncate -s-1 k1_k4.hex  $cat k1_k4.hex 64666eafe1cbd51f2e2b50799b40f6007c3dc56fe0aac1312d35b5e8b6bf9af6ecf07e1dff27c784 4bf20108190203c4210ff9df6c4eb6e907ddd1f49646ab4b243c80a6ae9b4808ca94445e3d771d3e 06b71ee0deb4c1879986c4c6a4b78bf1c3c1083a6ddce9ff dd bs=40 count=1 if=k1_k4.hex of=cmackey.hex 2>/dev/null dd bs=40 count=1 skip=1 if=k1_k4.hex of=smackey.hex 2>/dev/null dd bs=80 skip=1 if=k1_k4.hex 2>/dev/null | dd bs=64 count=1 of=cenckey.hex 2>/dev/null dd bs=80 skip=1 if=k1_k4.hex 2>/dev/null | dd bs=64 skip=1 count=1 of=senckey.hex 2>/dev/null

$ cat cmackey.hex

64666eafe1cbd51f2e2b50799b40f6007c3dc56f

$ cat smackey.hex

e0aac1312d35b5e8b6bf9af6ecf07e1dff27c784

$ cat cenckey.hex

4bf20108190203c4210ff9df6c4eb6e907ddd1f49646ab4b243c80a6ae9b4808

$ cat senckey.hex

ca94445e3d771d3e06b71ee0deb4c1879986c4c6a4b78bf1c3c1083a6ddce9ff

Verschlüsselte Handshake-Protokollierung

TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 64 Handshake Protocol: Encrypted Handshake Message  Handshake Protocol: Encrypted Handshake Message 16030300409a1bf36b786c3b5985617c76afd985d68ffdaf 6d9f1a25ef40159702b5adef402bdb5196ce76a93fd73049 3accf929447fa9c6f1172d6b4035f5578ebfe95c6d

Nur die verschlüsselten Daten gespeichert (letzte 64 Bytes in cenc.dat) $ xxd -p cenc.dat

9a1bf36b786c3b5985617c76afd985d6 8ffdaf6d9f1a25ef40159702b5ad ef402bdb5196ce76a93fd730493accf929447fa9c6f1172d6b4035f5578e bfe95c6d Note: space added again for clarity

$ xxd -p iv.bin 

9a1bf36b786c3b5985617c76afd985d6

$ xxd -p encmsg.bin

8ffdaf6d9f1a25ef40159702b5adef402bdb5196ce76a93fd730493accf9 29447fa9c6f1172d6b4035f5578ebfe95c6d

Zuletzt

$cat encmsg.bin | openssl aes-256-cbc -d -K $key -iv $iv -nopad |xxd gives the same result of bad decrypted data not a finished (14) record

Dave, beim Vergleich meines Ausgangsbytes für Byte sehe ich keine Probleme mit meinen Schritten. Ich habe dies ein Dutzend oder mehr manuell durchgegangen und mein Skript aufgerufen, und ich bekomme dieselbe Ausgabe, die falsch ist, weil Sie darauf hingewiesen haben, dass sie nicht zu einer Abschlussmeldung entschlüsselt wird. Spürst du hier etwas? Vielen Dank

0
Wer ist Dave? .... djsmiley2k vor 5 Jahren 1
Die Person, die mir geholfen hat. Ich hoffe, das war nicht außerhalb der Linie, um ihn an ihn zu richten. Ich hatte das in meinen vorherigen Beiträgen gemacht. David B vor 5 Jahren 0
Es ist nur verwirrend zu lesen. Das ist alles. djsmiley2k vor 5 Jahren 0
Vielleicht hilft ein @_daveSomethingOrOther_ zu seiner Stack-Austausch-ID Hogstrom vor 5 Jahren 0
Nein, ich sehe nichts. Die einzige verbleibende Möglichkeit, die mir einfällt, ist, dass Ihre Systeme die [Extended Master Secret-Erweiterung] (https://tools.ietf.org/html/rfc7627) verwendet haben, die (radikal!) Die Master-Secret-Ableitung ändert also natürlich die tasten. Überprüfen Sie ClientHello und ServerHello im Capture, ob _both_ diese Erweiterung enthält (0017 hex oder 23 decimal, wenn wireshark sie nicht decodiert). dave_thompson_085 vor 5 Jahren 0
@Hogstrom: @ -notify funktioniert nur für Personen, die bereits auf _this_ Q 'anwesend' sind, NICHT Sitewide. Siehe Hinweis 1 in der Hilfe für das Kommentarfeld oder das ausführlichere https://meta.stackexchange.com/questions/43019/how-do-comment-replies-work. Der Fragesteller hat das [vorherige Q] (https://superuser.com/questions/1347558/) kommentiert, bei dem ich der einzige andere Kommentator war, der mich automatisch "anpingte". dave_thompson_085 vor 5 Jahren 0
Danke, habe es mir erlaubt, meine Protokolle und RFC7627 zu überprüfen. Ich habe von unserem sys-Administrator gehört, der daran arbeiten wird, die Bibliotheken zu unseren Mumps-Betriebssystemen hinzuzufügen, die auf Unix laufen. Das sollte die Sache einfacher machen, aber es gibt keine Eta, wann ich diese zur Verfügung habe. David B vor 5 Jahren 0
das ist es! Der Kunde hatte 17 (23) für den erweiterten Handshake geschickt. Ich habe nicht bemerkt, dass ich meine Antwort mit einer 17 codiert habe, was auch mein Server angibt. Ich habe meine Antwort geändert, um kein erweitertes Hauptgeheimnis zu verwenden, und die Entschlüsselung hat funktioniert. Ich habe meinen nächsten Artikel gepostet, um hoffentlich kurz vor dem Abschluss [hier] (https://superuser.com/questions/1348665/decrypt-ssl-traffic-with-the-openssl-command-line-tool-9) zu stehen einen Blick Dave danke. David B vor 5 Jahren 0

0 Antworten auf die Frage

Verwandte Probleme