Come visualizzare la chiave crittografata in wireshark, durante lo scambio di chiavi ssl?

In wireshark, sono in grado di vedere i dati crittografati avanti e indietro dal mio PC. Non usa diffie hellman algorihm per lo scambio di chiavi perché vedo solo il pacchetto Client Key Exchange ma non esiste un pacchetto Server Key Exchange . Ciò significa che il browser sta inviando la chiave crittografata al server (crittografata utilizzando la chiave pubblica del server).
Ma non vedo alcun dato crittografato in quel pacchetto (“Scambio chiavi client”). Come visualizzare la chiave crittografata?

Fino a poco tempo fa la dissezione di ClientKeyExchange era così (versione 1.6 e seguenti):

 TLSv1 Record Layer: Handshake Protocol: Client Key Exchange Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 134 Handshake Protocol: Client Key Exchange Handshake Type: Client Key Exchange (16) Length: 130 

Ma se usi questa versione (1.7.2 verso l’alto) la dissezione chiave sarà così:

 TLSv1 Record Layer: Handshake Protocol: Client Key Exchange Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 134 Handshake Protocol: Client Key Exchange Handshake Type: Client Key Exchange (16) Length: 130 RSA Encrypted PreMaster Secret Encrypted PreMaster length: 128 Encrypted PreMaster: 761b1beac35e59de9a3bb9f74ebf9109b738e8ad346 

Puoi vedere il pre-master criptato 🙂

Non vedrai la chiave condivisa crittografata, non sarà scambiata. È ansible visualizzare il segreto pre-master crittografato quando si utilizza lo scambio di chiavi autenticate con RSA . (Si noti che l’utilizzo di Ephemeral Diffie-Hellman non è l’unica ragione per non vedere un messaggio di scambio di chiavi del server: potrebbe anche utilizzare una suite di crittografia DH_DSS o DH_RSA , ma ciò è insolito per quanto ne so).

Se si seguono le istruzioni sulla decrittografia di SSL con Wireshark , utilizzare l’opzione “SSL debug file” per archiviare i log in un file. (Si noti che l’interfaccia utente è leggermente cambiata nelle versioni più recenti di Wireshark, nel modo in cui si configura la chiave privata.)

I file di registro conterranno il segreto pre-master e le chiavi condivise.

(A proposito, è necessaria la chiave privata del server per farlo, ovviamente).

Utilizzando i dati di esempio forniti nella pagina Wireshark, ottieni:

 pre master encrypted[128]: 65 51 2d a6 d4 a7 38 df ac 79 1f 0b d9 b2 61 7d 73 88 32 d9 f2 62 3a 8b 11 04 75 ca 42 ff 4e d9 cc b9 fa 86 f3 16 2f 09 73 51 66 aa 29 cd 80 61 0f e8 13 ce 5b 8e 0a 23 f8 91 5e 5f 54 70 80 8e 7b 28 ef b6 69 b2 59 85 74 98 e2 7e d8 cc 76 80 e1 b6 45 4d c7 cd 84 ce b4 52 79 74 cd e6 d7 d1 9c ad ef 63 6c 0f f7 05 e4 4d 1a d3 cb 9c d2 51 b5 61 cb ff 7c ee c7 bc 5e 15 a3 f2 52 0f bb 32 pre master secret[48]: 03 00 ff 84 56 6d a0 fb cc fd c6 c8 20 d5 f0 65 18 87 b0 44 45 9c e3 92 f0 4d 32 cd 41 85 10 24 cb 7a b3 01 36 3d 93 27 12 a4 7e 00 29 96 59 d8 master secret[48]: 1e db 35 95 b8 18 b3 52 58 f3 07 3f e6 af 8a a6 ab c3 a4 ed 66 3a 46 86 b6 e5 49 2a 7c f7 8c c2 ac 22 bb 13 15 0f d8 62 a2 39 23 7b c2 ff 28 fb key expansion[136]: 11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7 b3 f7 33 aa b2 42 d0 1c a6 4e fb e9 9b 13 dd 29 63 aa 17 1f 47 71 95 71 08 e0 4b 8e e1 da 7b 4a 5a f3 c2 32 bd e0 a5 82 6d 14 44 3a d6 cb 2d c0 7d 57 be a8 37 de 5d d9 a1 07 fd 1b 22 71 b9 4b 7a 1e 0f 70 37 14 97 0a f0 db 98 3b 7b 74 e3 2d 51 66 2e 31 68 90 ac 6f e6 53 3c c9 5e 48 0c 05 bc 9f 92 e7 f9 91 98 f5 95 1c c4 bf d9 cb 26 ef 35 70 5e ad 21 22 3e f6 Client MAC key[20]: 11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7 b3 f7 33 aa Server MAC key[20]: b2 42 d0 1c a6 4e fb e9 9b 13 dd 29 63 aa 17 1f 47 71 95 71 Client Write key[32]: 08 e0 4b 8e e1 da 7b 4a 5a f3 c2 32 bd e0 a5 82 6d 14 44 3a d6 cb 2d c0 7d 57 be a8 37 de 5d d9 Server Write key[32]: a1 07 fd 1b 22 71 b9 4b 7a 1e 0f 70 37 14 97 0a f0 db 98 3b 7b 74 e3 2d 51 66 2e 31 68 90 ac 6f Client Write IV[16]: e6 53 3c c9 5e 48 0c 05 bc 9f 92 e7 f9 91 98 f5 Server Write IV[16]: 95 1c c4 bf d9 cb 26 ef 35 70 5e ad 21 22 3e f6 

Impressionante scrivere qui spiegando come funziona SSL, notare in nessun momento durante questa stretta di mano è la chiave privata mai inviata sul filo.

http://4orensics.wordpress.com/2011/10/21/ssl-in-a-nutshell/

Per farla breve non c’è modo di decrittografare i flussi SSL senza la chiave privata del server (a meno che non si lavori per la NSA o qualcosa del genere), tuttavia si consiglia di entrare tra il server e il client durante l’handshake e se l’utente non controlla la validità del certificato che ti viene presentato.

Ecco uno strumento che può farlo per te tra molti altri

http://mitmproxy.org/

Di certo consiglio vivamente l’articolo di sans reading room sugli attacchi SSL Mitm (Man in the Middle).