HTTP Strict Transport Security: differenze tra le versioni

Versione delle 15:49, 23 nov 2015

Versione delle 18:43, 6 gen 2016

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.

Riga 28:

:<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-mechno-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"><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">{{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.

Riga 42:

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>

Riga 81:

<references/>

== ArticoliVoci correlaticorrelate ==

* [[HTTPS]]

Riga 88:

* {{en}} [[rfc:6797|RFC 6797, HTTP Strict Transport Security (HSTS)]]

* {{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.

* {{en}}cita [web|http://www.twit.tv/sn262 |Security Now 262: Strict Transport Security]|lingua=en}}

* {{en}} [[owasp:HTTP_Strict_Transport_SecurityHTTP Strict Transport Security|Open Web Application Security Project (OWASP): HSTS description]]

* {{en}}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]]

Riga 99 ⟶ 101:

[[Categoria:HTTP]]

[[Categoria:Protocolli di Internet]]

{{Portale|informatica|sicurezza informatica|telematica}}