HSTS preload: requisiti di invio, rischi e come verificare header e stato nella lista

1. Che cos’è la lista HSTS preload

HTTP Strict Transport Security è definito nella RFC 6797. Un server invia Strict-Transport-Security: max-age=… su HTTPS e il browser ricorda per max-age secondi che l’host può essere raggiunto solo tramite HTTPS. Finché il browser di un visitante non ha ricevuto quell’header almeno una volta, nulla protegge la prima richiesta http:// in chiaro, e un attaccante sulla stessa rete può intercettarla. La RFC descrive questa debolezza iniziale e indica le policy preconfigurate come una possibile risposta.

La lista preload è quella risposta messa in pratica. La mantiene il progetto Chromium e le nuove voci vengono inserite direttamente nel codice sorgente di Chrome. Secondo la pagina HSTS di Chromium e hstspreload.org, Firefox, Safari ed Edge mantengono liste proprie basate su quella di Chrome. In ogni versione del browser che include la voce, un dominio in preload è solo HTTPS fin dal primo avvio e, poiché gli invii devono includere includeSubDomains, lo è anche ogni nome sottostante.

Tre dettagli vengono spesso fraintesi:

• La direttiva preload non fa nulla nel browser. Non fa parte della RFC 6797 e i browser ignorano le direttive che non riconoscono. Serve a indicare ai gestori della lista che il titolare del dominio acconsente all’inclusione. Una volta che il tuo header la contiene, chiunque può inviare il tuo dominio tramite il modulo.
• Nella lista entrano solo domini registrabili interi. Si invia example.com, non www.example.com né shop.example.com, e la voce copre ogni sottodominio, compresi quelli interni non raggiungibili pubblicamente.
• Alcuni domini di primo livello sono in preload per intero. Ogni dominio sotto .app o .dev, per esempio, è già solo HTTPS nei browser che usano la lista, indipendentemente dal fatto che il titolare abbia inviato qualcosa.

2. Hai ancora bisogno del preload?

Per la maggior parte dei siti, probabilmente no. Lo stesso sito di invio ora afferma che HSTS è raccomandato, mentre il preload HSTS no. Chrome e Safari provano automaticamente HTTPS per le navigazioni che partono da http://, qualunque sia la policy HSTS, quindi la lacuna della prima visita che il preload doveva colmare si è ridotta. Secondo hstspreload.org, il preload aggiunge protezione solo quando questi upgrade automatici falliscono a causa di un attaccante attivo, e il suo beneficio è minimo rispetto a HSTS stesso.

Il preload può ancora avere senso quando sono vere tutte queste condizioni:

• un downgrade alla primissima visita è un problema per te, per esempio perché le persone accedono o pagano da reti pubbliche;
• ogni sottodominio attuale e futuro, compresi quelli interni e quelli ospitati da fornitori, può servire HTTPS con un certificato valido;
• prevedi di mantenere il dominio, e HTTPS su di esso, per anni.

Rinuncia, o rimanda, se team o fornitori gestiscono sottodomini che non controlli del tutto, se host interni vivono sotto il dominio pubblico, se il dominio appartiene a una campagna di breve durata o se potresti venderlo o cederlo: la voce segue il dominio al suo prossimo proprietario finché qualcuno non ne chiede la rimozione. Un header HSTS ben configurato senza preload protegge già ogni visitatore di ritorno.

3. I requisiti di invio esatti

hstspreload.org verifica queste condizioni al momento dell’invio e devi continuare a rispettarle in seguito: i domini che smettono di soddisfarle possono essere rimossi, e togliere preload dall’header rende il dominio subito idoneo alla rimozione.

La regola sul redirect mette in difficoltà molti siti. Se https://example.com/ reindirizza a https://www.example.com/, quella risposta di redirect deve contenere l’header completo. L’header sulla pagina www non conta, perché una policy impostata da www.example.com non si applica mai al dominio di base. Un header che supera il controllo ha questo aspetto:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

4. I rischi: perché il preload è difficile da annullare

• La rimozione richiede mesi. La rimozione è una modifica del codice sorgente che raggiunge le persone con gli aggiornamenti del browser. La pagina sulla rimozione indica che possono servire da 6 a 12 settimane per raggiungere la maggior parte degli utenti Chrome, e forse di più negli altri browser. Un browser che non viene mai aggiornato mantiene la vecchia voce.
• I sottodomini che non supportano HTTPS smettono di funzionare. Casi tipici sono gli host intranet che si risolvono solo su DNS interno, le pagine di amministrazione di stampanti, router e dispositivi di archiviazione con certificati autofirmati, i server di staging dimenticati e i servizi di fornitori su CNAME, come un help desk, una pagina di stato o i link di tracciamento dei clic nelle email, che rispondono solo su HTTP. In un browser con il tuo dominio in preload, falliscono senza alcun modo di superare l’errore.
• Gli errori di certificato diventano errori bloccanti. Su un host HSTS la RFC 6797 impone al browser di interrompere la connessione a ogni errore di certificato, senza lasciare al visitatore la possibilità di procedere. Un certificato scaduto su qualsiasi sottodominio blocca tutti finché non viene sostituito: automatizza il rinnovo e monitora le scadenze prima dell’invio.
• I visitatori di ritorno conservano la policy memorizzata. Uscire dalla lista non cancella la policy che i browser hanno appreso dal tuo header. Con un max-age di due anni, quella copia dura due anni, a meno che il visitatore non torni e riceva max-age=0 su HTTPS.
• Invio accidentale. Un header copiato da un modello che contiene già preload basta a chiunque per inviare il tuo dominio. Lascia fuori la direttiva finché il piano della sezione successiva non è concluso.

5. Un piano graduale per max-age prima dell’invio

hstspreload.org raccomanda di aumentare max-age per fasi, con includeSubDomains fin dalla prima. A ogni fase cerca pagine non funzionanti e tieni d’occhio i tuoi numeri, come traffico, accessi e ricavi, correggi ciò che emerge, poi attendi almeno l’intero max-age di quella fase prima di passare alla successiva. Puoi eseguire le fasi prima con un gruppo di prova, ma poi eseguile per tutti.

Su nginx, invia l’header dal blocco server HTTPS con il parametro always, in modo che lo portino anche le pagine di errore, e mantieni il redirect HTTP sullo stesso host. Una riga add_header dentro un blocco location sostituisce lì gli header a livello di server (modulo headers di nginx).

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # fase 1: cambia il valore a ogni fase
    add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;
}

Solo la progressione richiede più di cinque settimane. Dopo l’invio, hstspreload.org avverte che una nuova voce può impiegare diversi mesi per arrivare a Chrome stabile, quindi il preload non è mai una soluzione rapida per una data di lancio.

6. Come verificare l’header HSTS

Controlla da terminale le tre risposte che contano:

curl -sS -D - -o /dev/null http://example.com/
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://www.example.com/

La prima deve restituire 301 o 308 con Location: https://example.com/; non richiede un header HSTS, perché i browser ignorano HSTS ricevuto su HTTP in chiaro. La seconda deve contenere strict-transport-security con tutte e tre le direttive, anche quando è a sua volta un redirect verso www. Anche la terza dovrebbe inviare l’header, perché un visitatore che apre sempre e solo www non riceve mai la policy del dominio di base. Su Windows usa curl.exe e -o NUL.

Attenzione a questi errori:

• Due header HSTS. Quando CDN e origine ne aggiungono uno ciascuno, la RFC 6797 dice ai browser di elaborare solo il primo, e il controllo di hstspreload.org segnala “Multiple HSTS headers” come errore. Decidi quale livello è responsabile dell’header.
• Una direttiva scritta male. I browser scartano senza alcun avviso le direttive che non riconoscono, quindi includeSubdomain senza la s finale lascia silenziosamente scoperti i sottodomini.
• Assente in alcune risposte. La home page ha l’header, ma le pagine di errore, l’API o i file statici serviti da un altro livello no.

In Chrome DevTools apri il pannello Network, poi digita http://example.com/ nella barra degli indirizzi dopo che il browser ha memorizzato la policy. La prima voce mostra 307 Internal Redirect con Non-Authoritative-Reason: HSTS: il browser è passato a HTTPS da solo, prima che qualsiasi richiesta raggiungesse il server. Il riferimento MDN elenca la sintassi dell’header.

7. Come verificare lo stato nella lista preload

• hstspreload.org. Inserisci il dominio nel modulo. Mostra se il dominio è in preload, in attesa o non presente in lista, insieme a eventuali errori e avvisi rispetto ai requisiti attuali. Un dominio in attesa non è ancora protetto: deve ancora essere distribuito in una release del browser.
• chrome://net-internals/#hsts. In Chrome inserisci il dominio sotto “Query HSTS/PKP domain”. I campi che iniziano con static_ provengono dalla lista integrata in quella versione del browser; quelli che iniziano con dynamic_ provengono dagli header che il browser ha ricevuto. “Delete domain security policies” cancella solo la parte dinamica, quindi una voce in preload resta finché un aggiornamento del browser non la rimuove.
• Altri browser. Firefox, Safari ed Edge distribuiscono copie proprie derivate dalla lista di Chrome, con tempi propri, quindi un’aggiunta o una rimozione può raggiungerli in momenti diversi.

Ripeti il controllo dopo modifiche a DNS, CDN o certificati. hstspreload.org segnala che in futuro i domini che smettono di rispettare i requisiti potrebbero essere rimossi automaticamente.

8. Uscire dalla lista: passaggi e tempi della rimozione

1. Continua a servire HTTPS con un certificato valido sul dominio di base; il modulo di rimozione lo verifica.
2. Invia un header HSTS senza preload. hstspreload.org considera quell’header come richiesta di rimozione. Mantieni includeSubDomains e un max-age lungo se vuoi ancora HSTS, oppure invia max-age=0 per disattivare del tutto HSTS.
3. Invia il dominio con il modulo di rimozione.
4. Nell’attesa, assegna un certificato valido al sottodominio che ha reso necessaria la decisione oppure spostalo su un altro dominio: la rimozione può richiedere da 6 a 12 settimane per raggiungere la maggior parte degli utenti Chrome e di più per gli altri browser.
5. Non inviare di nuovo preload, a meno che tu non voglia essere aggiunto di nuovo.

max-age=0 funziona solo su HTTPS e solo per i visitatori che tornano e lo ricevono. Pianifica pensando al percorso più lento: un browser non aggiornato che ha ancora la voce integrata, o una policy di due anni già memorizzata, può continuare a imporre HTTPS ben dopo che hai cambiato rotta.

9. Che cosa mostra lo snapshot gratuito

Lo snapshot gratuito di preparazione al lancio esegue otto controlli passivi su un dominio pubblico, senza registrazione, e restituisce un punteggio con l’esito di ciascun controllo. Due di questi riguardano HSTS:

• Il controllo degli header di sicurezza HTTP legge la home page del dominio inserito, dopo al massimo cinque redirect. Valuta come media la mancanza dell’header Strict-Transport-Security su una destinazione HTTPS e mostra il valore osservato.
• Il controllo del redirect a HTTPS segnala come bassa la gravità di un max-age inferiore a 180 giorni (15.552.000 secondi) quando inserisci un dominio senza schema o un indirizzo https://. Durante le fasi da 1 a 3 del piano, questo risultato è atteso.

Non controlla includeSubDomains, la direttiva preload, i tuoi sottodomini né il tuo stato nella lista; per questi usa hstspreload.org e i comandi curl visti sopra. Per aprire prima il risultato sugli header, usa la verifica gratuita degli header di sicurezza, che esegue lo stesso snapshot. Per il lato certificati, leggi la guida a certificati TLS e HSTS, mentre la checklist di lancio del sito mette HSTS accanto a redirect, DNS e agli altri controlli pre-lancio.