Sniffing TLS / SSL tramite HSTS?

0

Immagina quanto segue:

Il cliente C vuole comunicare con il server S. L'attaccante malvagio A è il Man-In-The-Middle.

C invia una richiesta a S, A la intercetta. A crea un certificato autofirmato con il nome di dominio di S e invia il certificato a C, mentre spoofing l'IP di origine sull'IP di S.

C e A eseguono l'handshake (C pensa che A sia S), A può decifrare richieste formate da A e le inoltra a S (tramite HTTP o HTTPS). Le risposte di S vengono considerate al contrario.

C vede l'avviso che il certificato è autofirmato, ma a chi importa davvero?

Poiché la connessione tra C e A avviene tramite SSL, l'HSTS non dovrebbe essere un problema.

È possibile? O mi sto perdendo qualcosa?

    
posta Heisenberg 10.06.2015 - 13:32
fonte

2 risposte

2

Una volta che il browser di C ha stabilito che S è un host HSTS conosciuto (tramite il suo elenco di precaricamento o avendo precedentemente ricevuto un'intestazione Strict-Transport-Security valida), i certificati autofirmati e problemi di sicurezza simili producono errori che l'utente può semplicemente facendo clic.

link

Quindi la risposta alla tua domanda "a chi importa davvero?" è "il browser".

Ovviamente, questo attacco potrebbe riuscire se C non ha ancora stabilito che S usi HSTS - cioè, se questo è il primo tentativo di C di connettersi a S, e S non è nell'elenco di precaricamento del browser.

    
risposta data 10.06.2015 - 14:00
fonte
1

"Nessun ricorso"

RFC 6797, sezione 12.1 afferma che l'utente NON DEVE essere presentato con un "clic qui per ignora e continua "dialog.

Questa è una clausola "DOVREBBE" e non una clausola "DEVE". Parlare in RFC significa che sei libero di ignorarlo. Ma ha esortato a non.

Quindi, se il tuo browser onora le raccomandazioni della RFC, non sarai in grado di ignorarlo.

E se il tuo browser ti consente di ignorare l'errore, puoi procedere e sniffare.

    
risposta data 10.06.2015 - 14:07
fonte

Leggi altre domande sui tag