7. Considerazioni sulla sicurezza

L'intero documento discute le pratiche di sicurezza che influenzano direttamente le applicazioni che utilizzano il protocollo TLS. Questa sezione contiene considerazioni di sicurezza più ampie relative alle tecnologie utilizzate insieme a o da TLS. Il lettore è rimandato alle sezioni Considerazioni sulla sicurezza di TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], TLS 1.2 [RFC5246] e DTLS 1.2 [RFC6347] per ulteriore contesto.

7.1. Convalida del nome host

Gli autori di applicazioni dovrebbero notare che alcune implementazioni TLS non convalidano i nomi host. Se l'implementazione TLS che utilizzano non convalida i nomi host, gli autori potrebbero dover scrivere il proprio codice di convalida o considerare l'uso di un'implementazione TLS diversa.

Si nota che i requisiti riguardanti la convalida del nome host (e, in generale, il legame tra il livello TLS e il protocollo che gira sopra di esso) variano tra i diversi protocolli. Per HTTPS, tali requisiti sono definiti dalle Sezioni 4.3.3, 4.3.4 e 4.3.5 di [RFC9110].

La convalida del nome host è critica per la sicurezza per tutti i casi d'uso comuni di TLS. Senza di essa, TLS garantisce che il certificato sia valido e garantisce il possesso della chiave privata, ma non garantisce che la connessione termini all'endpoint desiderato. I lettori sono rimandati a [RFC6125] per i dettagli riguardanti la convalida generica del nome host nel contesto TLS. Inoltre, quella RFC contiene un lungo elenco di protocolli applicativi, alcuni dei quali implementano una politica molto diversa da HTTPS.

Se il nome host viene scoperto indirettamente e in modo insicuro (ad esempio, tramite una query DNS in chiaro per un record SRV o Mail Exchange (MX)), NON DOVREBBE essere utilizzato come identificatore di riferimento [RFC6125] anche quando corrisponde al certificato presentato. Questa clausola non si applica se il nome host viene scoperto in modo sicuro (per ulteriori discussioni, vedi [RFC7673] e [RFC7672]).

La convalida del nome host si applica tipicamente solo al certificato "entità finale" foglia. Naturalmente, per garantire una corretta autenticazione nel contesto della PKI, i client applicativi devono verificare l'intero percorso di certificazione in conformità con [RFC5280].

7.2. AES-GCM

La Sezione 4.2 raccomanda l'uso dell'algoritmo di cifratura autenticato AES-GCM. Si prega di fare riferimento alla Sezione 6 di [RFC5288] per le considerazioni sulla sicurezza che si applicano specificamente ad AES-GCM quando utilizzato con TLS.

7.2.1. Riutilizzo del nonce in TLS 1.2

L'esistenza di stack TLS distribuiti che riutilizzano erroneamente il nonce AES-GCM è documentata in [Boeck2016], dimostrando che esiste un rischio reale che AES-GCM venga implementato in modo insicuro e rendendo così le sessioni TLS che utilizzano una suite di cifratura AES-GCM vulnerabili ad attacchi come [Joux2006]. (Vedi record [CVE]: CVE-2016-0270, CVE-2016-10213, CVE-2016-10212 e CVE-2017-5933.)

Sebbene questo problema sia stato risolto in TLS 1.3, che impone un metodo deterministico per generare nonce dai numeri di sequenza dei record e dai segreti condivisi per tutte le sue suite di cifratura AEAD (incluso AES-GCM), le implementazioni di TLS 1.2 potrebbero ancora scegliere i propri metodi (potenzialmente insicuri) di generazione dei nonce.

È quindi RACCOMANDATO che le implementazioni TLS 1.2 utilizzino il numero di sequenza a 64 bit per popolare la parte nonce_explicit del nonce GCM, come descritto nei primi due paragrafi della Sezione 5.3 di [RFC8446]. Questa raccomandazione più forte aggiorna la Sezione 3 di [RFC5288], che specifica che l'uso di numeri di sequenza a 64 bit per popolare il campo nonce_explicit è facoltativo.

Notiamo che, al momento della stesura, non ci sono suite di cifratura definite per algoritmi resistenti al riutilizzo del nonce come AES-GCM-SIV [RFC8452].

7.3. Forward Secrecy

La forward secrecy (chiamata anche "perfect forward secrecy" o "PFS" e definita in [RFC4949]) è una difesa contro un attaccante che registra conversazioni cifrate in cui le chiavi di sessione sono cifrate solo con le chiavi a lungo termine delle parti comunicanti.

Se l'attaccante dovesse ottenere queste chiavi a lungo termine in un secondo momento, le chiavi di sessione e quindi l'intera conversazione potrebbero essere decifrate.

Nel contesto di TLS e DTLS, tale compromissione delle chiavi a lungo termine non è del tutto inverosimile. Può verificarsi, ad esempio, a causa di:

• Un client o un server che viene attaccato da qualche altro vettore di attacco e la chiave privata viene recuperata.

• Una chiave a lungo termine recuperata da un dispositivo venduto o altrimenti dismesso senza essere stato prima ripulito.

• Una chiave a lungo termine utilizzata su un dispositivo come chiave predefinita [Heninger2012].

• Una chiave generata da una terza parte fidata come una CA e successivamente recuperata da essa tramite estorsione o compromissione [Soghoian2011].

• Una svolta crittografica o l'uso di chiavi asimmetriche con lunghezza insufficiente [Kleinjung2010].

• Attacchi di ingegneria sociale contro gli amministratori di sistema.

• Raccolta di chiavi private da backup protetti in modo inadeguato.

La forward secrecy garantisce in questi casi che non sia possibile per un attaccante determinare le chiavi di sessione anche se l'attaccante ha ottenuto le chiavi a lungo termine qualche tempo dopo la conversazione. Protegge anche contro un attaccante che è in possesso delle chiavi a lungo termine ma rimane passivo durante la conversazione.

La forward secrecy è generalmente ottenuta utilizzando lo schema Diffie-Hellman per derivare le chiavi di sessione. Lo schema Diffie-Hellman consente a entrambe le parti di mantenere segreti privati e inviare parametri sulla rete come potenze modulari su determinati gruppi ciclici. Le proprietà del cosiddetto problema del logaritmo discreto (DLP) consentono alle parti di derivare le chiavi di sessione senza che un intercettatore sia in grado di farlo. Non esiste attualmente alcun attacco noto contro DLP se vengono scelti parametri sufficientemente grandi. Una variante dello schema Diffie-Hellman utilizza curve ellittiche invece dell'aritmetica modulare proposta originariamente. Dato lo stato attuale dell'arte, l'Elliptic Curve Diffie-Hellman sembra essere più efficiente, consente lunghezze di chiave più brevi e lascia meno spazio per errori di implementazione rispetto al Finite-Field Diffie-Hellman.

Sfortunatamente, molte suite di cifratura TLS/DTLS sono state definite senza funzionalità di forward secrecy, ad esempio TLS_RSA_WITH_AES_256_CBC_SHA256. Questo documento sostiene quindi l'uso rigoroso solo di cifrari con forward secrecy.

7.4. Riutilizzo dell'esponente Diffie-Hellman

Per motivi di prestazioni, non è raro che le implementazioni TLS riutilizzino gli esponenti Diffie-Hellman e Elliptic Curve Diffie-Hellman su più connessioni. Tale riutilizzo può causare gravi problemi di sicurezza:

• Se gli esponenti vengono riutilizzati troppo a lungo (in alcuni casi, anche solo poche ore), un attaccante che ottiene l'accesso all'host può decifrare le connessioni precedenti. In altre parole, il riutilizzo dell'esponente annulla gli effetti della forward secrecy.

• Le implementazioni TLS che riutilizzano gli esponenti dovrebbero testare la chiave pubblica DH che ricevono per l'appartenenza al gruppo, al fine di evitare alcuni attacchi noti. Questi test non sono standardizzati in TLS al momento della stesura, sebbene una guida generale in quest'area sia fornita da [NIST.SP.800-56A] e disponibile in numerose implementazioni di protocollo.

• In determinate condizioni, l'uso di chiavi DH a campo finito statiche, o di chiavi DH a campo finito effimere che vengono riutilizzate su più connessioni, può portare ad attacchi temporali (come quelli descritti in [RACCOON]) sui segreti condivisi utilizzati nello scambio di chiavi Diffie-Hellman.

• Un attacco di "curva non valida" può essere montato contro Elliptic Curve DH se la vittima non verifica che il punto ricevuto si trovi sulla curva corretta. Se la vittima riutilizza i segreti DH, l'attaccante può ripetere il sondaggio variando i punti per recuperare il segreto completo (vedi [Antipa2003] e [Jager2015]).

Per affrontare queste preoccupazioni:

• Le implementazioni TLS NON DOVREBBERO utilizzare chiavi DH a campo finito statiche e NON DOVREBBERO riutilizzare chiavi DH a campo finito effimere su più connessioni.

• Le implementazioni server che desiderano riutilizzare le chiavi Elliptic Curve DH DOVREBBERO utilizzare una "curva sicura" [SAFECURVES] (ad esempio, X25519) o eseguire i controlli descritti in [NIST.SP.800-56A] sui punti ricevuti.

7.5. Revoca del certificato

Le seguenti considerazioni e raccomandazioni rappresentano lo stato attuale dell'arte per quanto riguarda la revoca dei certificati, anche se non esiste una soluzione completa ed efficiente per il problema del controllo dello stato di revoca dei comuni certificati a chiave pubblica [RFC5280]:

• La revoca del certificato è uno strumento importante nel recupero da attacchi all'implementazione TLS così come nei casi di certificati emessi in modo errato. Le implementazioni TLS DEVONO implementare una strategia per diffidare dei certificati revocati.

• Sebbene le Certificate Revocation List (CRL) siano il meccanismo più ampiamente supportato per distribuire le informazioni di revoca, presentano noti problemi di scalabilità che ne limitano l'utilità, nonostante soluzioni alternative come CRL partizionate e delta CRL. Il più moderno [CRLite] e la suite Let's Revoke [LetsRevoke] sfruttano la disponibilità dei log di Certificate Transparency [RFC9162] e una compressione aggressiva per consentire l'uso pratico dell'infrastruttura CRL, ma al momento della stesura, nessuna delle due soluzioni è distribuita per l'elaborazione della revoca lato client su larga scala.

• I meccanismi proprietari che incorporano elenchi di revoca nel database di configurazione del browser web non possono scalare oltre i pochi server web più utilizzati.

• L'Online Certification Status Protocol (OCSP) [RFC6960] nella sua forma base presenta problemi di scalabilità e privacy. Inoltre, i client tipicamente "falliscono in modo morbido" (soft-fail), il che significa che non interrompono la connessione TLS se il server OCSP non risponde. (Tuttavia, questo potrebbe essere un workaround per evitare attacchi Denial-of-Service se un risponditore OCSP viene messo offline). Per un'indagine recente sullo stato della distribuzione di OCSP nella PKI Web, vedi [Chung18].

• L'estensione TLS Certificate Status Request (Sezione 8 di [RFC6066]), comunemente nota come "graffetta OCSP" (OCSP stapling), risolve i problemi operativi con OCSP. Tuttavia, è ancora inefficace in presenza di un attaccante attivo sul percorso perché l'attaccante può semplicemente ignorare la richiesta del client per una risposta OCSP graffettata.

• [RFC7633] definisce un'estensione del certificato che indica che i client devono aspettarsi risposte OCSP graffettate per il certificato e devono interrompere l'handshake ("hard-fail") se tale risposta non è disponibile.

• L'OCSP stapling come utilizzato in TLS 1.2 non si estende ai certificati intermedi all'interno di una catena di certificati. L'estensione Multiple Certificate Status [RFC6961] affronta questa lacuna, ma ha visto poca diffusione ed era stata deprecata da [RFC8446]. Pertanto, sebbene questa estensione fosse raccomandata per TLS 1.2 in [RFC7525], non è più raccomandata da questo documento.

• TLS 1.3 (Sezione 4.4.2.1 di [RFC8446]) consente l'associazione di informazioni OCSP con certificati intermedi utilizzando un'estensione della struttura CertificateEntry. Tuttavia, l'utilizzo di questa facilità rimane poco pratico perché molte autorità di certificazione (CA) non pubblicano OCSP per i certificati CA o pubblicano report OCSP con una durata troppo lunga per essere utili.

• Sia le CRL che OCSP dipendono da una connettività relativamente affidabile a Internet, che potrebbe non essere disponibile per alcuni tipi di nodi. Un esempio comune sono i dispositivi appena approvvigionati che devono stabilire una connessione sicura per avviarsi per la prima volta.

Per i casi d'uso comuni dei certificati a chiave pubblica in TLS, i server DOVREBBERO supportare quanto segue come best practice dato lo stato attuale dell'arte e come base per una possibile soluzione futura: OCSP [RFC6960] e OCSP stapling utilizzando l'estensione status_request definita in [RFC6066]. Si noti che il meccanismo esatto per includere l'estensione status_request differisce tra TLS 1.2 e 1.3. Come questione di politica locale, gli operatori dei server POSSONO richiedere alle CA di emettere certificati must-staple [RFC7633] per il server e/oder per l'autenticazione del client, ma raccomandiamo di rivedere le condizioni operative prima di decidere su questo approccio.

Le considerazioni in questa sezione non si applicano agli scenari in cui il record di risorsa DNS-Based Authentication of Named Entities (DANE) TLSA [RFC6698] viene utilizzato per segnalare a un client quale certificato un server considera valido e buono da usare per le connessioni TLS.