11. Server Implementation and Deployment Advice (Consigli per l'Implementazione e la Distribuzione del Server)

Questa sezione è non normativa.

11.1. Non-Conformant User Agent Considerations (Considerazioni sugli Agenti Utente Non Conformi)

I UA non conformi ignorano il campo di intestazione Strict-Transport-Security; pertanto, gli agenti utente non conformi non risolvono le minacce descritte nella sezione 2.3.1 ("Threats Addressed"). Vedere la sezione 14.2 ("Non-Conformant User Agent Implications") per ulteriori discussioni.

11.2. HSTS Policy Expiration Time Considerations (Considerazioni sul Tempo di Scadenza della Politica HSTS)

Le implementazioni dei server e le distribuzioni dei siti Web devono considerare se impostare il tempo di scadenza su un valore costante nel futuro, o su un punto fisso nel tempo.

L'approccio "valore costante nel futuro" può essere realizzato inviando continuamente lo stesso valore max-age agli UA.

Ad esempio, un valore max-age di 7776000 secondi corrisponde a 90 giorni:

Strict-Transport-Security: max-age=7776000

Si noti che il UA dovrà aggiornare la sua nozione del momento in cui deve eliminare la sua conoscenza di questo host HSTS conosciuto ogni volta che riceve questo campo di intestazione.

L'approccio "punto fisso nel tempo" può essere realizzato inviando un valore max-age che rappresenta il tempo rimanente fino al tempo di scadenza desiderato. Ciò richiederà che l'host HSTS invii un valore max-age appena calcolato in ogni risposta HTTP.

Una considerazione qui è se i distributori desiderano far corrispondere il tempo di scadenza della politica HSTS segnalata con il tempo di scadenza del certificato del nome di dominio del sito Web.

Inoltre, gli implementatori di server dovrebbero considerare l'utilizzo di un valore max-age predefinito pari a zero nei loro sistemi di configurazione di distribuzione. Ciò costringerebbe i distributori a impostare intenzionalmente max-age affinché i UA applichino la politica HSTS per i loro host, e li proteggerebbe dall'attivazione involontaria di HSTS con una durata arbitraria non zero.

11.3. Using HSTS in Conjunction with Self-Signed Public-Key Certificates (Utilizzo di HSTS in Combinazione con Certificati a Chiave Pubblica Autofirmati)

Se tutte le seguenti quattro condizioni sono vere...

• Un sito Web/organizzazione/azienda sta generando i propri certificati a chiave pubblica di trasporto sicuro per il sito Web, e

• Il certificato CA radice di tale organizzazione normalmente non è incorporato per impostazione predefinita negli archivi di certificati CA dei browser e/o del sistema operativo, e

• La politica HSTS è abilitata sugli host che si identificano con certificati firmati dalla CA dell'organizzazione (cioè, "certificati autofirmati"), e

• Questo certificato non corrisponde alle associazioni di certificati TLS disponibili (come definito nella sezione 4 della specifica del protocollo TLSA [RFC6698]),

...allora, per progettazione HSTS, le connessioni sicure a quel sito falliranno. Questo serve a prevenire vari attacchi attivi, come discusso sopra.

Tuttavia, se l'organizzazione desidera utilizzare la propria CA e certificati autofirmati in combinazione con HSTS, può farlo distribuendo il suo certificato CA radice negli archivi di certificati CA radice dei browser o dei sistemi operativi dei suoi utenti. Può anche distribuire in aggiunta o in alternativa certificati di entità finale specifici dell'host ai browser dei suoi utenti. Ci sono diversi modi per realizzare ciò (i dettagli vanno oltre lo scopo di questa specifica). Una volta che il suo certificato CA radice è installato nei browser, può utilizzare la politica HSTS sui suoi siti.

In alternativa, l'organizzazione può distribuire il protocollo TLSA; tutti i browser che utilizzano anche TLSA potranno fidarsi dei certificati identificati dalle associazioni di certificati TLS disponibili rappresentate tramite TLSA.

NOTA: Distribuire interattivamente i certificati CA radice agli utenti, ad esempio tramite e-mail, e far installare loro gli utenti potrebbe essere considerato come addestrare gli utenti a essere vulnerabili a una possibile forma di attacco di phishing. Vedere la sezione 14.8 ("Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack"). Pertanto, occorre prestare attenzione al modo in cui tali certificati vengono distribuiti e installati sui sistemi e sui browser degli utenti.

11.4. Implications of includeSubDomains (Implicazioni di includeSubDomains)

La direttiva includeSubDomains ha implicazioni pratiche che meritano un'attenta considerazione; due scenari di esempio sono:

• Un host HSTS offre servizi basati su HTTP non sicuri su porte alternative o vari sottodomini del suo nome di dominio host HSTS.

• Diverse applicazioni Web sono offerte su diversi sottodomini dell'host HSTS, in modo tale che i UA generalmente interagiscono direttamente con queste applicazioni Web di sottodominio, senza necessariamente interagire con l'applicazione Web offerta sul nome di dominio dell'host HSTS (se presente).

Le sottosezioni seguenti discutono ciascuno di questi scenari a turno.

Per i dettagli completi, vedere RFC 6797.