E 'possibile iniettare informazioni in una cache della sessione TLS dei client?

0

A livello ipotetico, un utente malintenzionato può eseguire un attacco mirato su una rete che potrebbe iniettare informazioni nella cache di una vittima delle recenti connessioni TLS? In particolare, la chiave principale e il sessionID della tua sessione esistente verrebbero gestiti con un sito Web specifico che la vittima probabilmente visiterebbe in seguito.

Quando la vittima si connette al sito Web tramite https, l'intera stretta di mano verrà perdonata e il client tenterà di rinegoziare una sessione utilizzando la chiave master e sessionID immessi (e noti dall'attore). A sua volta, consente all'utente malintenzionato di intercettare tutte le seguenti comunicazioni crittografate.

È corretto o la mia comprensione dell'implementazione di TLS è errata? Certo, l'iniezione di informazioni è una montagna da scalare tutta per sé; ma sto ancora imparando molto su TLS e mi sono posto questa domanda.

    
posta theCowardlyFrench 01.09.2014 - 19:39
fonte

1 risposta

1

Una sessione memorizzata nella cache e riutilizzata con la chiave scelta per l'attacco funziona solo con / tramite l'autore dell'attacco, poiché il peer legittimo che è stato rappresentato non conoscerà questo id e chiave. Pertanto, ciò non consente l'intercettazione passiva, ma consente la rappresentazione attiva (incluso MitM) per continuare in modo più efficiente una volta avviato, così come consente alle connessioni legittime continue di essere più efficienti.

Ovviamente intercettare e simulare la connessione iniziale (con l'handshake completo) causerà la normale logica di cache del peer (se presente, vedi sotto) per memorizzare la sessione malvagia. Oltre a questa alterazione dannosa alla cache dipende dall'implementazione; non c'è alcuna operazione TLS che estrae le sessioni nella cache come DNS o ARP estraggono le voci "avvelenate" dal filo.

Hai taggato openssl e hai descritto solo l'azione del client https, sebbene la tua domanda non indichi tale limite. Se si intende client openssl, che non memorizza nella cache per impostazione predefinita. Se l'app client o l'utente specificano il contesto necessario per la memorizzazione nella cache, per impostazione predefinita openssl manterrà la cache solo in memoria, sebbene l'app possa fornire callback per fare qualcos'altro. Al contrario, il server openssl memorizza nella memoria cache per impostazione predefinita, e almeno alcuni server reali utilizzano un archivio di sessione esterno condiviso da più processi per gestire un volume client di grandi dimensioni.

Se altre implementazioni sono interessanti, fai una domanda più specifica. (Oppure, se puoi formularlo come un miglioramento di questa domanda, ti preghiamo di essere chiari sul cambiamento, in questo forum è considerato scortese in "orfano" le risposte già fornite.)

    
risposta data 02.09.2014 - 09:10
fonte

Leggi altre domande sui tag