De mis publicaciones anterioresparte 1,parte 2,parte 3yparte 4Creo que he calculado/descifrado todo correctamente y estoy listo para intentar descifrar el mensaje de protocolo de enlace cifrado del cliente. Estoy atascado en el siguiente paso una vez que tengo todas las claves. He estado leyendo e investigando esto durante un par de días y simplemente me quedé estancado.
Siguiendo las pautas de mis publicaciones anteriores que se me ocurrieron
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
Mi mensaje de protocolo de enlace de cliente cifrado:
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
Creo que necesito usar una variación de openssl end -d -K pero tropezando aquí entre el RFC y Google para encontrar una solución/ejemplo que lo explique claramente. ¿Alguien sabe si puedo hacer esto en la línea de comando en openssl? Gracias
Actualizar. No estoy seguro de por qué/cómo lo pasé por alto en elRFC 7.4.9 PRF(master_secret, finished_label, Hash(handshake_messages))He registrado todos los mensajes de protocolo de enlace. ¿Alguien puede explicar cómo puedo simular esto solo con la línea de comando de openssl con los datos que he capturado/descifrado hasta este punto? Parece que el hash de los mensajes de protocolo de enlace es lo que necesito realizar antes de esto.RFC sección 5Supongo que voy a usar el master_secret que generé. No estoy seguro de cuál debería ser la semilla para esto usando openssl como lo he estado usando anteriormente. No veo que para este hash haya una etiqueta concatenada, así que ¿uso todos los mensajes de protocolo de enlace hasta este punto concatenados juntos? Hay muchos pasos en los que me estoy perdiendo. Gracias
openssl dgst -sha256 -mac hmac -macopt hexkey:$key <seed -binary >a1
Respuesta1
Me intriga que parezcas utilizar un nuevo formato de volcado de archivos cada vez que publicas :-)
Suponiendo que esté utilizando como antes (RSA-con-)AES256CBC-(HMAC)SHA1:sí, puedes descifrar cifrados TLS CBC conopenssl enc, excepto ARIA. (También RC4, aunque debe evitar el uso de RC4 para cualquier propósito, incluido TLS. OTOH encno puede realizar ningún cifrado AEAD: ni GCM ni CCM, ni ChaCha/Poly). El formato de registro en TLS1.2 (y 1.1) para un El cifrado CBC está cubierto deRFC5246 sección 6.2.3.2. Para AES, los primeros 16 octetos son el IV y el resto es el texto cifrado, que debe descifrarse en el cuerpo del registro de texto sin formato (en este caso, el mensaje terminado) más HMAC más relleno, pero el relleno TLS no es lo mismo que PKCS5/ 7 padding soportado por enc(e internamente por la EVP_{??crypt,Cipher}*API), por lo que debes hacer esa parte tú mismo.
Como se describe en su página de manual en su sistemao en la web, y bastantes preguntas sobre varias pilas (aunque la mayoría de las que he observado se refieren a hacer coincidir la línea de comandos con otro código como Java y Python, etc., no con una especificación), openssl encel valor predeterminado esbasado en contraseñacifrado (PBE), que no es lo que desea aquí. Para realizar un descifrado 'basado en claves', debe especificar -d( -Kmayúsculas, no minúsculas) con la clave en hexadecimal y -ivcon el IV en hexadecimal si lo usa el cifrado (AES-CBC lo hace):
$ 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....
Desafortunadamente, como puede ver, este descifrado no es válido: no termina con un relleno estilo TLS y no comienza con un mensaje Finalizado, que es lo que debe ser la primera transmisión posterior a CCS por parte del cliente. O su clave derivada es incorrecta o su volcado de este registro lo es.
Una sugerencia que podría ayudar: haga una conexión usando(editar) openssl s_client -debugy registrar su salida en un archivo. Esto volca todos los registros en hexadecimal (y ASCII) que puede usar como datos o para verificar las diversas entradas (incluido el registro cifrado que contiene Finalizado), Y el bloque 'SSL-Session' al final incluye el valor correcto del secreto maestro que puede utilizar como verificación cruzada. Puede agregar -msgpara volcar también los mensajes cifrados; esto es más voluminoso pero un poco más conveniente y es lo que hice a continuación. Otra posibilidad, que requiere un poco más de trabajo de configuración, es conectarse desde un programa cliente Java SSL/TLS (JSSE) ejecutado con sysprop javax.net.debug=ssly log; que arrojalotesde información incluyendo el secreto maestroyllaves de trabajo.
Como ejemplo de cómo estodeberíatrabajo, realicé el procedimiento en una sesión de muestra registrada (que de hecho creé en su primera pregunta hace unas semanas), haciendo a mano el maestro y las derivaciones de trabajo y descifrando y verificando el mensaje Finalizado del cliente:
$ 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
En cuanto a la'verifique los datos'enel mensaje terminado, sí, necesita tomar el hash de todos los mensajes de protocolo de enlace anteriores como se describe en 7.4.9 (en TLS1.3 esto se denomina hash de 'transcripción') y luego el PRF (como se analizó en publicaciones anteriores) donde está la clave. el secreto maestro y la semilla es la etiqueta fija 'cliente terminado' o 'servidor terminado' (según corresponda) más ese hash de transcripción. Eso es mucho más trabajo y no lo hice para el ejemplo, aunque probablemente pueda hacerlo si es necesario.