HTTP Strict Transport Security
HTTP Strict Transport Security o HSTS (in italiano Sicurezza rigida per il trasporto di HTTP) è una procedura che implementa una politica di sicurezza per le comunicazioni web, necessaria a proteggere il canale HTTPS da attacchi di degrado della sicurezza (downgrade) e assai utile per la protezione dai dirottamenti di sessione. HSTS permette al server web di dichiarare che i browser e ogni altro tipo di client debbano comunicare con esso esclusivamente attraverso connessioni sicure su protocollo HTTPS e non sul semplice HTTP[1]. La procedura è uno standard di Internet della IETF, normato dal RFC 6797.
La politica HSTS[2] è indicata dal server allo user agent specificando una particolare intestazione nei messaggi di risposta HTTP, denominata «Strict-Transport-Security» che specifica il periodo di tempo durante il quale il client dovrà accedere al server in modalità necessariamente sicura.
Storia della specifica
HSTS è la concretizzazione di uno degli aspetti della visione progettuale di Jeff Hodges e Andy Steingruebl per migliorare la sicurezza del web, e presentata nel 2010 all'interno del loro articolo 2010 intitolato The Need for Coherent Web Security Policy Framework(s).[3]
Le specifiche HSTS si basano sul contributo originale di Jackson e Barth descritto nell'articolo ForceHTTPS: Protecting High-Security Web Sites from Network Attacks.[4]
La prima bozza originale delle specifiche fu scritta da Jeff Hodges[5] di PayPal, Collin Jackson[6] e Adam Barth[7] e pubblicata 18 settembre 2009.[8]
La prima specifica di STS fu resa pubblica il 18 dicembre 2009 e corrispose all'ultima cosiddetta "versione della comunità", che beneficiava appunto del riscontro pubblico.[9]
In seguito all'approvazione del 2 ottobre 2012 da parte dell'IESG, la specifica di HSTS è stata pubblicata come RFC Proposed Standard (standard proposto) il 19 novembre 2012 nel RFC 6797 [10]. La prima versione originale del documento fu però depositata già il 17 giugno 2010 come Internet-Draft, momento nel quale il titolo della specifica fu cambiato da "Strict Transport Security" (STS) al più preciso "HTTP Strict Transport Security".[11] Ciononostante, l'intestazione HTTP definita dalle specifiche ha mantenuto il nome di "Strict-Transport-Security".
Panoramica della procedura
Un server implementa la politica HSTS nel momento in cui emette la relativa intestazione in un messaggio di una comunicazione HTTPS (su HTTP tali intestazioni sono ignorate).[12]
Per esempio, un server potrebbe inviare un'instestazione che richieda che ogni richiesta a lui diretta nell'anno successivo sia trasmessa solo con HTTPS.
In tal caso, dato che il parametro max-age è espresso in secondi e che 31.536.000 è quindi una buona approssimazione di un anno, l'intestazione è Strict-Transport-Security: max-age=31536000; includeSubDomains;.
Quando un'applicazione web[13] dichiara agli user agent una politica HSTS i client conformi si comportano come descritto di seguito.[14]
- Ogni collegamento non sicuro è trasformato in un collegamento sicuro, cioè, per esempio,
http://example.com/some/page/è modificato inhttps://example.com/some/page/prima che tale risorsa utilizzata. - Se la sicurezza della connessione non è considerata affidabile, ad esempio se il certificato TLS non è tale, un messaggio d'errore è mostrato all'utente e l'accesso all'applicazione web è impedito.[15]
La politica HSTS aiuta a proteggere gli utenti delle applicazioni web da certi attacchi passivi (eavesdropping) o attivi:[16] in un attacco man-in-the-middle è molto più difficile intercettare domande e risposte tra l'utente e l'applicazione web quando il primo è in modalità HSTS rispetto alla seconda.
Applicabilità
La vulnerabilità di sicurezza più importante che possa essere scongiurata da HSTS è il cosiddetto man-in-the-middle con la tecnica di SSL-stripping, illustrata pubblicamente per la prima volta nel 2009 da Moxie Marlinspike nel suo intervento «New Tricks For Defeating SSL In Practice» (Messa in pratica dei nuovi trucchi per sconfiggere SSL) presentato al BlackHat Federal.[17][18] Questo attacco consiste nel convertire silenziosamente una connessione HTTP sicura, appoggiata a SSL o a TLS, in una connessione HTTP in chiaro: l'utente può verificare che effettivamente la connessione non sia sicura, ma non ha alcun modo di sapere che essa debba esserlo. Dato che diversi siti non usano TLS/SSL, infatti, non c'è modo di capire, se non conoscendo a priori lo specifico sito, se l'insicurezza della connessione sia l'effetto di un attacco, o se invece è il comportamento abituale dell'applicazione web. Inoltre il processo di regressione di sicurezza non genera alcun messaggio d'avvertimento all'utente, rendendo l'attacco discreto agli occhi di quasi chiunque. Lo strumento sslstrip di Marlinspike automatizza completamente tale attacco.
HSTS si occupa di questo problema[16] informando il browser che le sue connessioni al sito dovrebbero fare sempre uso di TLS/SSL. Visto che l'intestazione HSTS può però essere comunque manomessa da un attaccante nel momento della prima visita da parte di un utente, Google Chrome, Mozilla Firefox, Internet Explorer e Microsoft Edge cercano di limitare la problematica inserendo un elenco preliminare dei siti HSTS.[19][20][21] Nel prossimo paragrafo Limiti si discuterà anche di come questa soluzione sia necessariamente insufficiente, dato che il suddetto elenco non può essere esaustivo.
HSTS aiuta anche a prevenire il furto di credenziali di accesso a siti web basati su cookie HTTP, un attacco praticabile con strumenti facilmente disponibili, quale Firesheep.[22]
Dato che HSTS ha limiti temporali, il protocollo è sensibile ad attacchi che prevedono di spostare l'orologio della vittima, per esempio inviando falsi pacchetti . using false NTP packets.[23]
Limiti
La prima richiesta ad un'applicazione web non è protetta da attacchi attivi, quando essa usa un protocollo non sicuro come HTTP in chiaro o quando il relativo URI è stato ottenuto su un canale insicuro.[24]
Lo stesso vale per la prima richiesta effettuata dopo la scadenza del periodo precisato dal parametro max-age annunciato nella politica HSTS.
I siti dovrebbero pertanto impostare una durata di diversi giorni o di diversi mesi, a seconda dall'attività e comportamento degli utenti. Google Chrome, Mozilla Firefox e Internet Explorer/Microsoft Edge si occupano di questo limite del protocollo implementando una «lista preliminare STS»: un elenco di siti noti che supportano HSTS [19][20][21] che è distribuito direttamente con il browser e che lo induce ad usare HTTPS anche per la prima richiesta.
Ciononostante, come precedentemente accennato, tale lista non può elencare ogni sito web presente su Internet. Una possibile soluzione potrebbe essere realizzata usando i record DNS per dichiarare la politica HSTS ed accedendo a tali informazioni col protocollo DNSSEC, eventualmente avvalendosi di impronte digitali dei certificati per garantirne la validità, che a sua volta richiede un client di risoluzione DNS che verifichi quest'ultima per evitare problematiche nell'ultimo miglio di connessione.[25]
Anche se provvisto di una «lista preliminare STS» , HSTS non è in grado di prevenire attacchi allo stesso livello TLS, come il BEAST o il CRIME ideati daJuliano Rizzo e Thai Duong: il mantenimento della politica HSTS è ortogonale a questo genere di attacchi.
Per una più estesa discussione della sicurezza di HSTS, si veda il RFC 6797.[26]
Supporto da parte dei browser
- Chromium e Google Chrome dalla versione 4.0.211.0[27][28]
- Firefox dalla versione 4;[29] la versione 17 contiene una lista di siti che supportano HSTS.[20]
- Opera dalla versione 12[30]
- Safari da OS X Mavericks[31]
- Internet Explorer 11 su Windows 8.1 e Windows 7 qualora sia installato KB 3058515 (pubblicato nel giugno 2015).[32]
- Microsoft Edge e Internet Explorer 11 su Windows 10.[33][34]
Buone norme per la messa in opera
A seconda della specifica messa in opera, certe buone norme consentono di evitare alcune minacce alla sicurezza, come gli attacchi con iniezione di cookie.
- Gli host HSTS dovrebbero dichiarare la politica HSTS nel loro nome di livello massimo: per esempio, un server in ascolto su https://sub.example.com dovrebbe rispondere con l'intestazione HSTS anche per richieste a https://example.com .
- Un host che serve https://www.example.com dovrebbe aggiungere una richiesta ad una risorsa di https://example.com , cosicché HSTS sia impostato anche per il dominio padre. In tal modo l'utente è protetto da eventuali cookie injection effettuati da un man-in-the-middle che potrebbe iniettare un riferimento verso il dominio superiore o un altro dello stesso livello (come http://nonexistentpeer.example.com) dove risponderebbe.
Articoli correlati
Collegamenti esterni
- The State of HSTS Deployment: A Survey and Common Pitfalls provides an analysis of HSTS deployment statistics, patterns, mistakes, and best practices.
- RFC 6797, HTTP Strict Transport Security (HSTS)
- IETF WebSec Working Group
- Security Now 262: Strict Transport Security
- Open Web Application Security Project (OWASP): HSTS description
- Online browser HSTS and Public Key Pinning test
- HSTS Preload Submission for Google Chrome, Mozilla Firefox, Safari, IE 11, and Edge
Note
