Domanda:
Qual è la differenza tra l'utilizzo di HSTS e l'esecuzione di un reindirizzamento 301?
Franzech Domâs
2016-07-06 03:12:36 UTC
view on stackexchange narkive permalink

Se ho già eseguito un reindirizzamento 301 da tutte le pagine interne HTTP a HTTPS, perché dovrei usare anche HSTS?

Sei risposte:
#1
+64
Anders
2016-07-06 03:43:06 UTC
view on stackexchange narkive permalink

Diamo prima un'occhiata allo scenario con un reindirizzamento 301. La vittima invia una richiesta a http://example.com (come sottolineato nei commenti, ciò potrebbe essere dovuto a SSLStrip o perché l'utente ha appena inserito example.com nel La barra degli URL e i browser sono impostati su HTTP per impostazione predefinita) In assenza di attacchi MitM, ricevono una risposta 301 e vengono reindirizzati a https://example.com . Ma se esiste un MitM, l'attaccante può semplicemente scegliere di non inviare il 301, ma invece di servire una copia (eventualmente modificata) del sito su HTTP.

Il punto debole qui è che una connessione HTTP iniziale (senza TLS) e l'attaccante può modificare quel traffico. Tuttavia, se avessi utilizzato HSTS, il browser avrebbe saputo (supponendo che la vittima avesse visitato il sito in precedenza) che la pagina dovrebbe essere sempre servita su HTTPS: nessuna richiesta HTTP sarebbe mai stata inviata e il browser avrebbe semplicemente inviato una richiesta a https://example.com . L'aggressore non può MitM la connessione TLS, quindi l'attacco viene prevenuto.

(Il fatto che i browser memorizzino nella cache le risposte 301 rende questo un po 'più complicato nella pratica. Per maggiori informazioni, vedi bonsaiviking's great rispondi o questa domanda. Il racconto è che il 301 che viene memorizzato nella cache potrebbe aiutare un po ', ma non portarti fino in fondo come fa HSTS.

Vale la pena ricordare che `sslstrip` aiuta a sfruttare esattamente questo tipo di attacchi.
I browser più diffusi (almeno [Firefox] (https://blog.mozilla.org/security/2012/11/01/preloading-hsts/) e Chrome) hanno precaricato gli elenchi di host HSTS almeno dal 2012, quindi è necessariovisitare prima la pagina dovrebbe essere necessaria solo sui nuovi siti (e quell'unico sito che blocca tutta l'indicizzazione).
@l0b0 Sei precaricato solo se (a) imposti il flag di precaricamento e (b) richiedilo.Una minoranza di siti HSTS è precaricata, quindi per la maggior parte dei siti è necessario visitarla.
Ciò che distingue maggiormente 301 da HSTS è proprio il precarico.Con esso, non è necessaria una prima connessione insicura.Senza di essa, entrambi sono ugualmente vulnerabili a sslstrip (HSTS necessita di un sslstrip più "personalizzato", ma è comunque possibile).Anche l'eliminazione della cache può essere un fattore (forse 301 viene dimenticato ma HSTS no?)
@ValmikyArquissandas Non sono d'accordo.La maggior parte dei siti HSTS non utilizza il precaricamento e ottiene comunque un vantaggio significativo.A differenza dei post HSTS, non è garantito che un 301 venga memorizzato nella cache per un periodo di tempo prolungato, copre solo una pagina specifica e non un dominio completo e viene perso se l'utente elimina la cache.
Per riformulare @SandeepY:, l'attacco MitM più semplice che può essere eseguito è fingere che il sito Web non supporti HTTPS e mantenere attiva la sessione non crittografata
@Anders: hai ovviamente ragione e la mia risposta è sbagliata.Non so come ho dimenticato che 301 agisce solo su una singola pagina e non sul dominio - devo averli mescolati.
Il precaricamento è un'operazione primitiva.È necessario precaricare per un anno o più ed "essere consapevoli del fatto che l'inclusione nell'elenco di precaricamento non può essere facilmente annullata", secondo lo strumento di registrazione.Pertanto, se c'è QUALSIASI possibilità di errore, è prudente NON precaricare, almeno per un po '.Durante questo periodo il tuo sito web è aperto agli attacchi MiTM da ogni prima richiesta di ogni visitatore (per trovare l'intestazione HSTS).Il problema è che il reindirizzamento attiva un nuovo accesso completo.Poiché non esiste un flag di zona DNS per dire che https è supportato, non esiste una buona soluzione.HSTS fallisce.
@DavidSpector Ti sbagli, come ti è stato fatto notare sia nella tua risposta (errata) a questa domanda che nell'altra tua domanda.
#2
+46
bonsaiviking
2016-07-06 05:05:30 UTC
view on stackexchange narkive permalink

HTTP Strict Transport Security (HSTS) è progettato per la sicurezza. HTTP 301 spostato in modo permanente viene utilizzato per il reindirizzamento URL.

Il reindirizzamento 301 è una parte importante della distribuzione di un sito Web HTTPS. Come parte del protocollo HTTP, è supportato da più browser rispetto a HSTS. Serve come mezzo principale per aggiornare una connessione in chiaro a HTTPS, aggiornare gli indici di ricerca ed evitare la decomposizione dei link.

In molti casi, questi due metodi hanno lo stesso punto debole: la richiesta iniziale quando l'utente digita "esempio.com" nel browser viene inviato in chiaro. Se la richiesta iniziale viene effettuata su una rete ostile con un man-in-the-middle (MITM) attivo, la risposta può essere intercettata e la connessione non verrà aggiornata a una rete sicura.

Tuttavia, ci sono molte ragioni per cui HSTS è importante e un grande miglioramento della sicurezza rispetto a un reindirizzamento 301 standard:

  • HSTS copre l'intero dominio. Un reindirizzamento 301 copre solo un URI specifico sentiero. Se un utente viene reindirizzato per example.com/ , una richiesta successiva a example.com/somepage utilizzerà inizialmente HTTP e dovrà essere reindirizzato nuovamente. Un sito che utilizza HSTS richiede una sola richiesta per coprire l'intero sito.
  • HSTS funziona anche con una connessione HTTPS iniziale. Un reindirizzamento 301 associa solo un URI di testo normale a uno HTTPS, quindi visitare direttamente l'HTTPS non conferisce alcuna protezione alle visite successive.
  • HSTS utilizza una cache separata con un timeout separato. La cache 301 è spesso collegata alla cache delle richieste del browser, progettata per le prestazioni. Se non visiti una pagina per un po ', probabilmente verrà cancellata dalla cache per favorire i siti visitati più di frequente. Potrebbe anche esserci un'età massima per questa cache di poche settimane o mesi. Una soluzione comune per "il sito non funziona" è dire all'utente "svuota la cache". Tutto ciò esporrebbe nuovamente l'utente alla minaccia MITM. I timeout di HSTS sono generalmente dell'ordine di mesi o anni e la cache è solitamente separata, quindi non può essere cancellata facilmente o accidentalmente.
  • HSTS può essere precaricato in un browser dal produttore. Google lo fa con il proprio browser Chrome in base alle intestazioni scoperte durante la scansione del Web e inviate direttamente al proprio programma. Per i siti precaricati, il browser non dovrà mai essere visitato tramite testo in chiaro in primo luogo; si può sempre presumere che sia solo HTTPS.
Una "cache separata" che deve ancora essere eliminata quando l'utente richiede l'anonimato, quindi è ancora una soluzione supportata a metà
#3
+12
CBHacking
2016-07-06 09:29:10 UTC
view on stackexchange narkive permalink

Prima di tutto, alcuni vecchi browser non supportano HSTS, quindi è ancora necessario reindirizzare HTTP a HTTPS, impostare il flag secure su tutti i cookie, ecc. Ora, detto questo .. .

Oltre ai buoni motivi sopra elencati, poiché sconfiggere gli attacchi di tipo SSLStrip è uno degli scopi principali di HSTS, esiste un altro attacco da cui HSTS protegge ma i semplici reindirizzamenti no.

Supponiamo che un sito venga visitato interamente su HTTPS. L'utente è molto attento e richiede questo sito solo tramite HTTPS. Nessun reindirizzamento necessario. Non c'è HSTS, ma non ci sono nemmeno collegamenti al sito su HTTP non protetto, quindi tutto il traffico con il sito è crittografato.

Tuttavia, supponiamo che il sito abbia una vulnerabilità di sicurezza in cui riflette un cookie specifico (se present) nella pagina senza un corretto escape (XSS basato su cookie, raro ma difficilmente inaudito). L'autore dell'attacco non può effettivamente leggere (tanto meno modificare) il traffico HTTPS, ma desidera davvero accedere alla sessione dell'utente su quel sito HTTPS. Quindi, aspettano che l'utente visiti un altro sito su HTTP e modifichi la risposta da quel sito per includere una richiesta invisibile (forse uno script src) a http: // securesite. com / (il tuo sito solo HTTPS, ma su HTTP invece). Cosa succede dopo:

  • Se il sito ha un criterio HSTS attivo nel browser, il browser riscrive automaticamente la richiesta come https://securesite.com/ e l'aggressore non può leggere o modificare il traffico.
  • Se l'aggressore non manomette ma il sito non ha HSTS, la richiesta esce, ottiene un 301 a https: / /securesite.com/ e la richiesta viene nuovamente inviata tramite HTTPS.
    • Tuttavia, tutti i cookie per securesite.com ma senza il flag secure verranno inclusi con quella richiesta iniziale non sicura. L'aggressore può leggerli anche solo tramite intercettazioni passive a quel punto. Non va bene (e questo è un motivo per cui i cookie sensibili devono sempre avere il flag secure anche se il sito non dovrebbe essere mai accessibile tramite una connessione non sicura).
  • Se tutti i cookie sono sicuri , però, questo rende inutile questo attacco. L'aggressore dovrà manomettere di nuovo. Possono falsificare o modificare la risposta alla richiesta insicura. In questo caso particolare, l'attaccante aggiungerebbe un'intestazione Set-Cookie alla risposta, inserendo un cookie nel browser dell'utente che verrà inviato su richieste future a securesite.com, tramite HTTP o HTTPS.

Con l'ipotizzato vettore XSS basato su cookie (o qualsiasi altra cosa in cui un attacco di impianto di cookie può arrecare danno), l'aggressore ha attaccato con successo un sito a cui l'utente è stato molto attento per accedere solo tramite HTTPS , solo perché non utilizzava HSTS e aveva una vulnerabilità che sarebbe stato impossibile sfruttare senza una connessione non protetta.

Per quanto riguarda i vecchi browser.È controverso se un * sito * necessita o meno di un 301. Immagino che alla fine sia piuttosto gli * utenti * che sono responsabili di digitare il prefisso `https:` se insistono nell'usare un browser non supportato.È una decisione aziendale se si vuole sacrificare un po 'di sicurezza e confortare quella base di utenti.
Aspetta, come e dove è controverso?** Se usi HSTS, devi * assolutamente * includere anche il reindirizzamento 3xx! ** Non puoi nemmeno inviare un'intestazione HSTS su HTTP (almeno, nessun client conforme lo rispetterà, con una buona ragione), népuoi precaricare HSTS se rispondi su HTTP con qualsiasi cosa tranne un reindirizzamento.Ovunque l'intera domanda sia anche leggermente rilevante, l'uso del reindirizzamento è obbligatorio.
Il reindirizzamento non è realmente necessario per i nuovi browser, ma consigliato per semplicità e per i browser che non supportano HSTS.Tutto ciò che serve per abilitare HSTS è una singola risorsa caricata su HTTPS che include l'intestazione.Potrebbe essere semplice come un riferimento URL assoluto (ad esempio "").
@SilverlightFox: In questo modo la pagina principale verrà comunque caricata su HTTP su quella richiesta iniziale, il che potrebbe rivelare alcuni contenuti dell'utente e causare anche una cattiva esperienza utente (possibilmente facendo pensare all'utente che il sito funzioni completamente su HTTP).Inoltre renderà il tuo sito non idoneo per l'elenco di precaricamento HSTS (requisito n.2 su https://hstspreload.appspot.com/)
#4
+7
SilverlightFox
2016-07-06 21:10:52 UTC
view on stackexchange narkive permalink

La cosa fondamentale da notare è che la politica della stessa origine per i cookie è più permissiva rispetto alla politica della stessa origine altrove. Cioè, non esiste un unico canale sicuro per i cookie, hanno la stessa origine:

  Client ---- Plain HTTP ---- > ServerClient -------- -HTTPS ---- Server >  

Ovviamente il flag di sicurezza può essere impostato in modo che il valore di un cookie possa essere impostato per il trasferimento solo su HTTPS.

eg

Set-Cookie: foo = bar; sicuro

  Client --> HTTP (nessun cookie) --> ServerClient --> HTTPS (Cookie: foo = bar) --> Server  

Tuttavia, il server non ha modo di sapere se un cookie è stato impostato con il flag di sicurezza.

ad es. su HTTP semplice

Set-Cookie: foo = bar

  Client --> HTTPS (Cookie: foo = bar) --> Server 

Il server si troverà in questa situazione:

Fry

Quindi anche se i cookie impostati dal server su HTTPS non sono intercettabili, un MITM può iniettare i propri valori in una sessione "sicura". Ciò è vero anche se non si dispone di un semplice servizio HTTP:

  Client ---- Plain HTTP ---- > Nessun servizio Client --------- HTTPS ---- > Server  

... perché un MITM può ancora generare una semplice richiesta HTTP al tuo dominio e iniettare il cookie:

  Client ---- Plain HTTP ---- > MITM --> No serviceClient --------- HTTPS ------------- > Server  

Questo può portare ad alcuni attacchi se il tuo sito ha alcune vulnerabilità che altrimenti non potrebbero essere sfruttate:

anche come sopra, gli attacchi in stile ssltrip possono essere eseguiti senza HSTS. sslstrip si basa in una certa misura sul fatto che l'utente non si accorga che il suo non è HTTPS.

Vedi anche questa risposta.

#5
-1
dhaupin
2016-07-06 20:04:02 UTC
view on stackexchange narkive permalink

HSTS utilizza un reindirizzamento 307 lato client in modalità sandbox, quindi non raggiunge nemmeno il server finché non è in modalità https esplicita. Un reindirizzamento 301 d'altra parte è lato server, richiede risorse, tempo per il completamento, ecc. Inoltre, un reindirizzamento 301 aumenta il numero di reindirizzamenti [concatenati], che è generalmente attribuito alla diluizione SEO.

Quindi HSTS è generalmente la scelta migliore a causa della sua natura lato client + sandbox. Ma c'è un "pericolo" con un TTL molto lungo nella cache. Quando un SSL scade o se si desidera tornare alla modalità http, gli utenti verranno bloccati. Questo perché il TTL HSTS memorizzato nella cache è / cercherà solo https, ma i browser nogo i siti con un certificato scaduto. Quindi non lasciarlo mai scadere o cambiare modalità senza impostare il tempo della cache HSTS su 0 nelle settimane (o mesi) prima della modifica :) Non devi preoccuparti di questo con 301 poiché non è il browser a decidere reindirizzamento o meno: le persone non verranno bloccate se effettui la modifica lato server.

I browser memorizzano nella cache 301 risposte, quindi potresti guardare gli utenti con quelle se disabiliti HTTPS:
È vero che l'HSTS stesso è sicuro.Ma se l'utente accede con http e il sito non è precaricato, non c'è modo di scoprire l'intestazione HSTS senza reindirizzamento da http a https.In altre parole, una volta effettuata una richiesta http, MiTM è possibile.Il trucco è evitare di effettuare QUALSIASI richiesta http, a meno che il collegamento in uno vecchio, il sito web sia per un elettrodomestico, ecc. Una soluzione è aggiungere una nuova funzionalità ai record di zona DNS per dire "questo dominio supporta https".
@DavidSpector Per l'ennesima volta "e il sito non è precaricato" Quindi precarica allora.
@DavidSpector HSTS è un meccanismo di applicazione lato client di backup.Non è un sostituto per i meccanismi a livello di server ... è un'aggiunta.Se il tuo server / app / sito è impostato per applicare la modalità `https` sempre e ovunque, non servirà mai una richiesta` http` per cominciare.Puoi farlo direttamente a livello di nginx / apache.Un visitatore non potrebbe mai accedere a una pagina `http`, non verrebbe mai generata una sessione non sicura, non verrebbero utilizzati cookie non sicuri, ecc.esso, per-dire.
@JosephSible-ReinstateMonica aiuta sicuramente ad aggiungere quel flag, ma l'elenco di precaricamento nei browser è ancora utilizzato.Quindi, se hai il flag, ma il tuo dominio non è nell'elenco, non verrà precaricato.Puoi inviare il tuo dominio qui: https://hstspreload.org/.Non so se o quanto tempo ci vuole per essere aggiunto :)
@dhaupin No, HSTS è il meccanismo principale.Niente di ciò che fa il server può effettivamente applicare HTTPS, poiché sslstrip può semplicemente annullare tutto ciò che fa a meno che il client non sappia di utilizzare HTTPS dall'inizio (che è esattamente il punto di HSTS).E niente nel mio commento ha suggerito che l'intestazione fosse sufficiente;Volevo anche aggiungerlo alla lista.
@JosephSible-ReinstateMonica https: // github.com / LeonardoNve / sslstrip2 - apparentemente nessun "https" è sicuro, quindi qual è il punto di usarlo;) Sto scherzando.I casi d'uso sono limitati e il 99,9999% degli utenti trarrà vantaggio da entrambe le modalità.
@dhaupin [Quello strumento in realtà non funziona] (https://security.stackexchange.com/a/91096/127145).
@JosephSible-ReinstateMonica Haha, ti sento.Nemmeno un gruppo di altri, ma il punto è che l'HSTS verrà manomesso e iniettato ad un certo punto.Ci tengo molto, ma HSTS è un proto debole supportato dalle modalità di applicazione (IMO), le intestazioni possono essere ignorate / rimosse, ora ci sono un miliardo di vettori in aggiunta.In realtà sono d'accordo con i thread sopra per un flag di zona, ma anche questo potrebbe essere ignorato / intercettato / rimosso.Felice anno nuovo amico, potremmo andare avanti per anni su questo.
Il punto del precaricamento è che si diventa immuni a tutte queste manomissioni in questo modo.
@JosephSible-ReinstateMonica ...... hai dimenticato di menzionare tutte queste manomissioni del traffico * browser *.Ma questo risale al mio commento su come devi essere accettato nell'elenco di precarico.Pensi che aggiungeranno ogni piccolo sito alle reti?Devi essere un grosso problema per entrare in quella lista, altrimenti distribuiscono un file di testo da 5 + GB pieno di BS.Ho provato alcune volte a entrare in quella lista per alcuni domini piuttosto grandi .... anni dopo, ancora non lì.`preload` non influisce sul 99,9999% dei siti.Tuttavia, fai emergere punti positivi.
@dhaupin Sospetto che allora qualcosa non andasse con la tua configurazione TLS.Faranno entrare ogni piccolo sito.
Cerchiamo di [continuare questa discussione in chat] (https://chat.stackexchange.com/rooms/102751/discussion-between-dhaupin-and-joseph-sible-reinstate-monica).
#6
-3
David Spector
2019-12-28 01:36:28 UTC
view on stackexchange narkive permalink

Poiché HSTS richiede ancora un reindirizzamento la prima volta che ogni utente visita il tuo sito web (a meno che non siamo così sicuri di nessun errore che si possa osare un precaricamento irreversibile tramite registrazione), questa è una domanda trabocchetto. In sostanza non c'è differenza tra l'utilizzo dell'intestazione HSTS e l'utilizzo di un'intestazione di reindirizzamento.

L'unica buona soluzione a cui riesco a pensare è l'aggiunta di un tipo di record o di un flag a ciascun record di zona DNS per specificare "questo dominio supporta HTTPS ". Quindi non c'è bisogno di HSTS o reindirizzamento. Il browser sa già che https è supportato (dalla sua ricerca DNS), quindi può (a meno che non venga annullato dall'utente) riscrivere l'http dell'utente in https prima ancora di inviare la prima richiesta al server remoto.

Questo non è corretto.Un reindirizzamento 301 influisce solo sull'URL specifico su cui lo hai colpito, ma HSTS influisce sull'intero dominio.E stai anche facendo suonare il precaricamento molto peggio di quanto non sia in realtà.
Questa non è una "domanda trabocchetto".Non hai rappresentato correttamente ciò che accade in HSTS.Inoltre, la domanda è dal lato server.Stai proponendo un protocollo completamente nuovo.
HTTPS Everywhere (https://www.eff.org/https-everywhere) fa quello che vuoi dal lato client.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...