Wikipedia

HTTP Strict Transport Security: differenze tra le versioni

Naviga nella cronologia in modo interattivo
← Differenza precedente
Contenuto cancellato Contenuto aggiunto
VisualeWikitesto
m Correzione paragrafo "Note" e tradotta una nota.
→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
 
(47 versioni intermedie di 29 utenti non mostrate)
Riga 1:
'''''HTTP Strict Transport Security''''' o '''''HSTS''''' (in italiano '''Sicurezzasicurezza 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 strattostrato [[Transport Layer Security|TLS/SSL]]. </ref>.
La procedura è uno standard di Internet della [[IETF]], normato dal [[Request for Comments|RFC]] 6797.
 
La politica HSTS<ref name="hsts-policy"><cite class="citation web" contenteditable="falseno-user-recourse">Hodges, Jeff; Jackson, Collin; Barth, Adam (Novembernovembre 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 ==
HSTS è la concretizzazione di uno degli aspetti della visione progettuale di Jeff Hodges e  Andy Steingruebl  per migliorare la sicurezza del web, e presentata nel 2010 all'interno del loro articolo 2010 intitolato  ''The Need for Coherent Web Security Policy Framework(s)''.<ref name="web-sec-policy-frmwk"><cite class="citation web" contenteditable="false">Hodges, Jeff; Steinguebl, Andy (29 Octoberottobre 2010). </cite></ref>▼
 
Le specifiche HSTS si basano sul contributo originale di Jackson e Barth descritto nell'articolo ''ForceHTTPS: Protecting High-Security Web Sites from Network Attacks''.<ref name="forcehttps-paper"><cite class="citation{{Cita web" contenteditable|url="false">[https://crypto.stanford.edu/forcehttps/ |titolo="ForceHTTPS: Protecting High-Security Web Site from Network Attacks"]. </cite>}}</ref>▼
▲HSTS è la concretizzazione di uno degli aspetti della visione progettuale di Jeff Hodges e Andy Steingruebl per migliorare la sicurezza del web, e presentata nel 2010 all'interno del loro articolo 2010 intitolato ''The Need for Coherent Web Security Policy Framework(s)''.<ref name="web-sec-policy-frmwk"><cite class="citation web" contenteditable="false">Hodges, Jeff; Steinguebl, Andy (29 October 2010). </cite></ref>
 
La prima bozza originale delle specifiche fu scritta da  Jeff Hodges<ref name="jeffhodges-ext"><cite class="citation{{Cita web" contenteditable|url="false">[http://kingsmountain.com/people/Jeff.Hodges/ |titolo="Jeff Hodges's homepage"]<span class="reference-accessdate">. </span></cite>}}</ref>  di  [[PayPal]], Collin Jackson<ref name="collinjackson-ext"><cite class="citation{{Cita web" contenteditable|url="false">[http://www.collinjackson.com/ |titolo="Collin Jackson's homepage"]<span class="reference-accessdate">. </span></cite>}}</ref>  e  Adam Barth<ref name="adambarth-ext"><cite class="citation{{Cita web" contenteditable|url="false">[http://www.adambarth.com/ |titolo="Adam Barth's homepage"]<span class="reference-accessdate">. </span></cite>}}</ref>  e pubblicata 18 settembre 2009.<ref name="draft-spec"><cite class="citation{{Cita web" contenteditable|url="false">[https://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html |titolo="Strict Transport Security -05"]. |data= 18 Septembersettembre 2009<span class="reference-accessdate">. </span></cite>}}</ref>▼
▲Le specifiche HSTS si basano sul contributo originale di Jackson e Barth descritto nell'articolo ''ForceHTTPS: Protecting High-Security Web Sites from Network Attacks''.<ref name="forcehttps-paper"><cite class="citation web" contenteditable="false">[https://crypto.stanford.edu/forcehttps/ "ForceHTTPS: Protecting High-Security Web Site from Network Attacks"]. </cite></ref>
 
La prima specifica di STSHSTS 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"><cite class="citation{{Cita web" contenteditable|url="false">[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 Decemberdicembre 2009<span class="reference-accessdate">. </span></cite>}}</ref>▼
▲La prima bozza originale delle specifiche fu scritta da Jeff Hodges<ref name="jeffhodges-ext"><cite class="citation web" contenteditable="false">[http://kingsmountain.com/people/Jeff.Hodges/ "Jeff Hodges's homepage"]<span class="reference-accessdate">. </span></cite></ref> di [[PayPal]], Collin Jackson<ref name="collinjackson-ext"><cite class="citation web" contenteditable="false">[http://www.collinjackson.com/ "Collin Jackson's homepage"]<span class="reference-accessdate">. </span></cite></ref> e Adam Barth<ref name="adambarth-ext"><cite class="citation web" contenteditable="false">[http://www.adambarth.com/ "Adam Barth's homepage"]<span class="reference-accessdate">. </span></cite></ref> e pubblicata 18 settembre 2009.<ref name="draft-spec"><cite class="citation web" contenteditable="false">[//lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html "Strict Transport Security -05"]. 18 September 2009<span class="reference-accessdate">. </span></cite></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 <ref name="hsts-ps-rfc-approval-iesg-msg"><cite class="citation{{Cita web" contenteditable|url="false">[https://www.ietf.org/mail-archive/web/websec/current/msg01401.html |titolo="&#x5B;websec&#x5D; Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)"]|data=2 ottobre 2012}}</ref>.▼
▲La prima specifica di STS 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"><cite class="citation web" contenteditable="false">[//lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html "Strict Transport Security -06"]. 18 December 2009<span class="reference-accessdate">. </span></cite></ref>
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 Junegiugno 2010).</cite></ref>▼
 
Ciononostante, l'intestazione HTTP definita dalle specifiche ha mantenuto il nome di  "Strict-Transport-Security".▼
▲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 <ref name="hsts-ps-rfc-approval-iesg-msg"><cite class="citation web" contenteditable="false">[https://www.ietf.org/mail-archive/web/websec/current/msg01401.html "&#x5B;websec&#x5D; Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)"].
2 Oct 2012<span class="reference-accessdate">. </span></cite></ref>.
▲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 nel momento in cuise emette la relativa intestazione in un messaggio di una comunicazione HTTPS (su HTTP tali intestazioni sono invece ignorate).<ref><cite class="citation{{Cita web" contenteditable|url="false">[https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security |titolo="HTTP Strict Transport Security"].</cite>}}</ref>▼
Per esempio, un server potrebbe inviare un'instestazioneintestazione che richieda che ogni richiesta a lui diretta nell'anno successivo sia trasmessa solonecessariamente contramite HTTPS.▼
In tal caso, dato che il parametro ''max-age''  è espresso in secondi e che 31.536.000 èsecondi quindisono una buona approssimazione di un anno, l'intestazione è <code>Strict-Transport-Securitysarebbe: max-age=31536000; includeSubDomains;</code>.▼
:<code>Strict-Transport-Security: max-age=31536000; includeSubDomains;</code>.
 
Quando un'applicazione web<ref name="webapp"><citeDaniel class="citation web" contenteditable="false">Nations, Daniel.</cite></ref>  dichiara agli ''user agent '' una politica HSTS, i client conformiche 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>▼
▲Un server implementa la politica HSTS nel momento in cui emette la relativa intestazione in un messaggio di una comunicazione HTTPS (su HTTP tali intestazioni sono 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>
# 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.▼
▲Per esempio, un server potrebbe inviare un'instestazione che richieda che ogni richiesta a lui diretta nell'anno successivo sia trasmessa solo con HTTPS.
# 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>▼
▲In tal caso, dato che il parametro ''max-age'' è espresso in secondi e che 31.536.000 è quindi una buona approssimazione di un anno, l'intestazione è <code>Strict-Transport-Security: max-age=31536000; includeSubDomains;</code>.
La politica HSTS aiuta a proteggere gli utenti delle applicazioni web da certi attacchi passivi (''[[eavesdropping]]'') o attivi:<ref name="hsts-threats-addressed">{{Template:CiteCita web|url = https://tools.ietf.org/html/rfc6797#section-2.3|title titolo= 2.3. Threat Model|work sito= RFC 6797|publisher editore= IETF|last cognome= Hodges|first nome= Jeff|author2 autore2= Collin Jackson, Collin|author3 autore3= Adam Barth, Adam|date data= November novembre 2012|accessdate accesso= 21 Novembernovembre 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.▼
 
▲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 conformi si comportano come descritto di seguito.<ref name="hsts-mech"><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">{{Template:Cite web|url = https://tools.ietf.org/html/rfc6797#section-2.3|title = 2.3. Threat Model|work = RFC 6797|publisher = IETF|last = Hodges|first = Jeff|author2 = Jackson, Collin|author3 = Barth, Adam|date = November 2012|accessdate = 21 November 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>{{Template:CiteCita journalpubblicazione|url = https://blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf|title titolo= New Tricks For Defeating SSL In Practice|work = }}</ref><ref>[{{Cita web |url=https://www.youtube.com/watch?v=MFol6IMbZ7Y |titolo=Defeating SSL Using Sslstrip]<span contenteditable|pubblicazione="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.
▲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>{{Template:Cite journal|url = https://blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf|title = New Tricks For Defeating SSL In Practice|work = }}</ref><ref>[https://www.youtube.com/watch?v=MFol6IMbZ7Y Defeating SSL Using Sslstrip]<span contenteditable="false"> on </span>[[YouTube]]</ref>
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">{{Template:CiteCita web|url = https://www.chromium.org/sts|author autore= Adam Langley|title titolo= Strict Transport Security|work sito= The Chromium Projects|date data= 8 Julyluglio 2010|accessdate accesso= 22 Julyluglio 2010}}</ref><ref name="preloading_hsts_mozillla"><cite class="citation web" contenteditable="falsepreloading_hsts_mozilla">David Keeler (1 Novembernovembre 2012). </cite></ref><ref name="iepreload">{{Template:CiteCita web|url = httphttps://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-to-internet-explorer.aspx|title titolo= HTTP Strict Transport Security comes to Internet Explorer|accessdate accesso= 16 Februaryfebbraio 2015|author autore= Mike Bell,|autore2= Mike;David Walp, David|date data= February 16, febbraio 2015}}</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.
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. ▼
▲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 aiuta anche a prevenireevitare il furto di credenziali di accesso a siti web basati su [[Cookie|cookie HTTP]], un attacco praticabile con strumenti facilmente disponibili, quale  [[Firesheep]].<ref>{{Template:CiteCita web|url = http://identitymeme.org/archives/2010/10/29/firesheep-and-hsts-http-strict-transport-security/|author autore= Jeff Hodges|title titolo= Firesheep and HSTS (HTTP Strict Transport Security)|date data= 31 Octoberottobre 2010|accessdate accesso= 8 Marmarzo 2011}}</ref>▼
HSTS si occupa di questo problema<ref name="hsts-threats-addressed">{{Template:Cite web|url = https://tools.ietf.org/html/rfc6797#section-2.3|title = 2.3. Threat Model|work = RFC 6797|publisher = IETF|last = Hodges|first = Jeff|author2 = Jackson, Collin|author3 = Barth, Adam|date = November 2012|accessdate = 21 November 2012}}</ref> 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">{{Template:Cite web|url = https://www.chromium.org/sts|author = Adam Langley|title = Strict Transport Security|work = The Chromium Projects|date = 8 July 2010|accessdate = 22 July 2010}}</ref><ref name="preloading_hsts_mozillla"><cite class="citation web" contenteditable="false">David Keeler (1 November 2012). </cite></ref><ref name="iepreload">{{Template:Cite web|url = http://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-to-internet-explorer.aspx|title = HTTP Strict Transport Security comes to Internet Explorer|accessdate = 16 February 2015|author = Bell, Mike; Walp, David|date = February 16, 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.
 
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>{{Template:CiteCita web|url = https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security.pdf|title titolo= Bypassing HTTP Strict Transport Security|date data= 17 ottobre 2014-10-17|accessdate accesso= 22 ottobre 2014-10-22|author autore= Jose Selvi}}</ref>▼
▲HSTS aiuta anche a prevenire il furto di credenziali di accesso a siti web basati su [[Cookie|cookie HTTP]], un attacco praticabile con strumenti facilmente disponibili, quale [[Firesheep]].<ref>{{Template:Cite web|url = http://identitymeme.org/archives/2010/10/29/firesheep-and-hsts-http-strict-transport-security/|author = Jeff Hodges|title = Firesheep and HSTS (HTTP Strict Transport Security)|date = 31 October 2010|accessdate = 8 Mar 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>{{Template:Cite web|url = https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security.pdf|title = Bypassing HTTP Strict Transport Security|date = 2014-10-17|accessdate = 2014-10-22|author = Jose Selvi}}</ref>
 
== Limiti ==
LaDi prima richiestafronte ad un'applicazioneattacchi webattivi, la presenza di HSTS non è protettain dagrado attacchidi attiviproteggere la prima richiesta ad un'applicazione web, quando essaquella usasia 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">{{Template:CiteCita web|url = https://tools.ietf.org/html/rfc6797#section-14.6|title titolo= Section 14.6. Bootstrap MITM Vulnerability|work sito= RFC 6797|publisher editore= IETF|last cognome= Hodges|first nome= Jeff|author2 autore2= Collin Jackson, Collin|author3 autore3= Adam Barth, Adam|date data= November novembre 2012|accessdate accesso= 21 Novembernovembre 2012}}</ref>▼
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="preloading_hsts_mozilla"/><ref name="iepreload"/> che è distribuito direttamente all'interno del browser e che fa sì che questo usi HTTPS anche per la prima richiesta.
Ciononostante, come precedentemente accennato, tale lista non può elencare ogni sito web presente su Internet.
 
Anche sequando provvisto di unadella «lista preliminare STS» , il meccanismo HSTS non è comunque in grado di prevenireproteggere da attacchi alloche riguardino lo stesso livello di sicurezza TLS, comequali il [[Transportad Layeresempio il Security|BEAST]] o il  CRIME  ideati daJulianoda Juliano Rizzo e Thai Duong: il mantenimento della politica HSTS è ortogonaleininfluente e irrilevante di fronte a questo generetipo di attacchi.▼
▲La prima richiesta ad un'applicazione web non è protetta da attacchi attivi, quando essa usa 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">{{Template:Cite web|url = https://tools.ietf.org/html/rfc6797#section-14.6|title = Section 14.6. Bootstrap MITM Vulnerability|work = RFC 6797|publisher = IETF|last = Hodges|first = Jeff|author2 = Jackson, Collin|author3 = Barth, Adam|date = November 2012|accessdate = 21 November 2012}}</ref>
▲Lo stesso vale per la prima richiesta 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. [[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">{{Template:Cite web|url = https://www.chromium.org/sts|author = Adam Langley|title = Strict Transport Security|work = The Chromium Projects|date = 8 July 2010|accessdate = 22 July 2010}}</ref><ref name="preloading_hsts_mozillla"><cite class="citation web" contenteditable="false">David Keeler (1 November 2012). </cite></ref><ref name="iepreload">{{Template:Cite web|url = http://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-to-internet-explorer.aspx|title = HTTP Strict Transport Security comes to Internet Explorer|accessdate = 16 February 2015|author = Bell, Mike; Walp, David|date = February 16, 2015}}</ref> che è distribuito direttamente con il browser e che lo induce ad usare HTTPS anche per la prima richiesta.
Ciononostante, come precedentemente accennato, tale lista non può elencare ogni sito web presente su Internet. Una possibile soluzione potrebbe essere realizzata usando i record [[Domain Name System|DNS]] per dichiarare la politica HSTS ed accedendo a tali informazioni col protocollo [[DNSSEC]], eventualmente avvalendosi di impronte digitali dei certificati per garantirne la validità, che a sua volta richiede un client di risoluzione DNS che verifichi quest'ultima per evitare problematiche nell'[[Ultimo miglio|ultimo miglio di connessione]].<ref><cite class="citation web" contenteditable="false">Butcher, Simon (11 September 2011). </cite></ref>
 
Per una più estesa discussione della sicurezza di HSTS, si veda il  RFC 6797.<ref name="hsts-seccons">{{Template:CiteCita web|url = https://tools.ietf.org/html/rfc6797#section-14|title titolo= Section 14. Security Considerations|work sito= RFC 6797|publisher editore= IETF|last cognome= Hodges|first nome= Jeff|author2 autore2= Collin Jackson, Collin|author3 autore3= Adam Barth, Adam|date data= November novembre 2012|accessdate accesso= 21 Novembernovembre 2012}}</ref>▼
▲Anche se provvisto di una «lista preliminare STS» , HSTS non è in grado di prevenire attacchi allo stesso livello TLS, come il [[Transport Layer Security|BEAST]] o il CRIME ideati daJuliano Rizzo e Thai Duong: il mantenimento della politica HSTS è ortogonale a questo genere di attacchi.
 
▲Per una più estesa discussione della sicurezza di HSTS, si veda il RFC 6797.<ref name="hsts-seccons">{{Template:Cite web|url = https://tools.ietf.org/html/rfc6797#section-14|title = Section 14. Security Considerations|work = RFC 6797|publisher = IETF|last = Hodges|first = Jeff|author2 = Jackson, Collin|author3 = Barth, Adam|date = November 2012|accessdate = 21 November 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|upright=1.9|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">{{Template:CiteCita web|url = https://dev.chromium.org/sts|author autore= The Chromium Developers|title titolo= Strict Transport Security - The Chromium Projects|date data= 17 Novembernovembre 2010|accessdate accesso= 17 Novembernovembre 2010}}</ref><ref><cite class="citation web" contenteditable="false">Jeff Hodges (18 Septembersettembre 2009). [http{{Cita web |url=https://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1148.html |titolo="fyi: Strict Transport Security specification"]<span class="reference-accessdate">. </span></cite>}}</ref>
* [[Mozilla Firefox|Firefox]]  dalla versione 4;<ref><cite{{Cita classweb |url="citation web">[https://blog.mozilla.org/security/2010/08/27/http-strict-transport-security/ |titolo="HTTP Strict Transport Security"]. </cite>}}</ref>  la versione 17 contiene una lista di siti che supportano  HSTS.<ref name="preloading_hsts_mozilllapreloading_hsts_mozilla"><cite class="citation web" contenteditable="false">David Keeler (1 November 2012). </cite></ref>
* [[Opera (browser)|Opera]]  dalla versione 12<ref name="opera_presto">{{Template:CiteCita web|url = httphttps://www.opera.com/docs/specs/presto2.10/#m210-244|author autore= Opera Software ASA|title titolo= Web specifications support in Opera Presto 2.10|date data= 23 Aprilaprile 2012|accessdate accesso= 8 Maymaggio 2012|urlarchivio= https://web.archive.org/web/20120504161933/http://www.opera.com/docs/specs/presto2.10/#m210-244|urlmorto= sì}}</ref>
* [[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 [ {{Cita web |url=https://support.microsoft.com/kb/3058515 |titolo=KB 3058515]  |postscript=nessuno}} (pubblicato nel giugno 2015).<ref>{{Template:CiteCita web|url = httphttps://blogs.windows.com/msedgedev/2015/06/09/http-strict-transport-security-comes-to-internet-explorer-11-on-windows-8-1-and-windows-7/|title titolo= HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7|work sito= windows.com|accessdate accesso= 12 Junegiugno 2015}}</ref>
* [[Microsoft Edge]]  e  [[Internet Explorer 11]]  su  [[Windows 10]].<ref>{{Template:CiteCita web|url = https://status.modern.ie/httpstricttransportsecurityhsts|title titolo= Internet Explorer Web Platform Status and Roadmap|accessdate accesso= 14 Aprilaprile 2014|urlarchivio= https://web.archive.org/web/20150629110718/https://status.modern.ie/httpstricttransportsecurityhsts|urlmorto= sì}}</ref><ref><cite class="citation{{Cita web" contenteditable|url="false">[httphttps://blogs.msdn.com/b/ie/archive/2015/01/22/project-spartan-and-the-windows-10-january-preview-build.aspx |titolo="Project Spartan and the Windows 10 January Preview Build - IEBlog"]<span class="reference-accessdate">. </span></cite>}}</ref>
 
== Buone norme per la messa in opera ==
 
A seconda della specifica messa in opera, certe buone norme consentono di evitare alcune minacce alla sicurezza, come gli attacchi con iniezione di cookie.
* Gli host HSTS dovrebbero dichiarare la politica HSTS nel loro nome di livello massimo: per esempio, un server in ascolto su  <nowiki>https://sub.example.com</nowiki>  dovrebbe rispondere con l'intestazione HSTS anche per richieste a <nowiki>https://example.com .</nowiki>
* Un host che serve <nowiki>https://www.example.com</nowiki>  dovrebbe aggiungere una richiesta ad una risorsa di <nowiki>https://example.com</nowiki>  , cosicché HSTS sia impostato anche per il dominio padre. In tal modo l'utente è protetto da eventuali ''cookie injection''  effettuati da un ''man-in-the-middle''  che potrebbe iniettare un riferimento verso il dominio superiore o un altro dello stesso livello  (come   <nowiki>http://nonexistentpeer.example.com</nowiki>) dove risponderebbe.
 
== Note ==
 
<references/>
 
== ArticoliVoci correlaticorrelate ==
 
* [[HTTPS]]
 
== Collegamenti esterni ==
* [{{cita web|url=https://tools.ietf.org/wg/websec/charters |titolo=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.▼
* [http{{cita web|url=https://www.twit.tv/sn262 |titolo=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]]▼
* [{{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{{Reflist|30em}}▼
 
{{Portale|informatica|sicurezza informatica|telematica}}▼
▲* [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.
* [[rfc:6797|RFC 6797, HTTP Strict Transport Security (HSTS)]]▼
▲* [https://tools.ietf.org/wg/websec/charters IETF WebSec Working Group]
▲* [http://www.twit.tv/sn262 Security Now 262: Strict Transport Security]
▲* [[owasp:HTTP_Strict_Transport_Security|Open Web Application Security Project (OWASP): HSTS description]]
▲* [https://projects.dm.id.lv/Public-Key-Pins_test Online browser HSTS and Public Key Pinning test]
▲* [https://hstspreload.appspot.com HSTS Preload Submission] for Google Chrome, Mozilla Firefox, Safari, IE 11, and Edge{{Reflist|30em}}
 
▲* [[rfcCategoria:6797|RFCHypertext 6797, HTTPTransfer Protocol|Strict Transport Security (HSTS)]]
[[Categoria:Sicurezza informatica]]
[[Categoria:Crittografia]]
[[Categoria:HTTP]]
[[Categoria:Protocolli di Internet]]
 
▲{{Portale|informatica|sicurezza informatica|telematica}}
Estratto da "https://it.wikipedia.org/wiki/HTTP_Strict_Transport_Security"