以前の投稿からパート1、パート2、パート3そしてパート4すべてを正しく計算/復号化し、クライアントの暗号化されたハンドシェイク メッセージの復号化を試みる準備が整ったと思います。すべてのキーを入手したら、次のステップで行き詰まっています。数日間これについて読んで調査してきましたが、まったく行き詰まっています。
以前の投稿のガイドラインに従って、私は
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
暗号化されたクライアント ハンドシェイク メッセージ:
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
openssl end -d -K のバリエーションを使用する必要があると思いますが、RFC と Google の間で、明確に説明されている解決策/例を見つけるのに苦労しています。openssl のコマンド ラインでこれを行う方法/実行できるかどうかを知っている人はいますか? よろしくお願いします
更新。なぜ/どのように私が見落としたのかはわかりませんRFC7.4.9 参照 PRF(master_secret, finished_label, Hash(handshake_messages))ハンドシェイクメッセージはすべてログに記録していますが、これまでにキャプチャ/復号化したデータを使用して、opensslコマンドラインだけでこれをシミュレートする方法を誰か説明できますか。ハンドシェイクメッセージのハッシュは、この前に実行する必要があるようです。RFCセクション5生成したマスター シークレットを使用するつもりですが、以前使用していた方法で openssl を使用する場合、シードが何になるかわかりません。このハッシュには連結されたラベルがあるようには見えないので、この時点までのハンドシェイク メッセージをすべて連結して使用するだけでよいのでしょうか。手順が多数あり、どこにいるのかよくわかりません。ありがとうございます。
openssl dgst -sha256 -mac hmac -macopt hexkey:$key <seed -binary >a1
答え1
投稿するたびに新しいファイルダンプ形式を使用しているように見えるのが興味深いです :-)
以前と同じように (RSA-with-)AES256CBC-(HMAC)SHA1 を使用していると仮定します。はい、TLS CBC暗号を復号化できます。openssl encARIAを除く。（RC4も使用できますが、TLSを含むいかなる目的にもRC4の使用は避けてください。一方、encAEAD暗号は使用できません。GCMやCCM、ChaCha/Polyも使用できません。）TLS1.2（および1.1）のCBC暗号のレコード形式については、RFC5246 セクション 6.2.3.2AES の場合、最初の 16 オクテットが IV で、残りが暗号文です。暗号文は、プレーンテキストのレコード本体 (この場合は Finished メッセージ) と HMAC とパディングに復号化されますが、TLS パディングは、( APIencによって内部的にもEVP_{??crypt,Cipher}*) でサポートされている PKCS5/7 パディングと同じではないため、その部分は自分で行う必要があります。
システムのマニュアルページに記載されているとおりまたはウェブ上で、そしていくつかのスタックでかなりの数の質問があります（私が気づいたほとんどの質問は、JavaやPythonなどの他のコードとコマンドラインを一致させることに関するもので、仕様に関するものではありませんが）、openssl encデフォルトではパスワードベース暗号化 (PBE) は、ここで必要なものではありません。 'キーベース' の復号化を行うには、 , -d(-K小文字ではなく大文字) を 16 進数のキーとともに指定し、-iv暗号で使用される場合は 16 進数の IV も指定する必要があります (AES-CBC は使用します)。
$ 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....
残念ながら、ご覧のとおり、この復号化は無効です。TLS スタイルのパディングで終了しておらず、クライアントによる CCS 後の最初の送信がそうであるはずの Finished メッセージで始まっていません。派生キーが間違っているか、このレコードのダンプが間違っているかのどちらかです。
役に立つかもしれない提案：（編集） openssl s_client -debugそして、その出力をファイルに記録します。これにより、すべてのレコードが 16 進数 (および ASCII) でダンプされ、さまざまな入力 (Finished を含む暗号化されたレコードを含む) のデータとして使用したり、検証したりすることができます。また、最後の「SSL-Session」ブロックには、クロスチェックとして使用できるマスターシークレットの正しい値が含まれています。暗号-msg化されたメッセージをダンプするように追加することもできます。これはかさばりますが、少し便利で、以下で実行しました。もう 1 つの可能性は、設定に少し手間がかかりますが、syspropjavax.net.debug=sslと log で実行される Java SSL/TLS (JSSE) クライアントプログラムから接続することです。これはダンプします。たくさんマスターシークレットを含む情報そして機能するキー。
この例としてすべき作業では、ログに記録されたサンプル セッション (数週間前の最初の Q で実際に作成したもの) で手順を実行し、マスターと作業の派生を手動で実行し、クライアントの Finished メッセージを復号化して検証しました。
$ 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
に関しては'データの検証'で完了メッセージはい、7.4.9 で説明されているように、以前のハンドシェイク メッセージすべてのハッシュ (TLS1.3 では、これは「トランスクリプト」ハッシュと呼ばれます) を取得し、次に PRF (以前の投稿で説明したように) を取得する必要があります。ここで、キーはマスター シークレット、シードは固定ラベル「クライアント終了」または「サーバー終了」(該当する場合) とそのトランスクリプト ハッシュです。これはかなりの作業量であり、この例では実行しませんでしたが、必要であれば実行できる可能性があります。