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 |
annullo ultime 5 modifiche Etichetta: Nowiki inseriti da dispositivo mobile |
||
Riga 1:
[[File:HTTPS icon.png|alt=Icona del lucchetto di HTTPS.|thumb|Icona del lucchetto di HTTPS.]]
'''''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 stratto [[Transport Layer Security|TLS/SSL]].</ref>.
La procedura è uno standard di Internet della [[IETF]], normato dal [[RFC]] 6797.
La politica HSTS<ref name="hsts-policy"><cite class="citation web" contenteditable="false">Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012).</cite></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 ==
Riga 13 ⟶ 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".
== 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><cite class="citation web" contenteditable="false">[https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security "HTTP Strict Transport Security"].</cite></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"><cite class="citation web" contenteditable="false">Nations, Daniel.</cite></ref> dichiara agli ''user agent'' una politica HSTS, i client che supportano il meccanismo si comportano come descritto di seguito.<ref name="hsts-no-user-recourse"><cite class="citation web" contenteditable="false">Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). </cite></ref>
# 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"/>
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= Jackson, Collin|autore3= Barth, Adam|data= November 2012|accesso= 21 novembre 2012}}</ref> in un [[Attacco man in the middle|attacco man-in-the-middle]] è molto più difficile intercettare domande e risposte tra l'utente e l'applicazione web quando il primo è in modalità HSTS rispetto alla seconda.
== 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 ==
Riga 46 ⟶ 80:
<references/>
== Voci correlate ==
* [[HTTPS]]
== Collegamenti esterni ==
* {{en}} [[rfc:6797|RFC 6797, HTTP Strict Transport Security (HSTS)]]
* {{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|http://www.twit.tv/sn262|Security Now 262: Strict Transport Security|lingua=en}}
* {{en}} [[owasp:HTTP Strict Transport Security|Open Web Application Security Project (OWASP): HSTS description]]
* {{cita web|https://projects.dm.id.lv/Public-Key-Pins_test|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{{Reflist|30em}}
{{Portale|informatica|sicurezza informatica|telematica}}
[[Categoria:Sicurezza informatica]]
[[Categoria:Crittografia]]
[[Categoria:HTTP]]
[[Categoria:Protocolli di Internet]]
| |||