Decrypt TLS dati traffico HTTPS

Question

ho implementato un pacchetto di rete Java sniffer simile a quello proposto da http://www.freeproject.co.in/source/Network-Packet-Sniffer.aspx?pf=Java&t=web o http://packetsnifferusingjpcap.blogspot.it/

Ora vorrei per decodificare il flusso di dati proveniente da una https, nel tentativo di farlo ho impostato la variabile SSLKEYLOGFILE, in questo modo il browser scriverà i valori utilizzati per generare chiavi di sessione TLS in un file indicato da questa variabile vedere https://isc.sans.edu/forums/diary/Psst+Your+Browser+Knows+All+Your+Secrets/16415/

Come si è spiegato in https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format

Il file indicato da SSLKEYLOGFILE è una serie di linee. Le righe di commento iniziano con un carattere nitido ('#'). Altrimenti la linea prende uno di questi formati.

RSA <space> <16 bytes of hex encoded encrypted pre master secret> <space> <96 bytes of hex encoded pre master secret> 

CLIENT_RANDOM <space> <64 bytes of hex encoded client_random> <space> <96 bytes of hex encoded master secret> 

Come posso utilizzare il protocollo SSL/TLS segreti file di log-in per decodificare i pacchetti di rete in un codice Java?

Answer 1

Dato che wireshark implementa già tutta la logica necessaria, è possibile eseguire il piping dei dati acquisiti tramite tshark e analizzare il testo di output nell'applicazione.

È forse potrebbe anche fare da soli con l'aiuto di una libreria crittografica come bouncycastle, ma sarebbe un grande sforzo, perché si sarebbe ancora dovuto analizzare la stretta di mano e tutto (Lo SSLKEYLOGFILE contiene solo il veramente bit segreti, un sacco di contesto è ancora necessario per decifrare il traffico con successo!).

Answer 2

Per rispondere alla domanda specifica, è necessario creare un client TLS. Sono disponibili numerose librerie Java TLS valide, ma è possibile provare l'estensione JSSE (Java Secure Socket Extension) JRE in bundle prima di provare gli strumenti di terze parti. JSSE ha una buona integrazione con il resto degli strumenti di crittografia Java. Per iniziare, è possibile utilizzare these JSSE samples.

Se le API per l'attuazione JSSE predefinita non soddisfa le tue esigenze, dare un'occhiata a questi due buoni open-source TLS librerie per Java:

• The Legion's Bouncy Castle
• Amazon's s2n

Una volta decodificati i pacchetti, è comunque necessario gestire il traffico HTTP. Per farlo è possibile restituire i pacchetti al browser o ad un'altra libreria client HTTP.

Nota 1: i segreti effimeri creati durante l'handshake TLS sono validi solo per la sessione TLS specifica. La raccolta di questi segreti effimeri non ti consente di creare un proxy generale, come Mallory would want to mount a generic man-in-the-middle attack ma, tuttavia, ti dà accesso alle informazioni crittografate TLS, quindi se Alice sta effettuando l'accesso alla sua banca, il nome utente e la password di Alice faranno parte del Dati crittografati TLS ora disponibili. Questo è uno dei motivi, gli schemi di username-password hanno caratteristiche di sicurezza scarse anche se Alice crea una password "forte".

Nota 2: in TLS, Alice deve fiducia suo cliente TLS, vale a dire, quando Alice utilizza terminale per l'accesso, Alice è confidando che il suo browser è la versione di Google di Chrome, non Chuck's or Malloy's versione di Chromium.

Nota 3: in TLS, Alice deve fiducia che solo Bob ha accesso alla chiave privata di Bob, quando lei si collega al server di Bob. Se Chuck cattura la chiave privata di Bob, allora Chuck può delegare il sito di Bob senza che Alice se ne accorga (e, purtroppo, spesso Bob richiede un tempo a) - sfortunatamente, ci sono un certo numero di debolezze operative IT che rendono questo particolare scenario relativamente facile ma non è un attacco tecnico su TLS stesso.

Nota 4: Mallory potrebbe utilizzare il Key Compromise Impersonation attack come un man-in-the-middle tecnico generale su TLS, se il cliente è vulnerabile e il server obbliga; KCI è per lo più mitigato a questo punto.

Answer 3

È possibile utilizzare Charles Proxy (30 giorni liberi), è scritto in Java, consente l'ispezione del traffico https non crittografato ed è molto più amichevole di WireShark. Ma Charles Proxy gestisce solo http/https, wireshark è più generale.