Entschlüsseln Sie den SSL-Datenverkehr mit dem Befehlszeilenprogramm openssl - Fortsetzung Teil 3

537
David B

Von meinen vorherigen Fragen / Thread-Start- Teil 1 und Follow-Up- Teil 2 nach meiner geführten Erklärung, da meine erfassten Dateien / Daten binärer Natur sind, habe ich die folgenden openssl-Befehle verwendet, bei denen ich mit meinem Premaster-Secret begann, aus dem abgeleitet wurde:

openssl rsautl -in cpre.key -inkey key.pem -decrypt -out spre.key 

Dies erstellt meine 48-Byte-Server-Master-Master-Datei spre.key (ich denke, ist richtig) und in dezimaler (für die Anzeige mit Bett) als:

003 003 203 048 063 215 047 196 221 221 221 014 019 072 011 100 217 080 111 073 217 026 234 082 022 212 232 025 096 063 115 080 016 094 015 170 148 126 092 118 109 228 246

24 044 220 Hex: 0303CB303FD72FC4DDDDD0E13480B64D9506F49D91AE5215D15E04A8A052A5

Und die Verkettung des wörtlichen "master secret" + client.random + server.andomom habe ich mseed.key erstellt und erneut mit dem Bett auf dieselbe Weise wie das von mir erstellte Dezimalformat angezeigt :

109 097 115 116 101 114 032 115 101 099 114 101 116 173 212 147 215 014 129 225 102 157 027 001 125 167 097 014 085 064 025 114 025 248 096 254 044 235 151 130 033 151 015 133 251 114 232 095 213 076 194 057 175 106 08 08 206 08 08 080 198 061 180 043

Hex: 6D617374657220736563726574ADD493D70E81E1669D1B017DA7610E554019721918F860FE2CEB978221970F85FB72E85FD54CC239AF6AE158CE45BB32A81FD950C63DB42B
für insgesamt 69 Bytes

Next ich, daß zusammen und da ich wurde darauf hingewiesen, dass die Daten in binären Dateien wobei ich folgendes zu erzeugen, um das Master - Geheimnis und Schlüssel verwendet.

openssl dgst -sha256 -hmac spre.key <mseed.key -binary >a1 openssl dgst -sha256 -hmac spre.key <a1 -binary >a2 openssl dgst -sha256 -hmac spre.key <a2 -binary >a3 openssl dgst -sha256 -hmac spre.key <a3 -binary >a4 

Dadurch wurden 4 32-Byte-Dateien erstellt.

Anschließend erstellen Sie die Schlüssel mit:

cat a1 mseed.key | openssl dgst -sha256 -hmac spre.key -binary >k1 cat a2 mseed.key | openssl dgst -sha256 -hmac spre.key -binary >k2 cat a3 mseed.key | openssl dgst -sha256 -hmac spre.key -binary >k3 cat 42 mseed.key | openssl dgst -sha256 -hmac spre.key -binary >k4 

Dadurch wurden 4 32-Byte-Dateien erstellt.

Nach den Beispielen, die mir gegeben wurden, und dem Lesen des RFC, wenn ich es verstehe, wäre der Hauptschlüssel an dieser Stelle die ersten 48 Bytes von a1 + a2. Ist das richtig oder habe ich etwas verpasst? Da ich eigentlich nicht in der Lage bin zu sehen, was der master_secret-PRF zurückgibt oder tut, denke ich, wenn ich die Befehlszeile wie oben ausgeführt ausführe, würde ich das Master-Geheimnis erhalten. Danke David

0

1 Antwort auf die Frage

2
dave_thompson_085

Erstens sollte Ihre Mseed-Datei (Label + Seed-Wert in der PRF) 77 Byte und nicht 69 Byte betragen. Sie müssen die Client- und / oder Server-Nonces irgendwie durcheinander gebracht haben.

Zweitens -hmac spre.keyist schlimm falsch. Als HMAC-Schlüssel werden die tatsächlichen Zeichen verwendet, s p r e . k e y dh die Oktette 73 70 72 65 2e 6b 65 79. Sie müssen den Wert des entschlüsselten Premaster-Secret verwenden, der den Inhalt Ihrer Datei spre.key darstellt. Und da dies binäre Daten sind, die Bytes enthalten können, die Sonderzeichencodes wie Null, Tabulator, Dollarzeichen, Anführungszeichen, Backslash, Löschen usw. sind, können Sie sie nicht direkt, als -hmac oder auch nicht sicher übergeben -hmac ''. Stattdessen müssen Sie -mac hmac -macopt hexkey:wie in der vorherigen Antwort angegeben verwenden, mit Ausnahme des tatsächlichen Hex-Schlüsselwerts, den Sie in diesem Q angegeben haben 0303CB30...2CDC.

Drittens verketten Sie, wie ich in der vorherigen Antwort gezeigt habe, die Ergebnisse der zweiten HMAC-Schicht, dh in meiner Notation k1, k2, ..., um die Ausgabe zu bilden (die in diesem Beispiel 100 Oktette war):

$ cat k1 k2 k3 k4 | head -c100 | xxd 

aber wie ich weiter sagte:

... auch für den eigentlichen TLS1.2-Handshake, angepasst an die richtigen Längen: 48 für das Master-Secret und abhängig von der Ciphersuite für die Arbeitsschlüssel.

Für die erste (Premaster-Master-Ableitung) benötigen Sie 48 Oktette, so dass Sie nur die ersten beiden Chunks von 32 (a0-> a1-> a2 a1 + a0-> k1 a2 + a0-> k2) und dann k1 verketten + k2 und nimm die ersten 48 Oktette.

Für die zweite (Master-to-Working) -Ableitung hängt die Länge, die Sie benötigen, von der Chiffriersuite ab, die ausgehandelt wurde. Sie sagten, Sie verwenden RSA-with-AES256CBC-SHA, das (in TLS1.2 oder 1.1, aber nicht 1.0) 40 Oktette HMAC-Schlüssel und 64 Oktette Verschlüsselungsschlüssel mit insgesamt 104 Oktetten benötigt. Für 104 OZets müssen Sie 4 Chunks von 32 berechnen, k1 + k2 + k3 + k4 verketten und in dieser Reihenfolge an Client-MAC, Server-MAC, Client-Verschlüsselung und Serververschlüsselung auslagern. Siehe 6.3 der RFC. Beachten Sie auch, dass das Label unterschiedlich ist und für diese Ableitung der Startwert (label +) server_random + client_random ist, nicht (label +) client_random + server_random wie im ersten.

Ah ... ok ich habe mseed.key mit reinen Zufallszahlen generiert, von denen ich nicht wusste, dass dies die Zeit einschließen würde. Ich werde das mit der Zeit neu erstellen, dies sollte 77 Bytes erzeugen. Ich mache das und gehe noch einmal durch die Schritte, bevor ich ein Follow-up poste. Beim Entschlüsseln des Pre-Master-Secret mit openssl rsautl war mein cpre.key im Binärformat und das key.pem war die base64-Datei-Pem-Datei, die während meiner Zertifikatserstellung erstellt wurde. Ich glaube, dass die PEM-Datei das richtige Format hat, nicht sicher, ob cpre.key in einem anderen Format vorliegen muss oder nicht. Ich bin etwas verwirrt darüber, welche Formate verwendet werden sollen David B vor 5 Jahren 0
Ja, `rsautl -inkey` ist standardmäßig PEM (jedes der vier PEM-Formate, die OpenSSL für den privaten RSA-Schlüssel verwendet) und Eingabe und Ausgabe (Ihr cpre.key und spre.key) sind binär. Das Hex, das Sie für spre.key zeigen, sieht korrekt aus. Es ist definitiv die richtige Länge und das richtige Format (die ersten beiden Oktette 03 03 sind eine Anti-Downgrade-Funktion, siehe Abschnitt 7.4.7.1 in der RFC), und ein Fehler wäre unwahrscheinlich unwahrscheinlich, dass eine entschlüsselbare Auffüllung mit der richtigen Länge und dem richtigen Format erzeugt wurde. dave_thompson_085 vor 5 Jahren 0
Ok, nachdem ich gestern zwei Töpfe Kaffee getrunken und meine letzte kubanische Zigarre geraucht habe, bin ich mit den folgenden Schritten [hier] gekommen (https://superuser.com/questions/1344061/decrypt-ssl-traffic-mit-the-openssl -Befehlszeile-Werkzeug-Fortsetzung-Teil-4), von dem ich glaube, dass ich diese und die vorige Ausgabe angesprochen habe. David B vor 5 Jahren 0
Dave, ich bin ein wenig mit [Teil 5] (https://superuser.com/questions/1346633/decrypt-ssl-traffic-mit-openssl-command-line-tool-continued-part-5?noredirect) beschäftigt = 1 & lq = 1) Könntest du dir meinen letzten Beitrag dort ansehen und kommentieren, dass ich ein bisschen verloren gehe? Ich glaube, ich mache Fortschritte, aber jetzt ist es ein bisschen festgefahren. Vielen Dank David B vor 5 Jahren 0