Firme digitali, certificati, e TLS

La lezione precedente ha lasciato una domanda aperta: la cifratura asimmetrica ti permette di inviare un segreto a qualcuno di cui hai la chiave pubblica — ma come fai a sapere che quella chiave pubblica appartiene davvero a lui, e non a un aggressore nel mezzo? Le firme digitali e i certificati rispondono a questo, e insieme rendono possibile il TLS, il protocollo dietro ogni indirizzo https://.

Le firme digitali: prova di origine, non segretezza

Una firma digitale fa funzionare la cifratura asimmetrica al contrario. Invece di cifrare un messaggio con la chiave pubblica di qualcuno così che solo lui possa leggerlo, il mittente firma un messaggio con la propria chiave privata, e chiunque può verificarlo usando la chiave pubblica del mittente. Se la verifica ha successo, due cose sono vere: il messaggio proviene da chi detiene quella chiave privata, e non è stato alterato in seguito — la stessa proprietà di resistenza alle collisioni discussa a proposito dell’hashing nella lezione precedente è ciò che rende rilevabile una manomissione. Una firma dimostra autenticità e integrità; non mantiene, da sola, il messaggio segreto.

I certificati: una firma che garantisce per una chiave pubblica

Un certificato digitale risolve il problema del “di chi è davvero questa chiave pubblica”. Come spiega il Centro di apprendimento di Cloudflare, un certificato SSL/TLS è “un file di dati ospitato sul server d’origine di un sito web” contenente il nome di dominio, la chiave pubblica, una data di scadenza, e — fondamentale — “la firma digitale dell’autorità di certificazione”. Un’autorità di certificazione (CA) è una terza parte fidata che verifica che un sito web controlli il dominio per cui sta richiedendo un certificato, poi firma quel certificato con la propria chiave privata. Il tuo browser viene fornito con un elenco integrato di CA di cui si fida, così quando riceve un certificato firmato da una di esse, può fidarsi della chiave pubblica al suo interno senza aver mai incontrato l’operatore del sito web. Un certificato autofirmato — uno che un sito firma da sé invece di ottenerlo da una CA — non ha questa garanzia esterna, motivo per cui i browser lo trattano come non attendibile per impostazione predefinita.

TLS: mettere entrambi al lavoro

RFC 8446, la specifica per TLS 1.3, descrive un handshake in fasi: scambio di chiavi, in cui le due parti stabiliscono materiale segreto condiviso; poi autenticazione, dove, nelle parole della RFC, “il lato server del canale è sempre autenticato; il lato client è autenticato facoltativamente” — normalmente solo il sito web dimostra la propria identità, non il visitatore. Il server dimostra chi è usando il proprio certificato e una firma che solo lui potrebbe produrre con la propria chiave privata. Una volta che entrambe le parti si fidano della connessione, derivano chiavi simmetriche veloci (tipicamente l’AES della lezione precedente) per i dati veri e propri. RFC 8446 afferma chiaramente cosa questo ti offre: riservatezza e integrità per i dati scambiati, e autenticazione del server. Afferma anche, altrettanto chiaramente, un limite: “TLS non nasconde la lunghezza dei dati che trasmette”, e metadati come a quale server ti sei connesso e quando restano visibili a chiunque sia posizionato per osservare la connessione.

Cosa significa e cosa non significa l’icona del lucchetto

Un sito di phishing costruito su un dominio ingannevole può avere un certificato perfettamente valido: TLS autentica il dominio, non l’intento di chi lo ha registrato. Ecco perché la lezione precedente su come si sviluppano gli attacchi tratta una falsa pagina di accesso, lucchetto incluso, come una minaccia reale, non una contraddizione.