HTTP Strict Transport Security: differenze tra le versioni

Versione delle 11:01, 14 ott 2015

Versione delle 11:09, 14 ott 2015

Riga 48:

== 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 sia veicolata usasu 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 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">{{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 conall'interno ildel browser e che lofa inducesì adche questo usareusi 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>

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 ad esempio il [[Transport Layer 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.

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>