7. Considerazioni sulla sicurezza (Security Considerations)

7.1. Certificati associati (Pinned Certificates)

Come definito nella Sezione 1.8, un certificato si dice "associato" (pinned) a un nome di dominio DNS se l'utente ha esplicitamente scelto di associare il certificato del servizio con quel nome di dominio DNS nonostante il fatto che il certificato contenga altri nomi di dominio DNS (ad esempio, un utente ha esplicitamente approvato "apps.example.net" come dominio associato al dominio sorgente di "example.com"). L'associazione dei nomi memorizzata nella cache DEVE (MUST) tenere conto sia del certificato presentato che del contesto in cui è stato accettato o configurato (dove "contesto" include la catena di certificazione dal certificato presentato all'ancora di fiducia, il dominio sorgente, il tipo di servizio applicativo, e il dominio derivato e il numero di porta del servizio, nonché qualsiasi altra informazione pertinente fornita dall'utente o associata dal client).

7.2. Certificati wildcard (Wildcard Certificates)

Questo documento stabilisce che il carattere jolly '*' NON DOVREBBE (SHOULD NOT) essere incluso negli identificatori presentati ma PUÒ (MAY) essere verificato dai client applicativi (principalmente per retrocompatibilità con l'infrastruttura installata). Di conseguenza, le regole fornite in questo documento sono più restrittive delle regole di molte tecnologie applicative esistenti (come quelle estratte nell'Appendice B). Diverse considerazioni sulla sicurezza giustificano l'inasprimento delle regole:

I certificati wildcard garantiscono automaticamente qualsiasi nome host all'interno del loro dominio. Questo può essere conveniente per gli amministratori ma introduce anche il rischio di garantire per host dannosi o difettosi. Vedere ad esempio [Defeating-SSL] (iniziando dalla slide 91) e [HTTPSbytes] (slide 38-40).
Le specifiche per le tecnologie applicative esistenti non sono chiare o coerenti riguardo alle posizioni consentite per il carattere jolly, come ad esempio se può essere:
- Solo l'etichetta completa più a sinistra (ad esempio, *.example.com)
- Un frammento dell'etichetta più a sinistra (ad esempio, fo*.example.com, f*o.example.com, o *oo.example.com)
- Tutto o parte di un'etichetta diversa da quella più a sinistra (ad esempio, www.*.example.com o www.foo*.example.com)
- Tutto o parte di un'etichetta che identifica un cosiddetto "suffisso pubblico" (ad esempio, *.co.uk o *.com)
- Incluso più di una volta in una data etichetta (ad esempio, fbr.example.com)
- Incluso come intero o parte di più di un'etichetta (ad esempio, ..example.com)
Tali ambiguità possono introdurre varianze sfruttabili nel comportamento di verifica dell'identità tra le implementazioni client e possono guidare verso algoritmi di verifica dell'identità eccessivamente complessi e inefficienti.
Non esiste alcuna specifica che definisca come il carattere jolly possa essere incorporato in un'A-label o U-label [IDNA-DEFS] di un nome di dominio internazionalizzato [IDNA-PROTO]; di conseguenza, le implementazioni sono fortemente scoraggiate dall'includere o tentare di verificare caratteri jolly incorporati in un'A-label o U-label di un nome di dominio internazionalizzato (ad esempio, "xn--kcry6tjko*.example.org"). Si noti, tuttavia, che un identificatore di nome di dominio presentato PUÒ (MAY) contenere il carattere jolly purché tale carattere occupi l'intera posizione dell'etichetta più a sinistra dove tutte le etichette rimanenti sono etichette NR-LDH, A-labels o U-labels valide (ad esempio, "*.xn--kcry6tjko.example.org").

Nonostante le precedenti considerazioni sulla sicurezza, una specifica che riutilizza questa specifica può legittimamente incoraggiare il supporto continuato del carattere jolly se ci sono buone ragioni per farlo, come la retrocompatibilità con l'infrastruttura installata (vedere ad esempio [EV-CERTS]).

7.3. Nomi di dominio internazionalizzati (Internationalized Domain Names)

Consentire i nomi di dominio internazionalizzati può portare all'inclusione di caratteri visivamente simili (cosiddetti "confondibili") nei certificati; per una discussione, vedere ad esempio [IDNA-DEFS].

7.4. Identificatori multipli (Multiple Identifiers)

Un dato servizio applicativo potrebbe essere indirizzabile da più nomi di dominio DNS per vari motivi, e una data distribuzione potrebbe servire più domini (ad esempio, nei cosiddetti ambienti di "hosting virtuale"). L'uso di identificatori multipli è gestito come segue:

Nello scambio di handshake TLS predefinito, il client non è in grado di specificare il nome di dominio DNS con cui desidera contattare, e il server TLS restituisce solo un certificato che è il proprio. Senza estensioni a TLS, la soluzione tipica utilizzata per facilitare la mappatura dei servizi applicativi a più nomi di dominio DNS è incorporare tutti i nomi di dominio in un unico certificato.

Un approccio più recente (formalizzato in [TLS-EXT]) prevede che il client specifichi il nome di dominio DNS che si aspetta o desidera per il servizio utilizzando l'estensione TLS "Server Name Indication" (SNI) quando invia il messaggio client_hello. Il servizio può quindi restituire il certificato appropriato nel suo messaggio Certificate, e quel certificato può rappresentare un singolo nome di dominio DNS.

Al fine di accogliere la soluzione necessaria prima dello sviluppo dell'estensione SNI, questa specifica consente la presenza di più DNS-ID, SRV-ID o URI-ID in un certificato; tuttavia, scoraggia esplicitamente più CN-ID. Sebbene sarebbe desiderabile vietare completamente più CN-ID, ci sono diversi motivi per cui questa specifica attualmente stabilisce che NON DOVREBBERO (SHOULD NOT) (invece di NON DEVONO (MUST NOT)) essere inclusi:

Almeno una comunità di interesse tecnico significativo consente esplicitamente più CN-ID [EV-CERTS].
È noto che almeno una significativa autorità di certificazione emette certificati contenenti più CN-ID.
Molti fornitori di servizi spesso considerano necessario includere più CN-ID in ambienti di hosting virtuale perché almeno un sistema operativo ampiamente diffuso non supporta ancora l'estensione SNI.

Si auspica che la raccomandazione riguardante più CN-ID venga ulteriormente rafforzata in futuro.