Aus meinen vorherigen BeiträgenTeil 1,Teil 2,Teil 3UndTeil 4Ich glaube, ich habe alles richtig berechnet/entschlüsselt und bin bereit, zu versuchen, die vom Client verschlüsselte Handshake-Nachricht zu entschlüsseln. Ich stecke beim nächsten Schritt fest, sobald ich alle Schlüssel habe. Ich habe das ein paar Tage lang gelesen und recherchiert und stecke einfach fest.
Gemäß den Richtlinien aus meinen vorherigen Beiträgen habe ich Folgendes erstellt:
20 bytes for a client MAC key: 64666eafe1cbd51f2e2b50799b40f6007c3dc56f
20 bytes for a server MAC key: e0aac1312d35b5e8b6bf9af6ecf07e1dff27c784
32 bytes client encryption key:
4bf20108190203c4210ff9df6c4eb6e907ddd1f49646ab4b243c80a6ae9b4808
32 bytes for a server encryption key:
ca94445e3d771d3e06b71ee0deb4c1879986c4c6a4b78bf1c3c1083a6ddce9ff
Meine verschlüsselte Client-Handshake-Nachricht:
Hex. FILE SIZE: 40
ADDRESS 000 001 002 003 004 005 006 007 ASCII
===============================================================================
00000000 09A 01B 0F3 06B 078 06C 03B 059 ~Z ^[ -s k x l ; Y
00000008 085 061 07C 076 0AF 0D9 085 0D6 ~E a | v -/ -Y ~E -V
00000010 08F 0FD 0AF 06D 09F 01A 025 0EF ~O -} -/ m ~_ ^Z % -o
00000018 040 015 097 002 0B5 0AD 0EF 040 @ ^U ~W ^B -5 -- -o @
00000020 02B 0DB 051 096 0CE 076 0A9 03F + -[ Q ~V -N v -) ?
00000028 0D7 030 049 03A 0CC 0F9 029 044 -W 0 I : -L -y ) D
00000030 07F 0A9 0C6 0F1 017 02D 06B 040 ^? -) -F -q ^W - k @
00000038 035 0F5 057 08E 0BF 0E9 05C 06D 5 -u W ~N -? -i \ m
00000040
Ich glaube, ich muss eine Variante von openssl end -d -K verwenden, aber ich suche hier zwischen RFC und Google nach einer Lösung/einem Beispiel, das es klar erklärt. Weiß jemand, wie/ob ich das in der Befehlszeile in openssl machen kann? Danke
Update. Ich bin mir nicht sicher, warum/wie ich übersehen habe in derRFC 7.4.9 PRF(master_secret, finished_label, Hash(handshake_messages))Ich habe alle Handshake-Nachrichten protokolliert. Kann mir jemand erklären, wie ich dies mit der OpenSSL-Befehlszeile mit den Daten simulieren kann, die ich bis jetzt erfasst/entschlüsselt habe? Es sieht so aus, als ob ich vorher den Hash der Handshake-Nachrichten ausführen muss.RFC-Abschnitt 5Ich gehe davon aus, dass ich das von mir generierte Master-Geheimnis verwenden werde. Ich bin mir nicht sicher, was der Seed dafür sein soll, wenn ich OpenSSL so verwende, wie ich es bisher verwendet habe. Ich sehe nicht, dass für diesen Hash ein Label verknüpft ist. Verwende ich also einfach alle Handshake-Nachrichten bis zu diesem Punkt verknüpft? Es gibt viele Schritte, bei denen ich nicht mehr weiterkomme. Danke
openssl dgst -sha256 -mac hmac -macopt hexkey:$key <seed -binary >a1
Antwort1
Ich finde es faszinierend, dass Sie scheinbar bei jedem Post ein neues Datei-Dump-Format verwenden :-)
Angenommen, Sie verwenden wie zuvor (RSA-mit-)AES256CBC-(HMAC)SHA1:ja, Sie können TLS CBC-Chiffren entschlüsseln mitopenssl enc, außer ARIA. (Auch RC4, obwohl Sie die Verwendung von RC4 für alle Zwecke, einschließlich TLS, vermeiden sollten. Andererseits enckann ich keine AEAD-Chiffren verwenden: weder GCM noch CCM und auch nicht ChaCha/Poly.) Das Datensatzformat in TLS1.2 (und 1.1) für eine CBC-Chiffre wird behandelt inRFC5246 Abschnitt 6.2.3.2. Bei AES sind die ersten 16 Oktette der IV und der Rest der Geheimtext, der sich in den Klartext des Datensatzkörpers (in diesem Fall die Fertig-Nachricht) plus HMAC plus Padding entschlüsseln lässt – aber TLS-Padding ist nicht dasselbe wie das von der API enc(und intern auch von ihr EVP_{??crypt,Cipher}*) unterstützte PKCS5/7-Padding, also müssen Sie diesen Teil selbst erledigen.
Wie in der Manpage auf Ihrem System beschriebenoder im Webund eine ganze Reihe von Fragen zu mehreren Stacks (obwohl die meisten, die ich bemerkt habe, sich um die Anpassung der Befehlszeile an anderen Code wie Java und Python usw. und nicht an eine Spezifikation drehen), openssl enclautet standardmäßigpasswortbasiertVerschlüsselung (PBE), was hier nicht das ist, was Sie wollen. Um eine „schlüsselbasierte“ Entschlüsselung durchzuführen, müssen Sie -d, -K(Großbuchstaben, keine Kleinbuchstaben) mit dem Schlüssel in Hexadezimalschrift und -ivmit dem IV in Hexadezimalschrift angeben, wenn die Chiffre dies verwendet (AES-CBC tut dies):
$ echo $key; echo $iv
4bf20108190203c4210ff9df6c4eb6e907ddd1f49646ab4b243c80a6ae9b4808
9A1BF36B786C3B5985617C76AFD985D6
$ sed 1,2d <1346633.dat
8FFDAF6D9F1A25EF
40159702B5ADEF40
2BDB5196CE76A93F
D730493ACCF92944
7FA9C6F1172D6B40
35F5578EBFE95C6D
$ sed 1,2d <1346633.dat |xxd -p -r |openssl aes-256-cbc -d -K $key -iv $iv -nopad |xxd
0000000: f730 34cc b90f b0b0 6313 9a0f 239c 6e87 .04.....c...#.n.
0000010: 187f ff00 52d1 3e9c 2aef d5cd c07e 15be ....R.>.*....~..
0000020: dee0 aa95 6994 5ce6 768d 1952 ac00 17ba ....i.\.v..R....
Wie Sie sehen, ist diese Entschlüsselung leider ungültig: Sie endet nicht mit einer TLS-ähnlichen Auffüllung und beginnt nicht mit einer Fertigmeldung, wie sie die erste Übertragung des Clients nach CCS sein muss. Entweder ist Ihr abgeleiteter Schlüssel falsch oder Ihr Dump dieses Datensatzes.
Ein Vorschlag, der hilfreich sein könnte: Stellen Sie eine Verbindung her über(bearbeiten) openssl s_client -debugund protokolliert die Ausgabe in einer Datei. Dadurch werden alle Datensätze in Hex (und ASCII) ausgegeben, die Sie als Daten für die verschiedenen Eingaben verwenden oder diese überprüfen können (einschließlich des verschlüsselten Datensatzes mit „Fertig“). UND der Block „SSL-Sitzung“ am Ende enthält den korrekten Wert des Hauptgeheimnisses, den Sie zur Gegenprüfung verwenden können. Sie können hinzufügen, -msgdass auch die verschlüsselten Nachrichten ausgegeben werden. Dies ist umfangreicher, aber etwas praktischer, und ich habe es unten getan. Eine andere Möglichkeit, die etwas mehr Arbeit beim Einrichten erfordert, besteht darin, eine Verbindung von einem Java SSL/TLS (JSSE)-Clientprogramm herzustellen, das mit Sysprop javax.net.debug=sslund Log ausgeführt wird. Dies gibtvielevon Informationen, einschließlich des HauptgeheimnissesUndfunktionierende Schlüssel.
Als Beispiel dafür, wie diesesollenArbeit, ich habe das Verfahren anhand einer protokollierten Beispielsitzung durchgearbeitet (die ich tatsächlich vor einigen Wochen bei Ihrem ersten Q erstellt habe), indem ich die Master- und Arbeitsableitungen manuell durchgeführt und die Fertigmeldung des Clients entschlüsselt und überprüft habe:
$ cat tempc
2f e9 97 3e e4 11 89 81 c5 bc 18 11 7b c9 e9 3d
64 cb 88 6e a4 ac f2 01 95 05 d7
fe 3d 09 f4 13 4a d7 39 77 bf 50 dc f4 7b 9b b8
3c 0b 2f bf 98 5a 9c 4c 2d 28 6c 6a b6 93 a9 29
c5 5f f1 a3 cd
$ # this is the hexdump of from s_client -debug, cleaned up
$
$ echo $key; echo $iv
7d18617e178fc6320019442c6cd071ca4b4f7d2bb83f6194c23681aefd84f120
2fe9973ee4118981c5bc18117bc9e93d
$ # you can see the IV is the first line (16 bytes) of tempc
$ sed 1d tempc |xxd -p -r |openssl aes-256-cbc -d -K $key -iv $iv -nopad |tee tempc! |xxd
0000000: 1400 000c 5bbc 39d8 6c5d dbb1 076b b91b ....[.9.l]...k..
0000010: 9f4e 5c55 fd9e a185 6901 4bc0 6f02 2c0d .N\U....i.K.o.,.
0000020: 5bb0 d8c9 0b0b 0b0b 0b0b 0b0b 0b0b 0b0b [...............
$ # those last 12 bytes are SSL/TLS-style padding
$ # the first 4 bytes are a handshake message header for x14=Finished,
$ # followed by the 12 byte verify_data value, total 16 bytes
$
$ echo $mkey
28a3244d49c644f889b44f2bae54466b6913fb1e
$ { printf '\0\0\0\0\0\0\0\0\x16\x03\x03\0\x10'; head -c16 tempc! ; } \
> |openssl sha1 -mac hmac -macopt hexkey:$mkey -binary |xxd -p
9f4e5c55fd9ea18569014bc06f022c0d5bb0d8c9
$ # the 20 bytes after the 16-byte message and before the padding
$ # correctly match HMAC-SHA1 of the pseudoheader plus the message
Was die„Daten überprüfen“Indie Fertigmeldung, ja, Sie müssen den Hash aller vorherigen Handshake-Nachrichten nehmen, wie in 7.4.9 beschrieben (in TLS1.3 wird dies als „Transkript“-Hash bezeichnet) und dann den PRF (wie in früheren Beiträgen besprochen), wobei der Schlüssel das Hauptgeheimnis und der Seed die feste Bezeichnung „Client abgeschlossen“ oder „Server abgeschlossen“ (je nach Anwendbarkeit) plus dieser Transkript-Hash ist. Das ist deutlich mehr Arbeit und ich habe es für das Beispiel nicht gemacht, obwohl ich es bei Bedarf wahrscheinlich tun kann.