Bypassing HSTS e pin chiave pubblica con caratteri simili

I can see mitigations by having HSTS preloading with HSTS no_redirect, this idea of no_redirect would make the browser prevent an HTTP redirect for known HSTS websites.

Un reindirizzamento viene eseguito inviando una risposta HTTP con il codice 302 o simile e la nuova posizione all'interno dell'intestazione Location della risposta HTTP. Se un sito Web è presente nell'elenco di precarico HSTS, la richiesta per il dominio originale verrà già eseguita con HTTPS. Ciò significa che è necessario eseguire correttamente l'handshake TLS prima che la richiesta HTTP all'interno della connessione TLS possa essere inviata e che la risposta HTTP con il reindirizzamento possa essere ricevuta.

Ciò significa che per inviare il reindirizzamento, l'utente malintenzionato dovrebbe intercettare con successo la connessione TLS iniziale (ovvero l'attacco MITM) utilizzando un certificato attendibile e la sua chiave privata per il dominio che l'utente tenta di visitare. I tentativi di fare questo con un certificato autofirmato o un certificato che non corrisponde al nome host e sperare che l'utente salti qualsiasi avviso del certificato non funzionerà, poiché con HSTS non verrà offerta alcuna opzione per saltare i problemi del certificato.

Tuttavia, se l'utente malintenzionato ha già accesso a un certificato di questo tipo (magari hackerando una CA), non è necessario emettere un reindirizzamento in primo luogo, ovvero l'autore dell'attacco potrebbe continuare a offrire una risposta HTTP diversa ( con contenuti falsi) per il dominio originale, come con il reindirizzamento.

Pertanto, l'attributo no_redirect proposto per HSTS in realtà non fornisce una sicurezza aggiuntiva.