12. User Agent Implementation Advice (Consigli per l'Implementazione dell'Agente Utente)
Questa sezione è non normativa.
Per fornire una protezione più efficace agli utenti e ai siti Web, e per il controllo della gestione della loro cache delle politiche HSTS dei UA, gli implementatori di UA dovrebbero considerare di includere funzionalità come le seguenti:
12.1. No User Recourse (Nessun Ricorso dell'Utente)
Il fallimento dell'instaurazione di una connessione sicura su qualsiasi avvertimento o errore (conformemente alla sezione 8.4 ("Errors in Secure Transport Establishment")) dovrebbe essere completato con "nessun ricorso dell'utente (no user recourse)". Ciò significa che non dovrebbe essere presentata all'utente una finestra di dialogo che gli permetta di scegliere di continuare. Invece, dovrebbe assomigliare alla gestione degli errori del server, in cui l'utente non può fare nient'altro in termini di interazione con l'applicazione Web di destinazione, se non aspettare e riprovare.
Essenzialmente, "qualsiasi avvertimento o errore" significa qualsiasi cosa che farebbe sì che un'implementazione di UA annunci all'utente che qualcosa non è del tutto corretto con l'instaurazione della connessione.
Non farlo, cioè consentire il ricorso dell'utente, ad esempio "cliccare attraverso la finestra di dialogo di avvertimento/errore", è una ricetta per attacchi man-in-the-middle. Se un'applicazione Web emette una politica HSTS, allora sceglie implicitamente l'approccio "nessun ricorso dell'utente", cioè tutti gli errori o avvertimenti di certificato comportano la terminazione della connessione, senza possibilità di "ingannare" l'utente a prendere una decisione sbagliata e mettere se stesso in pericolo.
12.2. User-Declared HSTS Policy (Politica HSTS Dichiarata dall'Utente)
Una politica HSTS dichiarata dall'utente è la capacità per un utente di dichiarare esplicitamente che un dato nome di dominio rappresenta un host HSTS, seminandolo così come host HSTS conosciuto prima di qualsiasi interazione effettiva con esso. Ciò aiuterebbe a prevenire la vulnerabilità bootstrap MITM, come discusso nella sezione 14.6 ("Bootstrap MITM Vulnerability").
NOTA: Una tale funzionalità è difficile da fare correttamente su base per sito. Vedere la discussione sulle "regole di riscrittura" nella sezione 5.5 di [ForceHTTPS]. Ad esempio, un sito Web arbitrario potrebbe non concretizzare tutti i suoi URI con lo schema "https", quindi se il UA tenta di accedere esclusivamente al sito utilizzando solo tali URI, potrebbe "rompersi". Si noti anche che questa funzionalità complementerebbe, ma sarebbe indipendente dalla, funzionalità "elenco precaricato HSTS" (vedere la sezione 12.3).
12.3. HSTS Pre-Loaded List (Elenco Precaricato HSTS)
Un elenco precaricato HSTS è una struttura mediante la quale gli amministratori di siti Web possono far sì che i fornitori di UA preconfigurino la politica HSTS del loro sito in modo simile a come i certificati CA radice sono incorporati nei browser "di fabbrica" -- il cosiddetto "elenco precaricato". Ciò aiuterebbe a prevenire la vulnerabilità bootstrap MITM (sezione 14.6).
NOTA: Tale struttura complementerebbe la funzionalità "politica HSTS dichiarata dall'utente" (sezione 12.2).
12.4. Disallow Mixed Security Context Loads (Disabilitare i Caricamenti di Contesto di Sicurezza Misto)
Un caricamento di "contesto di sicurezza misto (mixed security context)" si verifica quando una risorsa di applicazione Web ottenuta da un UA tramite trasporto sicuro successivamente comporta l'ottenimento di una o più altre risorse senza utilizzare trasporto sicuro. Questo è anche comunemente chiamato un caricamento di "contenuto misto (mixed content)" (vedere la sezione 5.3 ("Mixed Content") di [W3C.REC-wsc-ui-20100812]).
NOTA: Per fornire coerenza comportamentale tra le implementazioni di UA, il concetto di contesto di sicurezza misto richiederebbe ulteriore lavoro di standardizzazione, ad esempio, definire più chiaramente i termini e definire comportamenti specifici ad esso correlati.
12.5. HSTS Policy Deletion (Eliminazione della Politica HSTS)
L'eliminazione della politica HSTS è la capacità di eliminare la politica HSTS memorizzata nella cache del UA su base per host HSTS.
NOTA: L'aggiunta di tale funzionalità dovrebbe essere fatta con molta attenzione sia nell'interfaccia utente che nel senso di sicurezza. L'eliminazione di una voce della cache di un host HSTS conosciuto dovrebbe essere un'azione molto deliberata e ponderata -- non dovrebbe essere qualcosa che gli utenti sono abituati a fare di routine: ad esempio, solo "cliccare attraverso" per portare a termine il lavoro. Inoltre, le implementazioni devono proteggersi contro la possibilità che un attaccante inietti codice (ad esempio, ECMAscript) nel UA che eliminerebbe silenziosamente e programmaticamente voci dalla cache degli host HSTS conosciuti del UA.