Istruzione 1: non dovrebbe esserci un'intestazione per un utente malintenzionato da rimuovere dal inviarlo via HTTP è useles s. Non ho idea del motivo per cui qualcuno lo invierà su HTTP. E se l'attaccante ha certificati che il client si fida di una connessione HTTPS, allora HTTPS non infastidirà l'aggressore. Una connessione su HTTP è ancora vulnerabile, l'HSTS non lo cambierà. Passerà in modo trasparente da HTTP a HTTPS se esiste una voce HSTS valida.

Istruzione 2: di nuovo, i browser dovrebbero agire solo sulle intestazioni HSTS inviate tramite una connessione HTTPS. Se l'attaccante può inviare quell'intestazione / i non sarà infastidito da HTTPS.

In ogni caso, Difesa in profondità! Ecco perché non penso che l'HSTS sia inutile. Se aggiorni immediatamente ogni connessione HTTP a una connessione HTTPS utilizzando i reindirizzamenti, gli utenti possono essere vulnerabili molto nel corso di un anno! Confrontalo alla connessione iniziale quando usi HSTS e un browser che lo supporta!

True or False: HSTS is absolutely useless against MITM attacks

False, HSTS protegge da certe categorie di attacchi MITM ma non contro altri.

HKP (so che non l'hai chiesto a riguardo, ma sento che non ha senso guardarne uno senza guardare l'altro) protegge anche da certe categorie di attacchi MITM ma non da altri.

La combinazione di HSTS e HKP protegge da uno scenario di attacco che nessuno dei due è in grado di proteggere.

Ci sono alcuni tipi di attacchi MITM che non possono essere protetti dalla combinazione di HSTS e HKP.

Vediamo alcuni scenari. In tutti gli scenari assumerò che example.com non sia in nessun elenco di prelod del browser. Supporrò anche che il collegamento reindirizzasse al link

Scenario 1:

Il cliente visita il link e non ha visitato example.com prima che il MITM si sia creato.

In questo scenario il MITM avrà successo. Può semplicemente intercettare la connessione iniziale e impedire il reindirizzamento a https.

Scenario 2:

Il cliente visita il link . L'utente malintenzionato non possiede un certificato che superi la normale convalida dei certificati del browser.

In questo scenario la connessione https fallirà la convalida del certificato e il MITM fallirà. HSTS e HKP non sono necessari.

Scenario 3:

Il cliente visita il link e ha visitato example.com prima che il MITM si sia creato. L'utente malintenzionato non possiede un certificato che superi la normale convalida dei certificati del browser.

In questo scenario senza HSTS il MITM avrà successo. Può semplicemente intercettare la connessione iniziale e impedire il reindirizzamento a https.

Con HSTS il browser non tenterà mai di creare una semplice connessione http, ma passerà direttamente a https. La connessione https fallirà la convalida del certificato e il MITM fallirà.

Scenario 4:

Il cliente visita il link e non ha visitato example.com prima che il MITM si sia creato. L'autore dell'attacco ha ottenuto un certificato coverting example.com da una CA nell'elenco delle directory attendibili di default dei browser (tramite l'inganno, la corruzione, il bullismo o qualsiasi altra cosa)

In questo scenario l'autore dell'attacco ha successo.

Scenario 5:

Il cliente visita il link e ha visitato example.com prima che il MITM si sia creato. L'autore dell'attacco ha ottenuto un certificato coverting example.com da una CA nell'elenco di credenziali attendibili predefinito dei browser.

In questo scenario senza HKP l'aggressore ha successo. Con HKP la convalida del certificato fallisce.

Scenario 6:

Il cliente visita il link e ha visitato example.com prima che il MITM si sia creato. L'autore dell'attacco ha ottenuto un certificato coverting example.com da una CA nell'elenco di credenziali attendibili predefinito dei browser.

In questo scenario senza HSTS il MITM avrà successo. Può semplicemente intercettare la connessione iniziale e impedire il reindirizzamento a https.

In questo scenario senza HKP il MITM avrà successo. Può MITM con successo la connessione https.

Sia con HSTS che con HKP il browser non tenterà mai di creare una semplice connessione http, ma passerà direttamente a https. La connessione https fallirà la convalida del certificato grazie a HKP e il MITM fallirà.

Scenario 7:

Il MITM ha ottenuto la chiave privata per (uno dei) certificati legittimi del sito

Il MITM avrà successo

Scenario 8:

Il MITM ha ottenuto un certificato per exampe.com da una CA che è stata aggiunta manualmente all'elenco delle credenziali attendibili.

HKP viene bypassato e il MITM avrà successo. (questo consente ai firewall aziendali che ispezionano https di continuare a lavorare, se questa è una cosa buona o meno è discutibile).

Un altro modo in cui HSTS potrebbe essere compromessa potrebbe essere se sul computer che stavi connettendo fosse installata una CA radice che consentiva a un utente malintenzionato MITM di apparire come il sito Web originale.

es. se si utilizza un computer aziendale per connettersi a Gmail, la società potrebbe intercettare il traffico nel modo seguente:

• I computer aziendali hanno una CA radice personalizzata installata
• La CA radice personalizzata viene utilizzata per firmare un certificato "cattivo" per Google
• Il tuo computer si connette a un dispositivo intermedio (ad esempio un firewall) utilizzando questo certificato "cattivo"
• La comunicazione viene decrittografata, quindi ri-crittografata utilizzando il certificato originale per Google.

Vedi questa domanda In che modo il mio datore di lavoro può essere un vero maniaco quando mi collego a Gmail?

Per rispondere all'originale, ampia domanda "L'HSTS è inutile contro MitM", la risposta è a volte. Come altri hanno risposto, l'HSTS non è ostentato dalle due affermazioni che hai fatto. Tuttavia, esistono diversi modi per interrompere l'HST e non hanno nulla a che fare con HSTS, TLS o certificati.

L'HSTS è un passo importante nella giusta direzione per la sicurezza HTTP, ma sfortunatamente, altri componenti critici non sono ancora stati raggiunti. Il DNS è uno dei principali modi per rompere, o meglio, sovvertire HSTS. Se un utente malintenzionato è MitM su una rete, significa che ha la capacità di falsificare le risposte DNS. Supponiamo che ci sia un client sulla rete che desidera connettersi a "accounts.google.com". Il browser del client sa che questo host utilizza HSTS e che deve connettersi solo tramite HTTPS. Tuttavia, l'autore dell'attacco sta effettuando lo spoofing del DNS e ha aggiunto una voce CNAME in modo tale che una ricerca DNS per "accounts.google.com" risolva in "accounts.google.con" (o qualsiasi altro nome simile), che a sua volta si risolve in un indirizzo sotto il controllo dell'attaccante (forse un sito web clonato o un proxy inverso). Il browser carica "accounts.google.con" su un semplice HTTP e l'utente probabilmente non se ne accorge. Ora, l'utente malintenzionato può raccogliere credenziali o eseguire altri attacchi MitM con facilità.

In breve, HSTS protegge da tutto ciò che è progettato per proteggere, ma la mancanza di integrità nel DNS può sovvertirlo. Cose come DNSSEC e DANE sono il pezzo mancante di questo puzzle, ma sono ancora a pochi anni dall'adozione diffusa.