Wikipedia

HTTP Strict Transport Security

procedura per implementare la sicurezza delle comunicazioni web proteggendo il canale HTTPS e per evitare dirottamenti di sessione
Versione del 5 nov 2020 alle 22:12 di 91.80.25.94 (discussione)

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).[1]

Le specifiche HSTS si basano sul contributo originale di Jackson e Barth descritto nell'articolo ForceHTTPS: Protecting High-Security Web Sites from Network Attacks.[2]

La prima bozza originale delle specifiche fu scritta da Jeff Hodges[3] di PayPal, Collin Jackson[4] e Adam Barth[5] e pubblicata 18 settembre 2009.[6]

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.[7]

In seguito all'approvazione del 2 ottobre 2012 da parte dell'IESG, la specifica di HSTS è stata pubblicata come RFC Proposed Standard (standard proposto) il 19 novembre 2012 nel RFC 6797[8]. La prima versione originale del documento fu però depositata già il 17 giugno 2010 come Internet-Draft, momento nel quale il titolo della specifica fu cambiato da "Strict Transport Security" (STS) al più preciso "HTTP Strict Transport Security".[9] 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).[10] 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:

Strict-Transport-Security: max-age=31536000; includeSubDomains;.

Quando un'applicazione web[11] dichiara agli user agent una politica HSTS, i client che supportano il meccanismo si comportano come descritto di seguito.[12]

  1. Ogni collegamento non sicuro è trasformato in un collegamento sicuro, cioè, per esempio, http://example.com/some/page/ è modificato in https://example.com/some/page/ prima che tale risorsa venga utilizzata.
  2. Se la sicurezza della connessione non è considerata affidabile, ad esempio se il certificato TLS non è tale, un messaggio d'errore è mostrato all'utente e l'accesso all'applicazione web è impedito.[12]

La politica HSTS aiuta a proteggere gli utenti delle applicazioni web da certi attacchi passivi (eavesdropping) o attivi:[13] in un 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 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.[14][15] Questo attacco consiste nel convertire silenziosamente una connessione HTTP sicura, appoggiata a SSL o a 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[13] 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.[16][17][18] Nel prossimo paragrafo 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 HTTP, un attacco praticabile con strumenti facilmente disponibili, quale Firesheep.[19]

Dato che HSTS ha limiti temporali, il protocollo è sensibile ad attacchi che prevedono di spostare l'orologio della vittima, per esempio inviando falsi pacchetti NTP.[20]

Supporto da parte dei browser

 
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.

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 https://sub.example.com dovrebbe rispondere con l'intestazione HSTS anche per richieste a https://example.com .
  • Un host che serve https://www.example.com dovrebbe aggiungere una richiesta ad una risorsa di https://example.com , 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 http://nonexistentpeer.example.com) dove risponderebbe.

Note

  1. ^ Hodges, Jeff; Steinguebl, Andy (29 ottobre 2010).
  2. ^ "ForceHTTPS: Protecting High-Security Web Site from Network Attacks", su crypto.stanford.edu.
  3. ^ "Jeff Hodges's homepage", su kingsmountain.com.
  4. ^ "Collin Jackson's homepage", su collinjackson.com.
  5. ^ "Adam Barth's homepage", su adambarth.com.
  6. ^ "Strict Transport Security -05", su lists.w3.org, 18 settembre 2009.
  7. ^ "Strict Transport Security -06", su lists.w3.org, 18 dicembre 2009.
  8. ^ "[websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)", su ietf.org, 2 ottobre 2012.
  9. ^ Jeff Hodges (30 giugno 2010).
  10. ^ "HTTP Strict Transport Security", su developer.mozilla.org.
  11. ^ Daniel Nations
  12. ^ a b Errore nelle note: Errore nell'uso del marcatore <ref>: non è stato indicato alcun testo per il marcatore hsts-no-user-recourse
  13. ^ a b Jeff Hodges, Collin Jackson e Adam Barth, 2.3. Threat Model, su RFC 6797, IETF, novembre 2012. URL consultato il 21 novembre 2012.
  14. ^ New Tricks For Defeating SSL In Practice (PDF).
  15. ^ Defeating SSL Using Sslstrip, in YouTube.
  16. ^ Adam Langley, Strict Transport Security, su The Chromium Projects, 8 luglio 2010. URL consultato il 22 luglio 2010.
  17. ^ a b David Keeler (1 novembre 2012).
  18. ^ Mike Bell e David Walp, HTTP Strict Transport Security comes to Internet Explorer, su blogs.msdn.com, 16 febbraio 2015. URL consultato il 16 febbraio 2015.
  19. ^ Jeff Hodges, Firesheep and HSTS (HTTP Strict Transport Security), su identitymeme.org, 31 ottobre 2010. URL consultato l'8 marzo 2011.
  20. ^ Jose Selvi, Bypassing HTTP Strict Transport Security (PDF), su blackhat.com, 17 ottobre 2014. URL consultato il 22 ottobre 2014.
  21. ^ The Chromium Developers, Strict Transport Security - The Chromium Projects, su dev.chromium.org, 17 novembre 2010. URL consultato il 17 novembre 2010.
  22. ^ Jeff Hodges (18 settembre 2009). "fyi: Strict Transport Security specification", su lists.w3.org.
  23. ^ "HTTP Strict Transport Security", su blog.mozilla.org.
  24. ^ Opera Software ASA, Web specifications support in Opera Presto 2.10, su opera.com, 23 aprile 2012. URL consultato l'8 maggio 2012 (archiviato dall'url originale il 4 maggio 2012).
  25. ^ @agl__ (Adam Langley).
  26. ^ HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7, su windows.com. URL consultato il 12 giugno 2015.
  27. ^ Internet Explorer Web Platform Status and Roadmap, su status.modern.ie. URL consultato il 14 aprile 2014.
  28. ^ "Project Spartan and the Windows 10 January Preview Build - IEBlog", su blogs.msdn.com.

Voci correlate

Collegamenti esterni

  Portale Sicurezza informatica
Estratto da "https://it.wikipedia.org/w/index.php?title=HTTP_Strict_Transport_Security&oldid=116474969"