HTTP Strict Transport Security: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Corretti parametri ref duplicati |
template citazione; rinomina/fix nomi parametri; converto template cite xxx -> cita xxx; fix formato data; elimino parametri vuoti |
||
Riga 31:
# 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 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"><cite class="citation web" contenteditable="false">Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). </cite></ref>
La politica HSTS aiuta a proteggere gli utenti delle applicazioni web da certi attacchi passivi (''eavesdropping'') o attivi:<ref name="hsts-threats-addressed">{{
== 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>{{
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 41:
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">{{
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.
HSTS aiuta anche a evitare il furto di credenziali di accesso a siti web basati su [[Cookie|cookie HTTP]], un attacco praticabile con strumenti facilmente disponibili, quale [[Firesheep]].<ref>{{
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 [[Network Time Protocol|NTP]] packets.<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">{{
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.
Riga 59:
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">{{
== 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">{{
* [[Mozilla Firefox|Firefox]] dalla versione 4;<ref><cite class="citation web">[https://blog.mozilla.org/security/2010/08/27/http-strict-transport-security/ "HTTP Strict Transport Security"]. </cite></ref> la versione 17 contiene una lista di siti che supportano HSTS.<ref name="preloading_hsts_mozillla"/>
* [[Opera (browser)|Opera]] dalla versione 12<ref name="opera_presto">{{
* [[Safari (browser)|Safari]] da [[OS X Mavericks]]<ref><cite class="citation web">@agl__ (Adam Langley). </cite></ref>
* [[Internet Explorer 11]] su [[Windows 8.1]] e [[Windows 7]] qualora sia installato [https://support.microsoft.com/kb/3058515 KB 3058515] (pubblicato nel giugno 2015).<ref>{{
* [[Microsoft Edge]] e [[Internet Explorer 11]] su [[Windows 10]].<ref>{{
== Buone norme per la messa in opera ==
| |||