Sniffing di un pacchetto HTTPS in uscita - solo intercettato da un determinato software, non può decifrare

Naviga le tue risposte
0

Sto cercando di annusare un pacchetto in uscita crittografato con SSL. Viene inviato dal gioco Mass Effect 3 a un servizio web EA.

Quando annisco i pacchetti con Nirsoft SocketSniff, posso vedere il pacchetto (identificato positivamente dal momento in cui appare in SocketSniff): 

Socket      Index  Type  Local Address  Local Port  Remote Address  Remote Port  Send Calls  Receive Calls  Sent Received  Closed
0x00000CBC  24     TCP   192.168.0.111  49191       94.236.58.180   443          5           492            661  1,753     Yes

Posso quindi fare clic su questa riga per visualizzare le dump esadecimali di tutte le comunicazioni (in entrambe le direzioni) sul socket pertinente. Vi sono 5 pacchetti inviati e 12 pacchetti ricevuti, uno dei quali è un certificato parzialmente leggibile di Electronic Arts in ingresso sul mio PC.

Posso anche vedere la comunicazione in modo più dettagliato in Wireshark, che mostra questo:

Quando faccio clic sulla riga Dati applicazioni, posso vedere il testo cifrato esadecimale. Tuttavia, voglio visualizzare il testo in chiaro, quindi ho bisogno di utilizzare un proxy HTTPS.

Ho provato per la prima volta Charles, che ho configurato e utilizzato con successo per decrittografare alcuni dati HTTPS da e verso un sito Web, nonché alcuni tipi di traffico HTTPS da Mass Effect 3. Tuttavia, il pacchetto sopra descritto non viene visualizzato in Charles. Ho anche provato Fiddler 4, che ho usato analogamente per decodificare con successo il traffico HTTPS, ma il pacchetto non compare neanche in Fiddler.

Quindi, tra i 4 software che ho usato, 2 di essi possono prelevare il pacchetto, ma non decrittografarlo, e 2 di loro possono decodificare il traffico HTTPS, ma non possono raccogliere questo particolare pacchetto.

Qualche idea su cosa potrei fare male o cosa posso provare dopo? Posso fornire ulteriori informazioni se necessario.

    
posta halbrd 18.07.2018 - 12:58
fonte

1 risposta

1

L'utilizzo di un proxy HTTPS si basa sul fatto che è possibile utilizzare la connessione MIM utilizzando un certificato autofirmato. È possibile creare un certificato per "* .ea.com" emesso dalla propria CA e comunicare al proxy HTTPS di inviarlo al gioco, nel caso in cui cerchi di stabilire una connessione in uscita.

Questa è la normale procedura:

  1. Il gioco vuole contattare ea.com
  2. Esegue un handshake TLS con ea.com
  3. Riceve un certificato che dice "questa chiave pubblica appartiene a ea.com"
  4. Il gioco determina se il certificato è autentico e attendibile
  5. Se no, termina la connessione, altrimenti invia dati crittografati che possono essere decifrati solo dal proprietario della chiave privata

Non appena il gioco crittografa i dati, non puoi decodificarlo, anche se usi Wireshark. L'utilizzo di un proxy che interrompe HTTPS esegue questa operazione:

  1. Il gioco vuole contattare ea.com
  2. Cerca di eseguire l'handshake TLS con ea.com
  3. Il proxy HTTPS stabilisce invece la connessione a ea.com stesso
  4. Il proxy HTTPS fornisce al certificato autofirmato (che TU hai la chiave privata) per il gioco
    1. Tutto il traffico viene ora decrittografato e crittografato nuovamente nel proxy HTTPS utilizzando il certificato autofirmato
  5. Il gioco determina se il certificato è autentico e attendibile
  6. Se no, interrompi la connessione, altrimenti invia dati crittografati che possono essere decodificati solo dal proprietario della chiave privata ( che in questo caso sei )

Il passaggio 5 è problematico. Un proxy HTTPS funziona solo se il gioco si basa sul sistema operativo per determinare l'autenticità di un certificato. In questo caso, puoi installare localmente il tuo cert autofirmato e il sistema operativo dice felicemente al gioco "sì, va tutto bene". Se il gioco fa una sorta di tecnica di fissaggio dei certificati HSTS e del certificato per evitare falsi certificati e insistere su un originale su (o addirittura memorizza l'unico certificato (root) accettato localmente nel suo codice), non si può ingannare accettando un certificato firmato (senza intaccare il codice stesso del gioco).

Suppongo che questo sia il motivo per cui il tuo proxy HTTPS non riesce a sostituire il certificato originale con uno falso. Il tuo proxy non lo raccoglie, in quanto non può rivelare il testo normale o raccoglierlo senza poterlo decifrare.

    
risposta data 18.07.2018 - 13:52
fonte

Leggi altre domande sui tag

In che modo DTLS sostituisce la crittografia di trasporto di TLS? [duplicare] La presenza del token XSRF e del cookie di sessione per richiesta riduce il rischio di sicurezza delle credenziali di accesso brute-forcing? [duplicare]