LEZIONE 09 · PROTEGGERE IL CANALE
Concordare un segreto senza spedirlo
Diffie–Hellman permette a due partecipanti di ricavare un segreto comune scambiando valori pubblici. Da solo non dimostra con chi lo stai condividendo.
- Chi?
- Un client, cioè il programma che richiede un servizio, e un server, cioè quello che lo offre.
- Che cosa?
- Un segreto da cui derivare chiavi per una sessione protetta.
- Quando?
- All’avvio del collegamento o quando il protocollo rinnova il materiale di chiave.
- Dove?
- Per esempio in una connessione HTTPS tra browser e sito.
- Perché?
- Evitare di distribuire prima una chiave segreta diversa per ogni coppia di utenti e servizi.
Il lessico del canale
- Accordo di chiave
- Un procedimento in cui i partecipanti contribuiscono a ottenere un segreto comune, senza che una parte debba inviarlo come tale. È diverso dal trasporto di una chiave già scelta.
- DH, ECDH ed ECDHE
- Diffie–Hellman è una famiglia di accordi di chiave. ECDH usa gruppi matematici basati su curve ellittiche; la E finale di ECDHE indica chiavi effimere, create per un uso temporaneo. Una curva ellittica qui è una struttura matematica per operazioni su punti, non una forma grafica scelta per decorazione.
- KDF
- Key Derivation Function: ricava materiale di chiave da un segreto e da informazioni di contesto. Consente di ottenere chiavi distinte per scopi diversi, senza usare direttamente il segreto grezzo per ogni operazione.
- Handshake e sessione
- L’handshake è lo scambio iniziale con cui si concordano parametri e si effettuano verifiche. Una sessione è un contesto di comunicazione con uno stato condiviso; i protocolli possono anche riprenderlo o aggiornarlo.
- Man-in-the-middle
- Un attaccante si interpone e stabilisce collegamenti distinti con le vittime, facendo credere a ciascuna di parlare direttamente con l’altra.
Un esempio numerico, senza sicurezza reale
Alice e Bruno pubblicano p = 23 e g = 5. Alice sceglie il segreto a = 6, Bruno b = 15. Usano potenze e resti come nella lezione su RSA, ma questo è un altro problema matematico.
| Alice | Bruno |
|---|---|
| Calcola A = 56 mod 23 = 8. | Calcola B = 515 mod 23 = 19. |
| Invia A = 8, mantiene segreto a. | Invia B = 19, mantiene segreto b. |
| Calcola Ba mod 23 = 196 mod 23 = 2. | Calcola Ab mod 23 = 815 mod 23 = 2. |
Il valore comune è 2 perché entrambi ottengono gab mod p. Un osservatore vede p, g, A e B ma non direttamente a e b. Con questi numeri minuscoli può recuperarli immediatamente: l’esempio spiega la relazione, non costituisce un protocollo sicuro. I sistemi reali impongono gruppi, controlli e dimensioni precisi.
Il punto debole: chi c’è dall’altra parte?
Eva può sostituire A e B con i propri valori e stabilire un segreto con Alice e un altro con Bruno. Può quindi leggere e ritrasmettere i messaggi. Un accordo di chiave va autenticato: per esempio un server firma il contesto dell’handshake e il client verifica la firma con una chiave pubblica affidabile.
Che cosa fa una connessione TLS 1.3 con certificato
TLS, Transport Layer Security, è un protocollo di protezione del collegamento. HTTPS è HTTP trasportato sopra TLS; HTTP è il protocollo applicativo con cui browser e server scambiano richieste e risposte. SSL è il nome dei protocolli predecessori, oggi obsoleti.
- Il client propone parametri e invia un contributo all’accordo di chiave.
- Il server sceglie i parametri e invia il proprio contributo. Si derivano segreti per l’handshake.
- Il server presenta un certificato e prova con una firma di possedere la relativa chiave privata.
- Il client verifica nome, catena di fiducia e messaggi di conferma. Si usano chiavi di traffico simmetriche.
Questa è una vista semplificata del normale handshake con certificato e (EC)DHE, non di ogni modalità di ripresa. I dati applicativi vengono protetti con schemi AEAD; la firma del server autentica lo scambio, non cifra ogni pagina. TLS 1.3 ha eliminato il vecchio trasporto di chiavi con RSA: una chiave RSA può ancora essere usata per firme compatibili. RFC 8446, specifica di TLS 1.3 del 2018; RFC 9846, revisione successiva che mantiene TLS 1.3.
Forward secrecy: proteggere anche il passato
La forward secrecy è la proprietà per cui il successivo furto della chiave privata a lungo termine non basta a ricavare le vecchie chiavi di sessione da traffico registrato. Richiede accordi effimeri corretti e cancellazione dei segreti temporanei. Non salva una sessione la cui chiave sia stata già sottratta dalla memoria del dispositivo. Le modalità TLS basate soltanto su segreti precondivisi richiedono una valutazione separata; i dati anticipati 0-RTT hanno inoltre limiti di replay.
HTTPS non significa «sito onesto»
Il canale può essere sicuro verso il dominio del truffatore. Devi verificare quale nome hai raggiunto. Inoltre un server che termina TLS vede normalmente i dati in chiaro: questo non è automaticamente un sistema cifrato da utente a utente.
Perché non riutilizzare una sola chiave di traffico per sempre?
Aumenterebbe la quantità di dati esposta da un furto, complicherebbe il rispetto dei limiti degli algoritmi e renderebbe più difficile isolare le sessioni. Il protocollo deve prevedere derivazione, separazione degli usi e rinnovo delle chiavi.
Approfondimento dei riferimenti a SSL/SSH nei video 14–15. Come verificare un certificato; specifiche dei protocolli.