So che fino a qualche anno fa qualcuno avrebbe potuto creare un AP wireless falso e usare qualcosa come SSLStrip per attirare le vittime nella connessione a versioni non sicure dei principali siti Web, come Gmail, Facebook, ecc. avevano HSTS questo era ancora possibile. Ma ora come vedo questo non è più possibile per i principali siti web. Cosa è cambiato da prima di alcuni anni. In che modo HSTS ora impedisce questo tipo di attacchi MitM?
L'intestazione HSTS interrompe gli attacchi MitM istruendo il browser per inviare sempre la richiesta HTTPS (al contrario di HTTP) al dominio fino alla scadenza della politica. Quindi un browser che rispetta l'intestazione invierà una richiesta a https://example.com anche se l'utente ha fatto clic su un link su http://example.com .
La logica dietro HSTS non è cambiata da quando è stata definita in un RFC nel 2012. Ciò che è cambiato è che oggi quasi tutti i browser lo implementano. Ricorda che è il browser che applica questa politica! Posso utilizzare segnala i browser che lo supportano dalle seguenti versioni:
(Il modo in cui Firefox e Chrome sono riusciti a supportare HSTS prima che la RFC fosse disponibile è un mistero per me.)
Quindi le persone che utilizzano browser più vecchi di così non saranno protetti anche se l'intestazione è impostata. Questo potrebbe spiegare perché hai l'impressione che l'impostazione dell'intestazione HSTS non sia stata utilizzata per aiutare contro SSLStrip in precedenza.
Un altro motivo per cui HSTS non aiuta può essere che l'utente non abbia mai visitato la pagina prima dell'attacco. Se il browser non ha mai visto l'intestazione, non può applicarlo. Questo può essere risolto con precaricamento .
SSLStrip ha lavorato riscrivendo https richieste a% http , rimuovendo la protezione e consentendo sia l'intercettazione che le modifiche.
Un server con protezione HSTS imposterà un'intestazione su una richiesta HTTPS chiedendo al browser di contattare solo quel server usando HTTPS:
Strict-Transport-Security: max-age=31536000
In questo caso, per un anno il browser si collegherà al server solo su HTTPS e riscriverà tutti i link come HTTPS (un SSLStrip invertito).
Ma c'è un avvertimento: il client deve aver avuto accesso al server usando HTTPS almeno una volta. Se il client si connette solo tramite HTTP, MiTM può ancora verificarsi, tutte le richieste possono essere modificate e qualsiasi collegamento HTTPS o reindirizzamento può essere modificato su HTTP. Ma non appena il client accede al server utilizzando HTTPS, il cookie HSTS viene impostato e gli attacchi SSLTrip MiTM non sono più possibili.
Leggi altre domande sui tag network man-in-the-middle hsts