HTTP Strict Transport Security: differenze tra le versioni

Versione delle 22:12, 5 nov 2020

Versione delle 22:14, 5 nov 2020

Riga 1:

'''''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 [[Dirottamento di sessione|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 di rete|protocollo]] HTTPS e non sul semplice [[HTTP]]<ref name="https">HTTPS denota HTTP sopra lo strato [[Transport Layer Security|TLS/SSL]].</ref>.

La procedura è uno standard di Internet della [[IETF]], normato dal [[Request for Comments|RFC]] 6797.

La politica HSTS<ref name="hsts-no-user-recourse">Hodges, Jeff; Jackson, Collin; Barth, Adam (novembre 2012).</ref> è indicata dal server allo [[user agent]] specificando una particolare intestazione nei messaggi di risposta [[Hypertext Transfer Protocol|HTTP]], denominata «<code>Strict-Transport-Security</code>» 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)''.<ref name="web-sec-policy-frmwk">Hodges, Jeff; Steinguebl, Andy (29 ottobre 2010).</ref>

Riga 36 ⟶ 42:

Dato che HSTS ha limiti temporali, il protocollo è sensibile ad attacchi che prevedono di spostare l'orologio della vittima, per esempio inviando falsi pacchetti [[Network Time Protocol|NTP]].<ref>{{Cita web|url= https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security.pdf|titolo= Bypassing HTTP Strict Transport Security|data= 17 ottobre 2014|accesso= 22 ottobre 2014|autore= Jose Selvi}}</ref>

== Limiti ==

Di fronte ad attacchi attivi, la presenza di HSTS non è in grado di proteggere la prima richiesta ad un'applicazione web, quando quella sia veicolata su un protocollo non sicuro come HTTP in chiaro o quando il relativo [[Uniform Resource Identifier|URI]] è stato ottenuto su un canale insicuro.<ref name="hsts-bootstrap-mitm">{{Cita web|url= https://tools.ietf.org/html/rfc6797#section-14.6|titolo= Section 14.6. Bootstrap MITM Vulnerability|sito= RFC 6797|editore= IETF|cognome= Hodges|nome= Jeff|autore2= Collin Jackson|autore3= Adam Barth|data= novembre 2012|accesso= 21 novembre 2012}}</ref>

Lo stesso vale per la prima richiesta che sia effettuata dopo la scadenza del periodo precisato dal parametro <code><nowiki>max-age</nowiki></code> 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.

I browser [[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<ref name="preloading_hsts_chromium"/><ref name="preloading_hsts_mozilla"/><ref name="iepreload"/> che è distribuito direttamente all'interno del browser e che fa sì che questo usi 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 [[Domain Name System|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|ultimo miglio di connessione]].<ref>Simon Butcher (11 settembre 2011).</ref>

Anche quando provvisto della «lista preliminare STS», il meccanismo HSTS non è comunque in grado di proteggere da attacchi che riguardino lo stesso livello di sicurezza TLS, quali ad esempio il [[Transport Layer Security|BEAST]] o il CRIME ideati da Juliano Rizzo e Thai Duong: il mantenimento della politica HSTS è ininfluente e irrilevante di fronte a questo tipo di attacchi.

Per una più estesa discussione della sicurezza di HSTS, si veda il RFC 6797.<ref name="hsts-seccons">{{Cita web|url= https://tools.ietf.org/html/rfc6797#section-14|titolo= Section 14. Security Considerations|sito= RFC 6797|editore= IETF|cognome= Hodges|nome= Jeff|autore2= Collin Jackson|autore3= Adam Barth|data= novembre 2012|accesso= 21 novembre 2012}}</ref>

== Supporto da parte dei browser ==