Descriptografa o tráfego SSL com a ferramenta de linha de comando openssl - continuação parte 3

Question

De minhas perguntas / tópicos anteriores, começando parte 1 e siga parte 2 a seguir minha explicação guiada desde os meus arquivos / dados que eu estou capturando é de natureza binária eu usei os seguintes comandos openssl onde comecei com o meu segredo pré-mestre derivado de:

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

Isso criou meu arquivo secreto do servidor master de 48 bytes spre.key (acho que está correto) e em decimal para (visualizando usando a cama) como:

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 217 232 025 096 063 115 080 016 094 015 170 148 126 092 118 109 228 246 149 208 195 044 220

Hex: 0303CB303FD72FC4DDDDDD0E13480B64D9506F49D91AEA5216D9E819603F7350105E0FAA947E5C766DE4F695D0C32CDC

E concatenando o literal "segredo mestre" + client.random + server.random eu criei mseed.key e novamente visualizando com cama da mesma forma que o decimal que criei:

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 024 248 096 254 044 235 151 130 033 151 015 133 251 114 232 095 213 076 194 057 175 106 225 088 206 069 187 050 168 031 217 080 198 061 180 043
Hex: 6D617374657220736563726574ADD493D70E81E1669D1B017DA7610E554019721918F860FE2CEB978221970F85FB72E85FD54CC239AF6AE158CE45BB32A81FD950C63DB42B
para um total de 69 bytes

Em seguida, juntei isso e, como fui informado de que os dados estavam em arquivos binários, usei o seguinte para gerar o segredo principal e as chaves.

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

Isso criou 4 arquivos de 32 bytes.

seguido pela criação das chaves com:

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

Isso criou 4 arquivos de 32 bytes.

Seguindo com os exemplos que me deram e lendo o RFC como eu o entendo, a chave mestra neste momento seria os primeiros 48 bytes de a1 + a2 que estão corretos ou eu perdi alguma coisa? Desde que eu não sou realmente capaz de ver o que o PRS master_secret retorna ou está fazendo eu acho que da execução da linha de comando como acima é como eu iria obter o segredo mestre. obrigado David

    

Answer 1

Primeiro, seu arquivo mseed (o rótulo + valor inicial no PRF) deve ter 77 bytes, e não 69. Você deve ter bagunçado o cliente e / ou servidor de alguma forma.

Em segundo lugar, -hmac spre.key está muito errado. Utiliza os caracteres reais s p r e . k e y , isto é, os octetos 73 70 72 65 2e 6b 65 79 como a chave HMAC. Você precisa usar o valor do segredo pré-mestre descriptografado, que é o conteúdo do seu arquivo spre.key. E porque são dados binários que podem incluir bytes que são códigos de caracteres especiais como null, tab, dollarsign, quote, barra invertida, delete, etc., você não pode passá-lo com segurança diretamente, como -hmac {key} ou mesmo -hmac '{key}' ; em vez disso, você precisa usar -mac hmac -macopt hexkey:{hex key value} como mostrei na resposta anterior, exceto usando o valor real da chave hexadecimal que você mostrou neste Q, ou seja, 0303CB30...2CDC .

Terceiro, como mostrei na resposta anterior, você concatena os resultados da camada segundo dos HMACs, ou seja, em minha notação k1, k2, ... para formar a saída (que nesse exemplo era 100 octetos):

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

mas, como eu disse:

... for the actual TLS1.2 handshake also, adjusted for the correct lengths: 48 for the master secret, and depending on the ciphersuite for the working keys.

Para a primeira derivação (premaster-to-master) você precisa de 48 octetos, então você só precisa dos dois primeiros pedaços de 32 (a0- > a1- > a2 a1 + a0- > k1 a2 + a0- > k2) então concatene k1 + k2 e tome os primeiros 48 octetos.

Para a segunda derivação (master-to-working), o comprimento que você precisa depende do ciphersuite que foi negociado. Você disse que está usando RSA-com-AES256CBC-SHA que (em TLS1.2 ou 1.1, mas não 1.0) precisa de 40 octetos de chaves HMAC e 64 octetos de chaves de criptografia totalizando 104 octetos. Para 104 ocets, você precisa calcular 4 trechos de 32, concatenar k1 + k2 + k3 + k4 e dividi-los em cliente-MAC, servidor-MAC, criptografia de cliente, criptografia de servidor nessa ordem. Veja 6.3 do RFC. Observe também que o rótulo é diferente e, para essa derivação, a semente é (label +) server_random + client_random, não (label +) client_random + server_random como no primeiro.