내 이전 게시물에서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의 명령줄에서 이 작업을 어떻게 수행할 수 있는지 아는 사람이 있습니까? 감사해요
업데이트. 내가 왜/어떻게 간과했는지 잘 모르겠습니다.RFC 7.4.9 PRF(master_secret, finished_label, Hash(handshake_messages))모든 핸드셰이크 메시지를 기록했습니다. 지금까지 캡처/해독한 데이터를 사용하여 openssl 명령줄을 사용하여 이를 시뮬레이션할 수 있는 방법을 누군가 설명해 줄 수 있습니까? 이 작업을 수행하기 전에 핸드셰이크 메시지의 해시를 수행해야 하는 것 같습니다.RFC 섹션 5나는 내가 생성한 master_secret을 사용할 것이라고 가정합니다. 이에 대한 시드가 내가 이전에 사용했던 방식으로 openssl을 사용해야 하는지 잘 모르겠습니다. 이 해시에는 연결된 레이블이 없다는 것을 알 수 없으므로 이 지점까지 연결된 모든 핸드셰이크 메시지를 함께 사용해야 합니까? 내가 있는 곳에서 길을 잃고 있는 단계가 많이 있습니다. 감사해요
openssl dgst -sha256 -mac hmac -macopt hexkey:$key <seed -binary >a1
답변1
게시할 때마다 새로운 파일 덤프 형식을 사용하는 것 같아서 궁금합니다. :-)
(RSA-with-)AES256CBC-(HMAC)SHA1을 사용하기 전과 같다고 가정합니다.예, 다음을 사용하여 TLS CBC 암호를 해독할 수 있습니다.openssl enc, ARIA는 제외. (또한 RC4는 TLS를 포함한 어떤 목적으로도 RC4를 사용하지 않아야 합니다. OTOH는 encAEAD 암호화를 수행할 수 없습니다: GCM 또는 CCM은 물론 ChaCha/Poly도 마찬가지입니다.) CBC 암호는RFC5246 섹션 6.2.3.2. AES의 경우 처음 16옥텟은 IV이고 나머지는 일반 텍스트 레코드 본문(이 경우 완료됨 메시지)과 HMAC 및 패딩으로 해독되어야 하는 암호문입니다. 그러나 TLS 패딩은 PKCS5/와 동일하지 않습니다. 7 패딩은 API에서 enc(및 내부적으로 EVP_{??crypt,Cipher}*) 지원되므로 해당 부분을 직접 수행해야 합니다.
시스템의 매뉴얼 페이지에 설명된 대로아니면 웹에서, 그리고 여러 스택에 대한 꽤 많은 질문(비록 내가 언급한 대부분의 질문은 명령줄을 사양이 아닌 Java 및 Python 등과 같은 다른 코드와 일치시키는 것에 관한 것이지만) openssl enc기본값은 다음과 같습니다 .비밀번호 기반암호화(PBE)는 여기서 원하는 것이 아닙니다. '키 기반' 암호 해독을 수행하려면 16진수 키를 사용하여 -d, (소문자가 아닌 대문자) 를 지정해야 하며 , 암호에서 사용하는 경우(AES-CBC는) IV를 16진수로 지정해야 합니다.-K-iv
$ 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그리고 그 출력을 파일에 기록합니다. 이는 다양한 입력(Finished를 포함하는 암호화된 레코드 포함)에 대한 데이터로 사용하거나 확인하기 위해 사용할 수 있는 모든 레코드를 16진수(및 ASCII)로 덤프하고 끝에 있는 'SSL-Session' 블록에는 올바른 값이 포함됩니다. 교차 확인으로 사용할 수 있는 마스터 시크릿입니다. -msg암호화된 메시지를 덤프하도록 추가할 수도 있습니다 . 이것은 더 부피가 크지만 좀 더 편리하며 아래에서 제가 한 일입니다. 설정 작업이 조금 더 필요한 또 다른 가능성은 sysprop javax.net.debug=ssl및 로그를 사용하여 실행되는 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에서는 'transcript' 해시라고 함)에 설명된 대로 모든 이전 핸드셰이크 메시지의 해시를 가져와야 하며, 키가 있는 PRF(이전 게시물에서 설명한 대로)를 가져와야 합니다. 마스터 시크릿과 시드는 고정 라벨 '클라이언트 완료' 또는 '서버 완료'(해당하는 경우)에 해당 성적표 해시를 더한 것입니다. 그것은 훨씬 더 많은 작업이며 필요한 경우 아마도 할 수 있지만 예제에서는 수행하지 않았습니다.