HTTP Strict Transport Security: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Bot: passaggio degli url da HTTP a HTTPS |
m Bot: lettere e sillabe sovrannumerarie e modifiche minori |
||
Riga 14:
La prima specifica di HSTS 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">{{Cita web |url=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 dicembre 2009}}</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
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>Jeff Hodges (30 giugno 2010).</ref>
Ciononostante, l'intestazione HTTP definita dalle specifiche ha mantenuto il nome di "Strict-Transport-Security".
Riga 27:
# 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.
# 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= Collin Jackson|autore3= Adam Barth|data= novembre 2012|accesso= 21 novembre 2012}}</ref> in un
== Applicabilità ==
Riga 35:
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
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
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.
Riga 47:
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="
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>Simon Butcher (11 settembre 2011).</ref>
Riga 59:
*[[Chromium]] e [[Google Chrome]] dalla versione 4.0.211.0<ref name="chromium_sts">{{Cita web|url= https://dev.chromium.org/sts|autore= The Chromium Developers|titolo= Strict Transport Security - The Chromium Projects|data= 17 novembre 2010|accesso= 17 novembre 2010}}</ref><ref>Jeff Hodges (18 settembre 2009). {{Cita web |url=https://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1148.html|titolo="fyi: Strict Transport Security specification"}}</ref>
* [[Mozilla Firefox|Firefox]] dalla versione 4;<ref>{{Cita web |url=https://blog.mozilla.org/security/2010/08/27/http-strict-transport-security/|titolo="HTTP Strict Transport Security"}}</ref> la versione 17 contiene una lista di siti che supportano HSTS.<ref name="
* [[Opera (browser)|Opera]] dalla versione 12<ref name="opera_presto">{{Cita web|url= https://www.opera.com/docs/specs/presto2.10/#m210-244|autore= Opera Software ASA|titolo= Web specifications support in Opera Presto 2.10|data= 23 aprile 2012|accesso= 8 maggio 2012}}</ref>
* [[Safari (browser)|Safari]] da [[OS X Mavericks]]<ref>@agl__ (Adam Langley).</ref>
| |||