HTTP Strict Transport Security: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Riga 29:
Quando un'applicazione web<ref name="webapp"><cite class="citation web" contenteditable="false">Nations, Daniel.</cite></ref> dichiara agli ''user agent'' una politica HSTS, i client che supportano il meccanismo si comportano come descritto di seguito.<ref name="hsts-no-user-recourse"><cite class="citation web" contenteditable="false">Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). </cite></ref>
# 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= Jackson, Collin|autore3= Barth, Adam|data= November 2012|accesso= 21 novembre 2012}}</ref> in un [[Attacco man in the middle|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.
|