Appendice B. Arte anteriore (Prior Art)

(Questa sezione è non normativa.)

Le raccomandazioni di questo documento astraggono dalle raccomandazioni delle specifiche per un'ampia gamma di protocolli applicativi. A scopo di confronto e per delineare la storia del pensiero all'interno dell'IETF riguardante la verifica dell'identità del servizio applicativo, questa sezione informativa raccoglie l'arte anteriore includendo il testo esatto di vari RFC (gli unici cambiamenti sono alcuni cambi di nome di riferimento per coerenza con il corpo di questo documento e l'omissione di testo irrilevante contrassegnato dai caratteri "[...]").

B.1. IMAP, POP3 e ACAP (1999)

Nel 1999, [USINGTLS] ha specificato il seguente testo riguardante la verifica dell'identità del servizio applicativo in IMAP, POP3 e ACAP.

2.4. Verifica dell'identità del server (Server Identity Check)

Durante la negoziazione TLS, il client DEVE (MUST) confrontare la sua comprensione del nome host del server contro l'identità del server comunicata nel messaggio Certificate del server, al fine di prevenire attacchi man-in-the-middle. Il confronto viene eseguito secondo le seguenti regole:

Il client DEVE (MUST) utilizzare il nome host del server che ha utilizzato per aprire la connessione come valore da confrontare con il nome del server espresso nel certificato server. Il client NON DEVE (MUST NOT) utilizzare alcuna forma del nome host del server derivata da una fonte remota non sicura (ad esempio, un lookup DNS non sicuro). La canonizzazione CNAME non viene eseguita.

Se un'estensione subjectAltName di tipo dNSName è presente nel certificato, DOVREBBE (SHOULD) essere utilizzata come fonte dell'identità del server.

Il confronto è insensibile alle maiuscole/minuscole.

Il carattere jolly "*" PUÒ (MAY) essere utilizzato come componente nome più a sinistra nel certificato. Ad esempio, *.example.com corrisponderebbe a a.example.com, foo.example.com, ecc., ma non a example.com.

Se il certificato contiene più nomi (ad esempio, più di un campo dNSName), allora una corrispondenza con uno qualsiasi di questi campi è considerata accettabile.

Se il confronto fallisce, il client DOVREBBE (SHOULD) richiedere una conferma esplicita dell'utente o terminare la connessione e indicare che l'identità del server è sospetta.

B.2. HTTP (2000)

Nel 2000, [HTTP-TLS] ha specificato il seguente testo riguardante la verifica dell'identità del servizio applicativo in HTTP.

3.1. Identità del server (Server Identity)

In generale, le richieste HTTP/TLS sono generate dereferenziando un URI. Di conseguenza, il nome host del server è noto al client. Se il nome host è disponibile, il client DEVE (MUST) verificarlo rispetto all'identità del server presentata nel messaggio Certificate del server, al fine di prevenire attacchi man-in-the-middle.

Se il client ha informazioni esterne riguardo all'identità attesa del server, la verifica del nome host PUÒ (MAY) essere omessa. (Ad esempio, un client potrebbe connettersi a una macchina il cui indirizzo e nome host sono dinamici, ma il client conosce il certificato che il server presenterà.) In tali casi, è importante restringere l'ambito dei certificati accettabili il più possibile al fine di prevenire attacchi man-in-the-middle. In casi speciali, può essere appropriato per il client ignorare semplicemente l'identità del server, ma deve essere compreso che ciò lascia la connessione aperta ad attacchi attivi.

Se un'estensione subjectAltName di tipo dNSName è presente, DEVE (MUST) essere utilizzata come identità. Altrimenti, il campo Common Name (più specifico) nel campo Subject del certificato DEVE (MUST) essere utilizzato. Sebbene l'uso del Common Name sia pratica esistente, è deprecato e le autorità di certificazione sono incoraggiate a utilizzare invece il dNSName.

Il confronto viene eseguito utilizzando le regole di confronto specificate da [PKIX-OLD]. Se è presente più di un'identità di un dato tipo nel certificato (ad esempio, più di un nome dNSName), una corrispondenza in uno qualsiasi dell'insieme è considerata accettabile. I nomi possono contenere il carattere jolly * che è considerato corrispondere a qualsiasi singolo componente nome di dominio o frammento di componente. Es. .a.com corrisponde a foo.a.com ma non a bar.foo.a.com. f.com corrisponde a foo.com ma non a bar.com.

In alcuni casi, l'URI è specificato come un indirizzo IP invece di un nome host. In questo caso, il subjectAltName iPAddress deve essere presente nel certificato e deve corrispondere esattamente all'IP nell'URI.

Se il nome host non corrisponde all'identità nel certificato, i client orientati all'utente DEVONO (MUST) notificare l'utente (i client POSSONO (MAY) dare all'utente l'opportunità di continuare la connessione in ogni caso) o terminare la connessione con un errore di certificato errato. I client automatizzati DEVONO (MUST) registrare l'errore in un registro di controllo appropriato (se disponibile) e DOVREBBERO (SHOULD) terminare la connessione (con un errore di certificato errato). I client automatizzati POSSONO (MAY) fornire un'impostazione di configurazione per disabilitare questo controllo, ma DEVONO (MUST) fornire un'impostazione per abilitarlo.

Si noti che in molti casi l'URI stesso proviene da una fonte non affidabile. Il controllo di cui sopra non fornisce alcuna protezione contro attacchi in cui questa fonte è compromessa. Ad esempio, se l'URI è stato ottenuto cliccando su una pagina HTML che non era essa stessa ottenuta tramite HTTP/TLS, un man-in-the-middle potrebbe aver sostituito l'URI. Al fine di prevenire questa forma di attacco, gli utenti dovrebbero esaminare attentamente il certificato presentato dal server per determinare se soddisfa le loro aspettative.

B.3. LDAP (2000/2006)

Nel 2000, [LDAP-TLS] ha specificato il seguente testo riguardante la verifica dell'identità del servizio applicativo in LDAP.

3.6. Verifica dell'identità del server (Server Identity Check)

Il client DEVE (MUST) confrontare la sua comprensione del nome host del server contro l'identità del server presentata nel messaggio Certificate del server al fine di prevenire attacchi man-in-the-middle.

Il confronto viene eseguito secondo le seguenti regole:

Il client DEVE (MUST) utilizzare il nome host del server che ha utilizzato per aprire la connessione LDAP come valore da confrontare con il nome del server espresso nel certificato server. Il client NON DEVE (MUST NOT) utilizzare il nome canonico DNS del server o qualsiasi altra forma derivata del nome.

Se un'estensione subjectAltName di tipo dNSName è presente nel certificato, DOVREBBE (SHOULD) essere utilizzata come fonte dell'identità del server.

Il confronto è insensibile alle maiuscole/minuscole.

Il carattere jolly "*" è consentito. Se presente, si applica solo al componente nome più a sinistra.

Ad esempio, *.bar.com corrisponderebbe a a.bar.com, b.bar.com, ecc., ma non a bar.com. Se è presente più di un'identità di un dato tipo nel certificato (ad esempio, più di un nome dNSName), una corrispondenza in uno qualsiasi dell'insieme è considerata accettabile.

Se il nome host non corrisponde all'identità basata su dNSName nel certificato secondo il controllo di cui sopra, i client orientati all'utente DOVREBBERO (SHOULD) notificare l'utente (i client possono dare all'utente l'opportunità di continuare la sessione LDAP in questo caso) o terminare la connessione e indicare che l'identità del server è sospetta. I client automatizzati DOVREBBERO (SHOULD) chiudere la connessione e restituire e/o registrare un errore indicando che l'identità del server è sospetta.

Oltre alla verifica dell'identità del server descritta in questa sezione, i client DOVREBBERO (SHOULD) essere pronti a fare ulteriori controlli per garantire che il server sia autorizzato a fornire il servizio che si osserva fornire. Il client PUÒ (MAY) dover utilizzare informazioni sui criteri locali.

Nel 2006, [LDAP-AUTH] ha specificato il seguente testo riguardante la verifica dell'identità del servizio applicativo in LDAP.

3.1.3. Verifica dell'identità del server (Server Identity Check)

Al fine di prevenire attacchi man-in-the-middle, il client DEVE (MUST) verificare l'identità del server (come presentata nel messaggio Certificate del server). In questa sezione, la comprensione del client dell'identità del server (tipicamente l'identità utilizzata per stabilire la connessione di trasporto) è chiamata "identità di riferimento" (reference identity).

Il client determina il tipo (ad esempio, nome DNS o indirizzo IP) dell'identità di riferimento ed esegue un confronto tra l'identità di riferimento e ciascun valore subjectAltName del tipo corrispondente fino a quando non viene prodotta una corrispondenza. Una volta prodotta una corrispondenza, l'identità del server è stata verificata e la verifica dell'identità del server è completa. Diversi tipi di subjectAltName vengono confrontati in modi diversi. Le Sezioni 3.1.3.1 - 3.1.3.3 dettagliano come confrontare i valori di vari tipi di subjectAltName.

Il client può mappare l'identità di riferimento in un altro tipo prima di eseguire il confronto. La mappatura può essere eseguita per qualsiasi tipo di subjectAltName disponibile in cui l'identità di riferimento può essere mappata. Tuttavia, l'identità di riferimento dovrebbe essere mappata solo in tipi per i quali la mappatura è intrinsecamente sicura (ad esempio, estraendo un nome DNS da un URI per il confronto con un subjectAltName di tipo dNSName) o eseguita in modo sicuro (ad esempio, utilizzando [DNSSEC] o utilizzando una tabella di lookup host-to-address/address-to-host configurata dall'utente o dall'amministratore).

L'identità del server può anche essere verificata confrontando l'identità di riferimento con il valore Common Name (CN) [LDAP-SCHEMA] nell'ultimo Relative Distinguished Name (RDN) del campo Subject del certificato server (dove "ultimo" si riferisce all'ordine di codifica DER, non all'ordine di presentazione in una rappresentazione stringa dei dati codificati DER). Questo confronto viene eseguito utilizzando le regole per il confronto dei nomi DNS nella Sezione 3.1.3.1 di seguito, con l'eccezione che non è consentita alcuna corrispondenza jolly. L'uso del valore Common Name è pratica esistente ma è deprecato, e le autorità di certificazione sono incoraggiate a utilizzare invece valori subjectAltName. Si noti che le implementazioni TLS possono rappresentare i DN nei certificati secondo X.500 o altre convenzioni. Ad esempio, alcune implementazioni X.500 ordinano gli RDN in un DN utilizzando una convenzione da sinistra a destra (dal più significativo al meno significativo) invece della convenzione LDAP da destra a sinistra.

Se la verifica dell'identità del server fallisce, i client orientati all'utente DOVREBBERO (SHOULD) notificare l'utente (i client possono dare all'utente l'opportunità di continuare la sessione LDAP in questo caso) o chiudere la connessione di trasporto e indicare che l'identità del server è sospetta. I client automatizzati DOVREBBERO (SHOULD) chiudere la connessione di trasporto e restituire e/o registrare un errore indicando che l'identità del server è sospetta.

Oltre alla verifica dell'identità del server descritta in questa sezione, i client dovrebbero essere pronti a fare ulteriori controlli per garantire che il server sia autorizzato a fornire il servizio che è richiesto di fornire. Il client potrebbe dover utilizzare informazioni sui criteri locali per prendere questa determinazione.

3.1.3.1. Confronto di nomi DNS (Comparison of DNS Names)

Se l'identità di riferimento è un nome di dominio internazionalizzato, le implementazioni conformi DEVONO (MUST) convertirlo nel formato ASCII Compatible Encoding (ACE) come specificato nella Sezione 4 della RFC 3490 [IDNA2003] prima del confronto con i valori subjectAltName di tipo dNSName. Nello specifico, le implementazioni conformi DEVONO (MUST) eseguire l'operazione di conversione specificata nella Sezione 4 della RFC 3490 come segue:

nel passaggio 1, il nome di dominio DOVRÀ (SHALL) essere considerato una "stringa memorizzata";

nel passaggio 3, impostare il flag chiamato "UseSTD3ASCIIRules";

nel passaggio 4, elaborare ogni etichetta con l'operazione "ToASCII"; e

nel passaggio 5, cambiare tutti i separatori di etichetta in U+002E (punto).

Dopo aver eseguito la conversione "ToASCII", le etichette DNS e i nomi DEVONO (MUST) essere confrontati per uguaglianza secondo le regole specificate nella Sezione 3 della RFC 3490.

Il carattere jolly '*' (ASCII 42) è consentito nei valori subjectAltName di tipo dNSName, e solo come etichetta DNS più a sinistra (meno significativa) in quel valore. Questo carattere jolly corrisponde a qualsiasi singola etichetta DNS più a sinistra nel nome del server. Cioè, il soggetto *.example.com corrisponde al nome server a.example.com e b.example.com, ma non a example.com o a.b.example.com.

3.1.3.2. Confronto di indirizzi IP (Comparison of IP Addresses)

Se l'identità di riferimento è un indirizzo IP, l'identità DEVE (MUST) essere convertita in una stringa di ottetti in "ordine di byte di rete" [IP] [IPv6]. Per IP Versione 4, come specificato in RFC 791, la stringa di ottetti conterrà esattamente 4 ottetti. Per IP Versione 6, come specificato in RFC 2460, la stringa di ottetti conterrà esattamente 16 ottetti. Questa stringa di ottetti viene quindi confrontata con i valori subjectAltName di tipo iPAddress. Una corrispondenza si verifica se l'identità di riferimento (stringa di ottetti) e il valore (stringa di ottetti) sono identici.

3.1.3.3. Confronto di altri tipi di subjectName (Comparison of Other subjectName Types)

Le implementazioni client POSSONO (MAY) supportare la corrispondenza con altri tipi di valori subjectAltName come descritto in altri documenti.