HTTP Strict Transport Security: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica
Etichette: Modifica da mobile Modifica da web per mobile
Nessun oggetto della modifica
Etichette: Modifica da mobile Modifica da web per mobile
Riga 20:
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".
 
== 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>[https://www.youtube.com/watch?v=MFol6IMbZ7Y Defeating SSL Using Sslstrip]<span contenteditable="false"> on </span>[[YouTube]]</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.
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 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"><cite class="citation web" contenteditable="false">David Keeler (1 November 2012). </cite></ref><ref name="iepreload">{{Cita web|url= http://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-to-internet-explorer.aspx|titolo= HTTP Strict Transport Security comes to Internet Explorer|accesso= 16 febbraio 2015|autore= Bell, Mike; Walp, David|data= 16 febbraio 2015}}</ref>
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>{{Cita web|url= http://identitymeme.org/archives/2010/10/29/firesheep-and-hsts-http-strict-transport-security/|autore= Jeff Hodges|titolo= Firesheep and HSTS (HTTP Strict Transport Security)|data= 31 ottobre 2010|accesso= 8 marzo 2011}}</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>{{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 ==