Hai bisogno di aiuto per decodificare lo "scambio di chiavi del client" catturato in Wireshark

1

Sto cercando di capire come avviene l'handshake SSL per HTTPS.

Ho fatto quanto segue:

  1. Catturato i pacchetti per una connessione HTTPS usando Wireshark.
  2. ha esaminato il client Hello per le suite di cipher supportate (non importante)
  3. Esaminato il server Ciao per la suite di crittografia decisa dal server. È TLS_RSA_WITH_RC4_128_MD5. Che significa L'algoritmo di handshake è RSA. il che significa che la chiave master viene crittografata utilizzando la chiave pubblica del server e inviata al server.

  4. Il prossimo messaggio Lo scambio di chiavi del cliente è il punto in cui sto affrontando la sfida. Esportato il flusso di byte crittografato "Protocollo Handshake: scambio chiavi client". Il flusso di byte in esadecimale è:

    10 00 01 00 8e 1b d9 49 6f 9e 15 8f b9 b6 8a 2e  
    e0 90 f1 54 3b 54 7d d3 d5 2e 64 b5 37 cc ae 74  
    ec 3f 38 59 1a 42 78 98 3f e1 4e 7b 8b 84 74 a9  
    17 95 c0 b7 07 d9 b1 a1 d0 1f 5a a1 2e 71 b6 98  
    ea 4b 6c 62 f3 b3 8c 8e d7 20 9a 4b 6a a7 d7 4c  
    f8 69 c9 6c d6 0b 8b d0 9f 59 28 f5 52 60 fa e9  
    72 52 4c 87 98 30 fe 6f ef a6 5b 11 fd 6b 0e 0d  
    db 60 d5 d4 d8 a6 0e 6d 9f 02 58 01 a4 21 d5 aa  
    17 80 5f 42 ec 84 78 a8 41 ed bc 94 c5 83 ab 74  
    09 b9 91 9d bf 6d c1 4b 85 95 90 d8 b4 22 fb 00  
    a4 76 af 54 e2 c3 1e 84 6f 5e 02 18 05 f5 6c 83  
    7f dc a7 44 85 24 06 b6 89 6f 13 4e 25 f0 ce 59  
    23 8c 50 4d c2 56 11 b9 0d 63 b5 28 b8 ad e7 9c  
    f2 16 96 f8 dd 4a f9 b5 72 8c 6f 6a 6c 8b 40 d7  
    03 c7 a8 d6 8e 88 38 00 d2 d3 9b 4a 04 3a 16 55  
    1f c9 58 c8 3f d3 7a 33 9a 3f 98 1c 74 83 3c 45  
    5a b2 9c da
    

    Ho rimosso i primi quattro byte (tipo e dimensioni del messaggio)

  5. Provato a decifrare la chiave del client usando la chiave privata del server usando il comando:

    openssl rsautl -decrypt -inkey /etc/apache2/ssl/apache.key -in Clientkeyexchange_enc -out Clientkeyexchange_dec
    

    Il valore esadecimale del risultato è:

    03 00 E1 B9  2F 27 4F 85   46 AF 54 CC  5D 55 5E 92
    71 CD 14 60  02 96 08 BA   8D E0 65 B7  A5 27 EF E4
    F7 4E 4A 02  55 47 80 4E   36 FF 49 75  D2 B6 AB 83
    

Non riesco a decrittografare i dati dell'applicazione utilizzando questo valore. So di aver frainteso qualcosa. Ma non riesco a scoprire cosa.

    
posta Prashanth 26.10.2014 - 05:55
fonte

1 risposta

3

Per prima cosa, prima di rispondere effettivamente, spero che tu sappia che Wireshark può fare tutto il lavoro duro per te in questo caso (sono disponibili la semplice chiave di scambio RSA e la chiave privata del server). Basta andare su Preferenze / Protocolli / SSL e dargli il file privato (chiaro) e farà i calcoli e la decrittografia chiave.

Se vuoi capire un protocollo, guarda la specifica di quel protocollo (quando disponibili e quelli di IETF) di solito è una buona idea. Nota che SSLv3 mostra la sua età, più recentemente con POODLE (vedi diverse dozzine di domande recenti), e dovresti davvero usare TLSv1.1 o migliore (anche indirizzando BEAST). Sotto ClientKeyExchange troviamo:

5.6.7.1. RSA Encrypted Premaster Secret Message 


   If RSA is being used for key agreement and authentication, the client
   generates a 48-byte premaster secret, encrypts it under the public
   key from the server's certificate or temporary RSA key from a server
   key exchange message, and sends the result in an encrypted premaster
   secret message.

        struct {
            ProtocolVersion client_version;
            opaque random[46];
        } PreMasterSecret;

   client_version:  The latest (newest) version supported by the client.
      This is used to detect version roll-back attacks.

   random:  46 securely-generated random bytes.

Quindi il tuo valore decodificato RSA è il segreto premaster ed è valido per SSLv3 anche se non lo hai detto. Per lo scambio di chiavi qualsiasi una volta stabilito il segreto premaster, lo si utilizza insieme a entrambi i valori Hello.random per derivare (calcolare) un master secret come descritto in 6.1. Asymmetric Cryptographic Computations e quindi usa il master secret con i nonces (che saranno nuovi nonce nel caso della ripresa della sessione) per derivare le chiavi di lavoro e, se applicabile, IV, plurale, come descritto in 6.2.2. Converting the Master Secret into Keys and MAC Secrets .

Nota in TLSv1 (.0) e 1.1 le funzioni di derivazione della chiave sono cambiate per mixare meglio MD5 e SHA1, il primo più chiaramente chiamato 8.1. Computing the Master Secret e il secondo spostato in avanti a 6.3. Key calculation ma entrambi condividono un PRF spostato in% codice%. Inoltre in TLSv1.2 i KDF vengono modificati per utilizzare SHA-2. Si noti inoltre che le cipheruites di "esportazione" hanno utilizzato un KDF modificato in SSLv3 e TLSv1 (.0); in 1.1 e 1.2 queste suite sono ufficialmente cancellate e il KDF modificato con esse, ma alcune implementazioni possono ancora permetterle (ma se lo fanno non dovresti usarle).

    
risposta data 26.10.2014 - 08:24
fonte

Leggi altre domande sui tag