HTTP Strict Transport Security: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m +wl |
m Conversione url nudo in cita web, formattazioni nei Cita, fix sezioni e template di compatibilità, fix minori. Vedi PU per dettagli |
||
Riga 4:
La procedura è uno standard di Internet della [[IETF]], normato dal [[Request for Comments|RFC]] 6797.
La politica HSTS<ref name="hsts-
== 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
Le specifiche HSTS si basano sul contributo originale di Jackson e Barth descritto nell'articolo ''ForceHTTPS: Protecting High-Security Web Sites from Network Attacks''.<ref name="forcehttps-paper">
La prima bozza originale delle specifiche fu scritta da Jeff Hodges<ref name="jeffhodges-ext">
La prima specifica di HSTS fu resa pubblica il 18 dicembre 2009 e corrispose all'ultima cosiddetta "versione della comunità", che beneficiava appunto del riscontro pubblico.<ref name="STS-draft-spec-2">
In seguito all'approvazione del 2 ottobre 2012 da parte dell'[[Internet Engineering Steering Group|IESG]], la specifica di HSTS è stata pubblicata come [[Request for Comments|RFC]] ''Proposed Standard'' (standard proposto) il 19 novembre 2012 nel RFC 6797 <ref name="hsts-ps-rfc-approval-iesg-msg">
La prima versione originale del documento fu però depositata già il 17 giugno 2010 come [[Internet Draft|Internet-Draft]], momento nel quale il titolo della specifica fu cambiato da "Strict Transport Security" (STS) al più preciso "HTTP Strict Transport Security".<ref
▲La prima versione originale del documento fu però depositata già il 17 giugno 2010 come [[Internet Draft|Internet-Draft]], momento nel quale il titolo della specifica fu cambiato da "Strict Transport Security" (STS) al più preciso "HTTP Strict Transport Security".<ref><cite class="citation web" contenteditable="false">Jeff Hodges (30 June 2010).</cite></ref>
Ciononostante, l'intestazione HTTP definita dalle specifiche ha mantenuto il nome di "Strict-Transport-Security".
== Panoramica della procedura ==
Un server implementa la politica HSTS se emette la relativa intestazione in un messaggio di una comunicazione HTTPS (su HTTP tali intestazioni sono invece ignorate).<ref>
Per esempio, un server potrebbe inviare un'intestazione che richieda che ogni richiesta a lui diretta nell'anno successivo sia trasmessa necessariamente tramite HTTPS.
In tal caso, dato che il parametro ''max-age'' è espresso in secondi e che 31.536.000 secondi sono una buona approssimazione di un anno, l'intestazione sarebbe:
:<code>Strict-Transport-Security: max-age=31536000; includeSubDomains;</code>.
Quando un'applicazione web<ref name="webapp">
# Ogni collegamento non sicuro è trasformato in un collegamento sicuro,
# Se la sicurezza della connessione non è considerata affidabile, ad esempio se il certificato [[Transport Layer Security|TLS]] non è tale, un messaggio d'errore è mostrato all'utente e l'accesso all'applicazione web è impedito.<ref name="hsts-no-user-recourse"/>
La politica HSTS aiuta a proteggere gli utenti delle applicazioni web da certi attacchi passivi (''[[eavesdropping]]'') o attivi:<ref name="hsts-threats-addressed">{{Cita web|url= https://tools.ietf.org/html/rfc6797#section-2.3|titolo= 2.3. Threat Model|sito= RFC 6797|editore= IETF|cognome= Hodges|nome= Jeff|autore2=
== Applicabilità ==
La vulnerabilità di sicurezza più importante che possa essere scongiurata da HSTS è il cosiddetto [[Attacco man in the middle|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''.<ref>{{Cita pubblicazione|url= https://blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf|titolo= New Tricks For Defeating SSL In Practice}}</ref><ref>
Questo attacco consiste nel convertire silenziosamente una connessione HTTP sicura, appoggiata a [[Transport Layer Security|SSL]] o a [[Transport Layer Security|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.
Riga 38 ⟶ 37:
HSTS si occupa di questo problema<ref name="hsts-threats-addressed"/> 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.<ref name="preloading_hsts_chromium">{{Cita web|url= https://www.chromium.org/sts|autore= Adam Langley|titolo= Strict Transport Security|sito= The Chromium Projects|data= 8 luglio 2010|accesso= 22 luglio 2010}}</ref><ref name="preloading_hsts_mozillla
Nel prossimo paragrafo [[Strict Transport Security|Limiti]] si discuterà anche di come questa soluzione sia necessariamente insufficiente, dato che il suddetto elenco non può essere esaustivo.
Riga 46 ⟶ 45:
== 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=
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_mozillla"/><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>
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=
== Supporto da parte dei browser ==
[[File:Chromium HSTS settings screenshot.png|alt=Pagina di impostazioni per HTTPS Strict Transport Security in Chromium 45, che mostra lo stato della politica di sicurezza per il dominio di Wikipedia in inglese.|thumb|right|428x428px|Pagina di impostazioni per HTTPS Strict Transport Security in Chromium 45, che mostra lo stato della politica di sicurezza per il dominio di Wikipedia in inglese.]]
*[[Chromium]] e [[Google Chrome]] dalla versione 4.0.211.0<ref name="chromium_sts">{{Cita web|url= https://dev.chromium.org/sts|autore= The Chromium Developers|titolo= Strict Transport Security - The Chromium Projects|data= 17 novembre 2010|accesso= 17 novembre 2010}}</ref><ref
* [[Mozilla Firefox|Firefox]] dalla versione 4;<ref>
* [[Opera (browser)|Opera]] dalla versione 12<ref name="opera_presto">{{Cita web|url= http://www.opera.com/docs/specs/presto2.10/#m210-244|autore= Opera Software ASA|titolo= Web specifications support in Opera Presto 2.10|data= 23 aprile 2012|accesso= 8 maggio 2012}}</ref>
* [[Safari (browser)|Safari]] da [[OS X Mavericks]]<ref
* [[Internet Explorer 11]] su [[Windows 8.1]] e [[Windows 7]] qualora sia installato
* [[Microsoft Edge]] e [[Internet Explorer 11]] su [[Windows 10]].<ref>{{Cita web|url= https://status.modern.ie/httpstricttransportsecurityhsts|titolo= Internet Explorer Web Platform Status and Roadmap|accesso= 14 aprile 2014}}</ref><ref>
== Buone norme per la messa in opera ==
| |||