HTTP Strict Transport Security: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Conversione url nudo in cita web, formattazioni nei Cita, fix sezioni e template di compatibilità, fix minori. Vedi PU per dettagli |
→Limiti: eliminata la parte (copiata da en.wikipedia) che conteneva considerazioni personali e non supportate da dati tecnici sulla capacità di DNSSEC di comunicare campi HSTS per la mitigazione dell'attacco di downgrade |
||
(15 versioni intermedie di 11 utenti non mostrate) | |||
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>.
Riga 15 ⟶ 14:
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">{{Cita web |url=https://lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html |titolo= "Strict Transport Security -06" |data= 18 dicembre 2009}}</ref>
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
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>Jeff Hodges (30 giugno 2010).</ref>
Ciononostante, l'intestazione HTTP definita dalle specifiche ha mantenuto il nome di "Strict-Transport-Security".
Riga 28 ⟶ 27:
# Ogni collegamento non sicuro è trasformato in un collegamento sicuro, cioè, per esempio, <code><nowiki>http://example.com/some/page/</nowiki></code> è modificato in <code><nowiki>https://example.com/some/page/</nowiki></code> ''prima'' che tale risorsa venga utilizzata.
# 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= Collin Jackson|autore3= Adam Barth|data= novembre 2012|accesso= 21 novembre 2012}}</ref> in un
== Applicabilità ==
Riga 36 ⟶ 35:
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<ref name="hsts-threats-addressed"/> informando il browser che le sue connessioni al sito dovrebbero fare sempre uso di
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
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 48 ⟶ 47:
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="
Ciononostante, come precedentemente accennato, tale lista non può elencare ogni sito web presente su Internet.
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
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 ==
[[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|
*[[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>Jeff Hodges (18 settembre 2009). {{Cita web |url=
* [[Mozilla Firefox|Firefox]] dalla versione 4;<ref>{{Cita web |url=https://blog.mozilla.org/security/2010/08/27/http-strict-transport-security/|titolo="HTTP Strict Transport Security"}}</ref> la versione 17 contiene una lista di siti che supportano HSTS.<ref name="
* [[Opera (browser)|Opera]] dalla versione 12<ref name="opera_presto">{{Cita web|url=
* [[Safari (browser)|Safari]] da [[OS X Mavericks]]<ref>@agl__ (Adam Langley).</ref>
* [[Internet Explorer 11]] su [[Windows 8.1]] e [[Windows 7]] qualora sia installato {{Cita web |url=https://support.microsoft.com/kb/3058515|titolo=KB 3058515 |postscript=nessuno}} (pubblicato nel giugno 2015).<ref>{{Cita web|url=
* [[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|urlarchivio= https://web.archive.org/web/20150629110718/https://status.modern.ie/httpstricttransportsecurityhsts|urlmorto= sì}}</ref><ref>{{Cita web |url=
== Buone norme per la messa in opera ==
Riga 78 ⟶ 76:
== Collegamenti esterni ==
* {{cita web|url=https://tools.ietf.org/wg/websec/charters|titolo=IETF WebSec Working Group|lingua=en}}▼
▲* {{cita web|https://tools.ietf.org/wg/websec/charters|IETF WebSec Working Group|lingua=en}}
* {{en}} [https://garron.net/crypto/hsts/hsts-2013.pdf The State of HSTS Deployment: A Survey and Common Pitfalls] provides an analysis of HSTS deployment statistics, patterns, mistakes, and best practices.
* {{cita web|
* {{en}} [[owasp:HTTP Strict Transport Security|Open Web Application Security Project (OWASP): HSTS description]]
* {{cita web|url=https://projects.dm.id.lv/Public-Key-Pins_test|titolo=Online browser HSTS and Public Key Pinning test|lingua=en}}
* {{en}} [https://hstspreload.appspot.com HSTS Preload Submission] for Google Chrome, Mozilla Firefox, Safari, IE 11, and Edge
Riga 91 ⟶ 88:
[[Categoria:Sicurezza informatica]]
[[Categoria:Crittografia]]
|