Versioni TLS, cipher suite e perfect forward secrecy

TLS (Transport Layer Security) è il protocollo crittografico che protegge la maggior parte delle comunicazioni Internet: HTTPS, SMTPS, IMAPS, LDAPS e le VPN si basano tutti su TLS. TLS offre tre proprietà di sicurezza: riservatezza (la crittografia impedisce l'intercettazione), integrità (il MAC impedisce le manomissioni) e autenticazione (i certificati verificano l'identità del server). TLS si è evoluto da SSL (Secure Sockets Layer), ormai deprecato. Le versioni attuali sono TLS 1.2, ampiamente distribuito, e TLS 1.3, più veloce e sicuro, consigliato per tutte le nuove implementazioni.

TLS ha attraversato diverse versioni; quelle meno recenti presentavano vulnerabilità critiche. SSL 2.0/3.0: deprecati e vulnerabili agli attacchi POODLE e DROWN. TLS 1.0: deprecato da NIST e PCI-DSS nel 2020, vulnerabile a BEAST e a POODLE con i cifrari a blocchi. TLS 1.1: deprecato insieme a TLS 1.0. TLS 1.2: standard minimo attuale, sicuro se configurato correttamente con suite di cifratura robuste. TLS 1.3: rilasciato nel 2018; rimuove tutti gli algoritmi deboli, rende obbligatoria la forward secrecy, accelera significativamente l'handshake (1-RTT anziché 2-RTT) e impedisce gli attacchi di downgrade. PCI-DSS 4.0 richiede almeno TLS 1.2 e raccomanda TLS 1.3.

Una suite di cifratura è un insieme di algoritmi crittografici utilizzati insieme in una sessione TLS. Ogni suite di cifratura specifica: un algoritmo di scambio delle chiavi (come vengono stabilite le chiavi di sessione), un algoritmo di autenticazione (come viene verificato il server), un algoritmo di cifratura bulk (che cosa cifra i dati) e un algoritmo MAC (Message Authentication Code) (come viene verificata l'integrità). Client e server negoziano la suite da utilizzare durante l'handshake TLS: il server seleziona la suite più robusta tra quelle supportate da entrambe le parti.

La fase di scambio delle chiavi stabilisce la chiave di sessione senza trasmetterla. Scambio di chiavi RSA (TLS 1.2): il client cifra un segreto premaster con la chiave pubblica del server; se in seguito la chiave privata viene compromessa, tutte le sessioni passate possono essere decifrate. DHE (Diffie-Hellman Ephemeral): genera una nuova coppia di chiavi per ogni sessione; offre la forward secrecy, ma è lento. ECDHE (Elliptic Curve DHE): offre la stessa forward secrecy di DHE, ma con chiavi più piccole e prestazioni migliori; è lo scambio di chiavi preferito sia in TLS 1.2 sia in TLS 1.3. TLS 1.3 rende obbligatorio ECDHE o DHE, eliminando completamente lo scambio di chiavi RSA.

La Perfect Forward Secrecy (PFS) garantisce che, anche se la chiave privata a lungo termine del server viene compromessa in seguito, le sessioni registrate in passato non possano essere decifrate. La PFS si ottiene usando uno scambio di chiavi effimero (ECDHE o DHE), che genera una nuova coppia di chiavi temporanea per ogni sessione e la elimina al termine dell'utilizzo. Senza PFS, con lo scambio di chiavi RSA, un aggressore può registrare oggi tutte le sessioni TLS cifrate e decifrarle retroattivamente quando riesce a ottenere la chiave privata. La strategia di sorveglianza della NSA, «raccogli ora, decifra in seguito», presuppone che gli obiettivi passeranno infine a chiavi più robuste o che i computer quantistici riusciranno a violare quelle attuali.

Diversi componenti di cifratura legacy sono compromessi dal punto di vista crittografico e devono essere disabilitati. Cifrari NULL: nessuna cifratura. Cifrari di livello export (attacco FREAK): indeboliti deliberatamente per rispettare le normative statunitensi sull'esportazione degli anni '90. RC4: cifrario a flusso con distorsioni statistiche sfruttate negli attacchi. DES e 3DES: cifrari a blocchi con dimensioni dei blocchi troppo ridotte (attacco SWEET32) o lunghezze delle chiavi insufficienti. MD5 e SHA-1 per i MAC: vulnerabilità alle collisioni. Cifrari anonimi (aNULL): nessuna autenticazione del server. Le configurazioni TLS moderne dovrebbero consentire come cifrari bulk solo AES-GCM, ChaCha20-Poly1305, AES-CCM.

TLS 1.3 introduce diversi miglioramenti significativi alla sicurezza rispetto a 1.2. PFS obbligatoria: lo scambio di chiavi RSA è stato rimosso; tutte le sessioni usano ECDHE o DHE. Meno suite di cifratura: sono consentite solo 5 suite di cifratura AEAD; non è possibile negoziare cifrari deboli. Handshake più veloce: un round trip (1-RTT) anziché 2-RTT in TLS 1.2 e 0-RTT per la ripresa della sessione, anche se 0-RTT comporta considerazioni relative agli attacchi di replay. Handshake cifrato: il certificato del server viene cifrato durante l'handshake, impedendo agli osservatori passivi di identificare il certificato e quindi il sito web a cui il client si sta connettendo.

Gli attacchi di downgrade inducono un server e un client TLS a usare una versione TLS o una suite di cifratura più vecchia e debole rispetto a quelle supportate da entrambi. POODLE (Padding Oracle On Downgraded Legacy Encryption) sfruttava il fatto che le implementazioni TLS tornassero a SSL 3.0 in caso di errori di connessione. La mitigazione consisteva nel disabilitare SSL 3.0. FREAK e Logjam sfruttavano i cifrari di livello export. TLS_FALLBACK_SCSV è una pseudo-suite di cifratura che i client includono per segnalare «questa non è la mia versione preferita»: se un server la rileva e supporta una versione superiore, interrompe il tentativo di downgrade.

L'autenticazione del server TLS si basa sulla verifica, da parte del client, della catena di certificati fino a una CA radice attendibile. Controlli fondamentali: scadenza (il certificato deve rientrare nel periodo di validità), revoca (un controllo CRL o OCSP conferma che il certificato non sia stato revocato), nome host (SAN o CN deve corrispondere al dominio a cui ci si connette) e catena delle firme (le firme della CA intermedia e della CA radice sono valide). La Certificate Transparency (CT) richiede che tutti i certificati considerati attendibili pubblicamente siano registrati in log CT append-only, consentendo di rilevare entro pochi minuti dall'emissione i certificati emessi in modo errato.

Qualys SSL Labs (ssllabs.com/ssltest) è lo strumento di riferimento per valutare la configurazione TLS di un server web. Assegna ai server una valutazione da A+ (eccellente) a F (problemi critici) in base a: versioni TLS supportate, robustezza delle suite di cifratura, validità del certificato, configurazione HSTS, supporto della forward secrecy e resistenza agli attacchi noti. Una valutazione A+ richiede: solo TLS 1.2 o versioni successive, tutti cifrari ECDHE, un certificato valido e HSTS con preload. Le organizzazioni dovrebbero eseguire i test SSL Labs dopo la configurazione iniziale e nuovamente dopo ogni modifica allo stack TLS. Molti framework di conformità, tra cui PCI-DSS, richiedono valutazioni periodiche della configurazione TLS.

I certificati TLS scaduti causano interruzioni del servizio e avvisi che compromettono la fiducia degli utenti, aspetti che gli aggressori possono sfruttare. La gestione del ciclo di vita dei certificati comprende: il monitoraggio di tutti i certificati in un inventario dei certificati, la configurazione di avvisi di scadenza almeno 30 giorni prima della scadenza, l'automazione del rinnovo con il protocollo ACME (Let's Encrypt, Certbot), l'utilizzo di certificati con validità breve (90 giorni per i certificati pubblici) per ridurre la finestra di rischio in caso di compromissione e l'uso attento dei certificati wildcard (*.example.com), poiché un certificato wildcard compromesso compromette tutti i sottodomini. Le piattaforme di gestione dei certificati (Venafi, DigiCert CertCentral) automatizzano l'individuazione e la gestione del ciclo di vita in grandi inventari di certificati.

Verificate la vostra comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione avete imparato che TLS 1.0/1.1 sono deprecati e TLS 1.2 è lo standard minimo, mentre TLS 1.3 è la versione preferita, con PFS obbligatoria e handshake cifrati; che le suite di cifratura specificano lo scambio delle chiavi (è preferibile ECDHE), la cifratura bulk (AES-GCM, ChaCha20) e gli algoritmi MAC; e che la Perfect Forward Secrecy richiede uno scambio di chiavi effimero (DHE/ECDHE), affinché le sessioni passate non possano essere decifrate nemmeno dopo la compromissione della chiave. Ora esamineremo il DNS sicuro: DNSSEC e DNS over HTTPS.