"Google.com" non è protetto da HSTS?

Oct 07 2020

Problema:

Spesso le persone entrano google.comdirettamente nella barra degli indirizzi del browser senza includere i prefissi http://o https://.

Utilizzando Chrome DevTools in una nuova sessione di navigazione in incognito, ho eseguito il seguente esperimento:

PASSI:
-----------------
Inserisci "google.com" (o equivalentemente "http://google.com") direttamente nel file
barra degli indirizzi del browser.

1. Richiesta: http://google.com;
Risposta: Codice di stato: 301 spostato in modo permanente
Posizione: http://www.google.com/
Controllo cache: pubblico, età massima = 2592000

2. Richiesta: http://www.google.com;
Risposta: Codice di stato: 302 Trovato
Posizione: https://www.google.com/?gws_rd=ssl

3. Richiesta: https://www.google.com/?gws_rd=ssl;
Risposta: Codice di stato: 200
rigoroso-trasporto-sicurezza: max-age = 31536000

APPUNTI:
-----------------
* Per ottenere gli stessi risultati, avvia una nuova sessione di navigazione in incognito (chiudi tutte le
Windows e aprirne uno nuovo). Se hai già una finestra di navigazione in incognito, aprilo
potrebbe non ottenere gli stessi risultati. Anche aver selezionato "disabilita cache" non aiuta.

* Se ripeti l'esperimento dalla stessa sessione di navigazione in incognito, noterai il
seguenti differenze rispetto alla prima volta:

* Richiesta 1: se "disabilita cache" è deselezionato (che imita il file
comportamento durante il normale utilizzo), la risposta sarà dalla cache
a causa della risposta "Cache-Control: public, max-age = 2592000"
intestazione restituita la prima volta. Ciò significa che http
la richiesta non viene inviata (anche se mostra ancora un 301
risposta) che è probabilmente una buona cosa.

* Richiesta 2: la risposta sarà 307 invece di 302. Ciò è dovuto a
"strict-transport-security: max-age = 31536000" restituito da
terza richiesta la prima volta. Questo è il caso a prescindere
se "disabilita cache" è selezionato o meno.

* Una volta che il browser si rende conto che un dominio è protetto da HSTS (tramite il
Precaricamento HSTS o intestazione della risposta STS) il browser reindirizzerà "internamente"
tutte le richieste http a https per quel dominio. Questi reindirizzamenti vengono visualizzati in
scheda di rete come "Codice di stato: 307 Reindirizzamento interno" (che è una specie di
fuorviante poiché sembra che la risposta provenga da un server quando è in
in realtà sta tutto accadendo all'interno del browser. Notare che non esiste
"Indirizzo remoto" nella sezione "Generale" per queste richieste

* Un altro modo (forse più semplice) per verificare se un dominio è protetto da HSTS è tramite
inserendo il dominio in https://hstspreload.org/ ma ci sono avvertenze!
https://hstspreload.org/ segnala quanto segue per "www.google.com":
- "Errore di risposta: nessuna intestazione HSTS è presente nella risposta."
- "` http: // www.google.com` non reindirizza a `https: // www.google.com`"
Nessuno di questi risultati è coerente con quanto osservato nella rete
scheda nell'esperimento sopra! Ho inviato un'e-mail alla mailing list hstspreload e
ha ricevuto la seguente risposta interessante: "Il server per
http://www.google.com non reindirizza sempre http a https, motivo per cui questo
viene visualizzato un errore. Ad esempio, se utilizzo curl, non ottengo il reindirizzamento. "
-----------------

Problemi di privacy / sicurezza:

La richiesta iniziale a google.comviene eseguita httppoiché google.comnon è inclusa nell'elenco di precaricamento HSTS. Questa richiesta è vulnerabile agli attacchi MITM.
In nessun momento il browser viene reindirizzato https://google.com, pertanto l'intestazione STS non viene mai impostata per questo dominio. Ciò significa che anche le richieste future a google.comnon saranno protette da HSTS e potrebbero quindi essere vulnerabili agli attacchi MITM!

Vale la pena notare che l' intestazione della risposta cache-control max-age = 2592000 (30 giorni) inclusa nel reindirizzamento 301 iniziale sembra fornire un livello di protezione simile a quello fornito da HSTS poiché fa sì che le richieste future http://google.comvengano gestite "internamente" dalla cache (e soprattutto reindirizzato al dominio protetto HSTS "www.google.com"). D'altra parte, il controllo della cachemax-age è impostato per scadere dopo 30 giorni (molto più breve di quello su cui max-ageè solitamente impostato l'HSTS ) e, cosa più importante, a differenza dell'HSTS max-age che viene aggiornato ad ogni httpsrichiesta fatta a un dominio abilitato per HSTS, il cache-control max agenon viene aggiornato finché non httpviene effettuata una nuova richiesta non sicura ! Ciò significa che le tue richieste google.compossono essere intercettate anche una volta ogni 30 giorni.
La richiesta a www.google.comviene effettuata tramite http ed è vulnerabile agli attacchi MITM. Almeno in questo caso la risposta è un reindirizzamento 302 a https://www.google.comcui include l'intestazione STS. Ciò significa che qualsiasi richiesta successiva http://www.google.comverrà reindirizzata "internamente" a https dal browser, come indicato sopra, l'HSTS max-ageviene aggiornato ad ogni richiesta. Quindi, fintanto che il tuo browser effettua una richiesta https://www.google.comalmeno una volta all'anno (che è quella su cui max-ageè impostata la scadenza STS ), tutte le richieste a quel dominio saranno protette HSTS.

TL; DR - "google.com" non è protetto da HSTS e sembra che le richieste possano essere potenzialmente soggette ad attacchi MITM anche una volta ogni 30 giorni (o più spesso se la cache viene svuotata o viene utilizzata la modalità di navigazione in incognito).

Questo potrebbe non essere così grave come sembra per i seguenti motivi:

Tutti i cookie importanti per .google.come www.google.comsicuramente hanno la securebandiera impostata.
google.comsembra non fare altro che reindirizzare a, www.google.comquindi qualsiasi richiesta a google.comsarebbe realisticamente solo al percorso di root (quindi l'URL stesso non sarebbe interessante per un intercettatore).
I sottodomini di Google che inviano / ricevono dati più sensibili (ad es. Gmail.com, accounts.google.com ...) si trovano nell'elenco di precaricamento HSTS. Quindi, anche se un utente malintenzionato imposta qualcosa come sslsplit e un utente finisce su un utente malintenzionato controllato http://www.google.com(che è già abbastanza difficile da estrarre poiché richiede all'utente di non notare l'icona del lucchetto mancante), i domini precaricati HSTS sarebbero comunque protetti . Un utente malintenzionato dovrebbe quindi impedire a un utente di navigare in uno di questi sottodomini.

Domande

Quali potrebbero essere i motivi per cui Google non ha abilitato l'HSTS google.com
Quali potrebbero essere i motivi per cui Google ha abilitato solo l'intestazione STS www.google.comma non ha aggiunto quel dominio all'elenco di precaricamento HSTS?

Risposte

28 EsaJokinen Oct 07 2020 at 13:35

Situazione attuale

È vero che, a partire da ottobre 2020, Google non ha HSTS attivo google.com, ma solo attivo www.google.com, ed esegue il reindirizzamento prima verso wwwe poi verso https://. Anche se fosse presente un'intestazione HSTS google.com, il browser non la vedrebbe e sarebbe in grado di memorizzarla nella cache. Solo www.google.comè protetto da HSTS.

Migliori pratiche

Si raccomanda inoltre come best practice, ad esempio, dal Consiglio federale CIO , che:

Nella sua forma più forte e consigliata, la politica HSTS include tutti i sottodomini e indica la volontà di essere "precaricato" nei browser:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 
Quando si utilizza questo modulo, tenere presente:

La politica dovrebbe essere distribuita a https://domain.gov, no https://www.domain.gov.

Tutti i sottodomini associati al dominio padre devono supportare HTTPS. (Non è necessario che ciascuno abbia la propria politica HSTS.)

OWASP HTTP Strict Transport Security Cheat Sheet aggiunge (annotato anche nella RFC 6797, 14.4 ):

I cookie possono essere manipolati dai sottodomini, quindi l'omissione includeSubDomainsdell'opzione consente un'ampia gamma di attacchi relativi ai cookie che HSTS impedirebbe altrimenti richiedendo un certificato valido per un sottodominio. Garantire che il flag di sicurezza sia impostato su tutti i cookie impedirà anche alcuni, ma non tutti, gli stessi attacchi.

Ciò può essere ottenuto solo reindirizzando prima a HTTPS.

Perché?

Tuttavia, possiamo solo dire cosa sarebbe meglio, ma non possiamo rispondere al motivo per cui alcuni non seguono queste linee guida. Solo Google sa perché l'hanno implementato in questo modo. Non è mancanza di conoscenza e capacità, come l'hanno già fatto, ad esempio gmail.com, che attualmente è nell'elenco di precaricamento HSTS.

Puoi avvicinarti alla tua risposta leggendo Bringing HSTS di Jay Brown su www.google.com dal blog sulla sicurezza di Google. Da questo articolo di luglio 2016 possiamo scoprire che è intenzionale, a causa della complessità dell'enorme sito, e per la retrocompatibilità con i servizi legacy .