14. Security Considerations (Considerazioni sulla Sicurezza)

Questa specifica è principalmente una specifica di sicurezza -- essa indirizza le minacce elencate nella sezione 2.3.1 ("Threats Addressed") -- e quindi le considerazioni sulla sicurezza permeano l'intera specifica. Questa sezione riassume alcuni aspetti notevoli della sicurezza e ne solleva alcuni altri.

14.1. Underlying Secure Transport Considerations (Considerazioni sul Trasporto Sicuro Sottostante)

HSTS è essenzialmente uno strato di sicurezza che si sovrappone a HTTP -- vedere la sezione 2.3.1 ("Threats Addressed"). HSTS si basa su un trasporto sicuro di livello sottostante; tutti i requisiti, considerazioni, semantiche, ecc., di HTTP eseguito su TLS o SSL si applicano [RFC2818], compresi quelli specificati in HTTP [RFC2616] e TLS [RFC5246], [RFC4346], [RFC2246]. Vedere anche le considerazioni sulla sicurezza SSL [RFC6101].

HSTS dovrebbe utilizzare TLS versione 1.2 [RFC5246] o superiore, modulo l'attuale stato dell'arte e della pratica.

HSTS è esplicitamente orientato all'host ed è effettivamente un'associazione host-nome-a-chiave-sicura: quindi, HSTS si basa sulla certificazione basata sul nome di dominio e non funziona con forme di certificazione che non identificano l'host HSTS tramite nome di dominio. Esempi sono certificati a livello IP e certificati che omettono completamente l'identificazione. Ciò soddisfa i requisiti stabiliti nella sezione 4.3 di [RFC2818] e amplificati in "Raccomandazioni per i controlli di sicurezza del certificato del server (Recommendations for Secure Use of TLS and DTLS)" [RFC7525].

Inoltre, si noti che la funzionalità di politica HSTS descritta in questa specifica non è intesa per sostituire o eliminare la necessità della funzionalità di controllo dei certificati standard esistente negli UA. Vedere anche la sezione 8.4 ("Errors in Secure Transport Establishment") per ulteriori discussioni.

14.2. Non-Conformant User Agent Implications (Implicazioni degli Agenti Utente Non Conformi)

Gli UA che non implementano HSTS non supportano lo strato di sicurezza aggiunto che HSTS fornisce. Ciò potrebbe mascherare problemi di distribuzione del sito Web in modo tale che i distributori di HSTS potrebbero non essere consapevoli di tali problemi. Esempi di questi problemi di distribuzione sono:

• Tentativi di caricare risorse non sicure dai siti abilitati HSTS. Questo fallisce sugli UA che supportano HSTS, ma sembra riuscire sugli UA che non supportano HSTS.

• Tentativi di interagire con siti HSTS i cui certificati sono considerati non validi dagli UA conformi. Questa interazione fallisce sugli UA che supportano HSTS (in modo conforme), ma sembra riuscire sugli UA che non supportano HSTS.

Infine, gli UA non conformi non risolvono le minacce enumerate nella sezione 2.3.1 ("Threats Addressed").

14.3. Ramifications of HSTS Policy Establishment Only over Error-Free Secure Transport (Ramificazioni dell'Instaurazione della Politica HSTS Solo su Trasporto Sicuro Privo di Errori)

La politica HSTS è stabilita solo quando viene ricevuta senza errori tramite trasporto sicuro. Quindi, la politica HSTS non può essere facilmente emulata da un attaccante di rete attivo (come in un attacco "strip SSL/TLS"), solo se il sito di destinazione supporta il trasporto sicuro e gli UA non supportano HSTS.

Ad esempio, supponiamo che example.com supporti sia http che https, non supporti HSTS, e che un UA stia comunicando con esso utilizzando "http://". In questo caso, una rete-on-path-attacker può emulare con successo example.com e indurre il UA a inviare informazioni sensibili senza la consapevolezza del UA. Questo è uno scenario di attacco classico.

Tuttavia, se example.com fornisce https e adotta HSTS, un UA conforme noterebbe example.com come host HSTS conosciuto quando il UA interagisce con esso tramite trasporto sicuro. Quindi, da allora in poi, il UA insiste nell'utilizzo del trasporto sicuro con example.com. Così, l'attaccante di rete è limitato ad attaccare la comunicazione solo durante la prima interazione tra il UA e example.com. Una volta che il UA conosce example.com come host HSTS, l'attaccante "non può più" emularlo con successo (supponendo che l'attaccante non disponga di un certificato TLS valido per example.com, e supponendo che il UA supporti anche TLS).

Vedere la sezione 14.6 ("Bootstrap MITM Vulnerability") per ulteriori discussioni.

14.4. The Need for includeSubDomains (La Necessità di includeSubDomains)

Una considerazione importante è che poiché la politica HSTS è dichiarata dall'host tramite un campo di intestazione HTTP e può essere memorizzata dal UA per periodi di tempo estesi, i cookie possono diventare obsoleti nel senso che un dato host può non supportare più l'accesso sicuro (https), anche se una volta lo supportava. Ad esempio, un distributore di sito può decidere di non offrire più un servizio tramite una determinata origine host o può sospendere l'accesso sicuro per un periodo.

Se il nome di dominio dell'origine dell'host in questione è un sottodominio di un dominio padre che è un host HSTS conosciuto, e se il dominio padre asserisce includeSubDomains, gli UA devono applicare HSTS al dato host anche se tale host non ha mai emesso esso stesso una politica HSTS. Questo è richiesto per sicurezza (vedere ad esempio [WebAppSec]) affinché la politica HSTS dichiarata dall'host HSTS conosciuto copra se stessa e l'insieme di host i cui nomi di dominio sono sottodomini del nome di dominio dell'host HSTS conosciuto.

Vedere anche la sezione 11.4 ("Implications of includeSubDomains") e la sezione 14.5 ("Domain Name System (DNS) and IP Address Based Attacks") per ulteriori discussioni.

14.5. Domain Name System (DNS) and IP Address Based Attacks (Attacchi Basati su Domain Name System (DNS) e Indirizzo IP)

HSTS non può proteggere contro i compromessi DNS o IP. Una rete-on-path-attacker che può modificare le risposte DNS a un UA può indirizzare quel UA a un server arbitrario IP. Se l'attaccante è l'operatore di tale server, l'attaccante può fornire con successo dati al UA.

Tuttavia, se il UA dispone di una politica HSTS precedentemente registrata per l'host di destinazione e se l'attaccante non dispone di un certificato appropriato per questo host (ad esempio, un certificato pubblicamente attendibile che si lega correttamente al nome dell'host di destinazione), allora il UA non deve procedere con una transazione HTTP. Pertanto, anche un attacco DNS o basato su indirizzamento IP dovrebbe essere combinato con un attacco al trasporto sicuro (vedere la sezione 2.3.1 ("Threats Addressed") per ulteriori discussioni). HSTS è progettato per rendere un tale attacco combinato più difficile da eseguire con successo.

Tuttavia, questa specifica non risolve un attacco di avvelenamento della cache DNS contro l'host padre. Ad esempio, se un attaccante riuscisse ad avvelenare la cache DNS del UA (o dell'infrastruttura DNS su cui si basa) per example.com, allora il UA potrebbe non essere in grado di contattare example.com anche per rilevare una politica HSTS. Per tale attacco, soluzioni come DNSSEC [RFC4033] sono necessarie per prevenire l'avvelenamento della cache DNS.

Vedere anche la sezione 14.7 ("Creative Manipulation of HSTS Policy") e l'appendice B ("Differences between HSTS Policy and Same-Origin Policy").

14.6. Bootstrap MITM Vulnerability (Vulnerabilità Bootstrap MITM)

Un UA che implementa HSTS ma non ha ancora ricevuto una politica HSTS da un dato host è vulnerabile al seguente attacco man-in-the-middle quando il UA esegue un bootstrap HSTS, quando il UA tenta di comunicare con quel host:

1. Un attaccante di rete attivo presenta all'UA un certificato apparentemente valido per il dato host (ad esempio, è firmato da una CA di cui il UA si fida). L'attaccante è in grado di farlo perché controlla un router nella rete tra il UA e il dato host, e il router intercetta e sostituisce i messaggi.

2. Il UA crea quello che percepisce come un canale di trasporto sicuro con il dato host. Infatti, il "canale sicuro" è con l'attaccante, ma il UA è ignaro di questo attacco.

3. L'attaccante falsifica risposte apparentemente provenienti dal dato host (come se provenissero da un host HSTS), incluso un campo di intestazione STS. Pertanto, il UA annota incorrettamente il dato host come host HSTS conosciuto.

4. Gli attacchi successivi sono prevenuti finché la registrazione del dato host come host HSTS conosciuto non scade.

Questa vulnerabilità è un effetto collaterale di HSTS essenzialmente un trust-on-first-use (TOFU) [Defeating-SSL] meccanismo di sicurezza. È importante che i distributori e gli utenti di HSTS comprendano questo rischio. Tuttavia, ci sono alcune cose che i distributori e i fornitori di UA possono fare per mitigare questa vulnerabilità.

Una cosa che può essere fatta per mitigare questa preoccupazione è aumentare opportunisticamente lo schema di distribuzione HSTS host-name-a-key-binding distribuendo automaticamente politiche HSTS agli UA. Cioè, un UA può mantenere un elenco precaricato lato client di host HSTS conosciuti nel codice o nei dati configurati del UA, la cui politica HSTS è caricata e applicabile prima di qualsiasi tentativo di comunicare con tali host. Ciò proteggerebbe quegli host contro la vulnerabilità bootstrap MITM.

Un'altra cosa che può essere fatta dai distributori di HSTS per mitigare la vulnerabilità bootstrap (oltre al rischio sopra di utilizzo di nomi di dominio temporanei) è utilizzare uno schema di denominazione a dominio più stabile. Ad esempio, se il dominio padre del dato host è un host HSTS conosciuto e se il dominio padre asserisce includeSubDomains, allora il dato host stesso è dichiarato come host HSTS da quel dominio padre; quindi, il bootstrap MITM è prevenuto per il dato host anche se il UA non ha mai visitato il dato host in precedenza.

NOTA: Richiedere semplicemente che il UA forzi sempre il trasporto sicuro quando comunica con host accessibili tramite https non è una risposta; questo rompe retro-compatibilità, poiché ci sono molti siti Web accessibili tramite https ma che non funzionano correttamente con https e non possono essere considerati come host HSTS. Ad esempio, tali siti potrebbero avere certificati non validi, o il sito Web non funziona correttamente tramite https. Tali siti Web si sono adattati al ricorso dell'utente per gli avvertimenti/errori dei certificati presentati dagli UA nella corrente pratica Web.

Vedere anche [ForceHTTPS] per una discussione ulteriore su tali questioni di bootstrap.

14.7. Creative Manipulation of HSTS Policy (Manipolazione Creativa della Politica HSTS)

Un attaccante di rete che può solo osservare o manipolare DNS, ma non può manipolare il traffico HTTP o TLS tra un UA e un server, potrebbe comunque tentare di manipolare la politica HSTS rilevata dal UA cambiando o aggiungendo record DNS per gli host.

Ad esempio, supponiamo che un utente stia cercando di raggiungere un host HSTS conosciuto non HSTS dal nome di dominio "example.com" avendo un dominio padre che asserisce la direttiva includeSubDomains. L'attaccante di rete cambia temporaneamente i record DNS per "example.com" così che il nome di dominio punti a un indirizzo IP controllato dall'attaccante. Il server presso questo indirizzo IP espone una politica HSTS con un tempo di scadenza molto lungo nel futuro (ad esempio, diversi anni), oppure non è raggiungibile affatto.

In quest'ultimo caso (cioè, l'attaccante modifica semplicemente i record DNS del server in modo che non punti a nulla), nessun danno è fatto in termini di cambiamento dell'applicazione della politica HSTS. Nel primo caso, il UA otterrà e applicherà una politica HSTS per questo host (perché gli UA conformi si comportano trust-on-first-use), ma ciò non è diverso dalla situazione in cui il vero sito espone una politica HSTS per se stesso.

Inoltre, una volta che l'attaccante sostituisce i record DNS, il risultato della manipolazione dell'attaccante è sostanzialmente equivalente all'applicazione della politica HSTS dichiarata dall'host HSTS padre anche in assenza di questo schema di attacco. Questo è perché gli UA conformi richiedono la verifica dell'identità -- essenzialmente un controllo di nome di dominio -- prima di accettare e applicare qualsiasi dato campo di intestazione STS.

Tutto sommato, gli attaccanti ottengono poco o nulla da questo tipo di schema di attacco. Gli host che asseriscono includeSubDomains portano già i loro sottodomini nello spazio dei nomi HSTS (vedere la sezione 14.4 ("The Need for includeSubDomains")). Tuttavia, resta comunque importante per gli operatori host HSTS richiedere che qualsiasi certificato rilasciato per i loro domini debba essere convalidato in modo robusto attraverso domini e sottodomini da parte delle CA.

14.8. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack (Attacco Phish con Certificato CA Radice Falso più Avvelenamento della Cache DNS)

Un attacco di social engineering potrebbe cooptare gli utenti a installare un certificato CA radice falso, ad esempio tramite una campagna di phishing via e-mail. Questo, accoppiato con DNS cache poisoning, potrebbe ovviare efficacemente all'utilità di HSTS.

HSTS non può difendere contro questo tipo di attacco. Tuttavia, un elenco precaricato di host HSTS conosciuti distribuito con gli UA può aiutare a mitigare tale attacco in modo simile alla mitigazione discussa nella sezione 14.6 ("Bootstrap MITM Vulnerability").

14.9. Bogus HSTS Policy Injection (Iniezione di Politica HSTS Falsa)

Esiste il potenziale che intermediari o attaccanti malevoli possano iniettare intestazioni Strict-Transport-Security non valide in comunicazioni HTTP altrimenti sicure. La specifica indica che gli UA devono ignorare tali intestazioni se appaiono in comunicazioni HTTP ricevute tramite trasporto non sicuro. Se il requisito non viene seguito, e se il UA utilizza una tale intestazione HTTP non affidabile per impostare la politica HSTS per un dato host, allora il UA è vulnerabile a un attacco di negazione del servizio. Questo perché l'attaccante può costruire la politica HSTS in modo tale che il UA non possa in pratica stabilire una connessione sicura all'host HSTS reale (o, per quella materia, a qualsiasi altro host il cui nome di dominio corrisponde secondo la corrispondenza del nome di dominio dell'host HSTS conosciuto).

Ad esempio, l'attaccante può stabilire un tempo di scadenza lungo nel futuro e/o asserire includeSubDomains per un dominio padre tale che host realmente esistenti potrebbero non essere accessibili con successo in modo conforme a HSTS.

14.10. Internationalized Domain Names (Nomi di Dominio Internazionalizzati)

Questa specifica richiede l'uso di IDNA2008 per la canonizzazione dei nomi di dominio (vedere la sezione 8 ("User Agent Processing Model") e la sezione 10 ("Domain Name IDNA-Canonicalization")). Gli implementatori che scelgono di implementare UTS #46 per facilitare la migrazione di IDNA devono leggere e comprendere [UTS46], sezione 4.1 "Introduzione". Gli UA devono prendere decisioni politiche informate su quali nomi di dominio utilizzare. Esempi di tali decisioni politiche sono offerti nelle sezioni 4.2 e 4.3 di [UTS46].

14.11. Mixed Security Context Threats (Minacce di Contesto di Sicurezza Misto)

Gli implementatori di UA e gli operatori di siti Web HSTS dovrebbero essere consapevoli che applicazioni Web e/o implementazioni di UA che caricano o permettono il caricamento di risorse di contesto di sicurezza misto potrebbero comunque essere esposti a una varietà di potenziali attacchi attivi e passivi, nonostante l'applicazione della politica HSTS. Vedere la sezione 5 ("User Agent Guidelines") di [W3C.REC-wsc-ui-20100812] e la sezione 14.6 ("Bootstrap MITM Vulnerability").