Autenticazione reciproca (Mutual authentication): in cosa consiste

Quando aprite un sito in una connessione protetta avviene una verifica sola: il vostro browser controlla il certificato del server e stabilisce che quel server è chi dichiara di essere. Il server, dal suo lato, non sa nulla di voi — accetterà la connessione da qualsiasi client, e vi identificherà soltanto dopo, quando inserirete delle credenziali.

L’autenticazione reciproca elimina quell’asimmetria: entrambe le parti presentano un certificato e ciascuna verifica quello dell’altra prima che qualsiasi dato venga scambiato. La differenza sostanziale è che l’identità viene stabilita a livello di connessione, non di applicazione, e questo la rende adatta a un caso d’uso che le credenziali coprono male: le comunicazioni tra sistemi, dove non c’è nessuna persona che digita niente.

1. Unidirezionale e reciproca: che cosa cambia
2. Come funziona lo scambio
3. Dove serve davvero
4. Il problema non è attivarla, è gestirla
5. Quando non conviene

Unidirezionale e reciproca: che cosa cambia

Nella modalità unidirezionale, che è quella predefinita di qualsiasi connessione protetta sul web, il server dimostra la propria identità presentando un certificato digitale emesso da un’autorità che il client riconosce. Il client verifica quella firma, controlla che il certificato non sia scaduto né revocato e che sia intestato al nome che ha contattato. Da quel momento il canale è cifrato, e chiunque può usarlo.

Nella modalità reciproca il server, dopo aver presentato il proprio certificato, ne richiede uno anche al client. Il client lo presenta e dimostra di possedere la chiave privata corrispondente, il server lo verifica contro le autorità di cui si fida, e solo allora la connessione procede. Un client che non ha un certificato valido non arriva nemmeno a poter tentare un accesso: viene fermato prima, sul canale.

È una distinzione che vale la pena tenere presente perché genera confusione. Inserire nome utente e password su un sito in connessione protetta non è autenticazione reciproca: è autenticazione unidirezionale del server, seguita da una verifica dell’utente fatta dall’applicazione. La stessa cosa vale per l’autenticazione a più fattori, che rafforza la verifica della persona ma non cambia nulla su chi sta parlando con chi a livello di connessione.

Come funziona lo scambio

La sequenza è più semplice di quanto le descrizioni tecniche suggeriscano, e si svolge prima che venga trasmesso un solo dato applicativo.

Il server presenta il proprio certificato, che contiene la sua identità e la sua chiave pubblica. Il client lo verifica: controlla la firma dell’autorità di certificazione, la validità temporale, lo stato di revoca e la corrispondenza con il nome contattato. Se la modalità reciproca è attiva, il server richiede a sua volta un certificato al client, che lo presenta insieme a una firma che dimostra di detenere la chiave privata associata — è quel passaggio, e non il certificato in sé, che prova l’identità, perché un certificato è un documento pubblico che chiunque potrebbe copiare.

Verificate entrambe le parti, client e server derivano una chiave di sessione condivisa. Da quel momento il traffico è protetto con crittografia simmetrica, che è molto più efficiente: la crittografia asimmetrica serve a stabilire la fiducia e la chiave, non a cifrare i dati.

Un elemento su cui vale la pena soffermarsi è chi emette i certificati dei client. Per i server si usano autorità pubbliche, riconosciute dai browser. Per i client, nella quasi totalità dei casi aziendali, si usa un’autorità interna: siete voi a decidere di quali certificati fidarvi, e questo significa che diventate responsabili della loro emissione, della loro revoca e della loro scadenza.

Dove serve davvero

Il criterio è netto: l’autenticazione reciproca serve dove le parti sono sistemi e non persone, e dove l’elenco dei client legittimi è noto e limitato.

Il caso principale sono le **interfacce di programmazione tra sistemi**. Un servizio che riceve chiamate solo da tre applicazioni note ha tutto da guadagnare: senza un certificato riconosciuto nessuno raggiunge nemmeno il livello applicativo, quindi non può provare credenziali, non può cercare difetti di autorizzazione, non compare nei registri come tentativo respinto ma come connessione mai stabilita. È il motivo per cui su questo perimetro l’autenticazione reciproca è la misura più efficace disponibile, e vale la pena valutarla ogni volta che si progetta un’integrazione.

Gli altri contesti in cui è la scelta corretta sono gli scambi con le controparti in ambito finanziario, dove l’identità dell’interlocutore deve essere accertata prima della trasmissione e non dopo; le connessioni verso reti aziendali, dove il dispositivo si autentica insieme all’utente e non al posto suo; e gli apparati connessi in campo, dove non esiste nessuno che possa digitare una password e il certificato è l’unico modo di distinguere un dispositivo legittimo da uno introdotto da qualcun altro.

Il tratto comune ai quattro casi è la conseguenza pratica: si riduce la superficie utile a un attaccante prima che questo possa interagire con l’applicazione. Il canale non è aperto e poi protetto, non si apre affatto.

Il problema non è attivarla, è gestirla

Questa è la parte che le trattazioni tecniche omettono e che determina se l’adozione funziona o diventa un problema ricorrente. Attivare l’autenticazione reciproca su un servizio è un’operazione di configurazione che richiede poche ore. Mantenerla è un impegno permanente.

La ragione è che ogni certificato ha una scadenza, e alla scadenza la connessione si interrompe. Non si degrada, non genera un avviso: si ferma. La causa più comune di interruzione dei servizi che usano l’autenticazione reciproca non è un attacco, è un certificato scaduto che nessuno aveva in calendario — e succede tipicamente su un’integrazione avviata anni prima da qualcuno che nel frattempo ha cambiato ruolo.

A questo si aggiungono tre questioni che vanno decise in anticipo. Dove risiedono le chiavi private dei client, perché una chiave privata copiabile da un file su un server condiviso annulla il beneficio dell’intero meccanismo. Come si revoca un certificato quando un fornitore cessa il rapporto, e chi verifica che la revoca sia effettiva. E chi tiene l’elenco di quali certificati sono stati emessi, a chi e con quale scadenza: un elenco che, come per le interfacce esposte, nella pratica risulta più corto di quello reale.

Serve infine la registrazione degli eventi. Un servizio che accetta connessioni autenticate reciprocamente e non traccia quale certificato ha presentato ciascun client non permette di ricostruire nulla in caso di incidente, come abbiamo visto parlando di gestione dei registri.

Quando non conviene

Vale la pena essere altrettanto chiari su dove l’autenticazione reciproca non è la risposta, perché proporla fuori contesto è il modo più rapido per farla abbandonare.

Non conviene sui servizi rivolti al pubblico. Distribuire e mantenere un certificato per ogni utente di un portale è un onere che nessuna organizzazione sostiene a lungo, e per quello scenario esistono strumenti pensati per gli utenti umani — autenticazione a più fattori, protocolli di autorizzazione delegata come OAuth, gestione centralizzata delle identità.

Non conviene dove l’elenco dei client cambia continuamente, perché il costo di emissione e revoca supera il beneficio. E non sostituisce i controlli applicativi: un client con un certificato valido è un client identificato, non un client autorizzato a fare tutto. Le verifiche su quali dati quel client possa leggere restano necessarie, e sono la categoria di difetti che si trova più spesso su un’interfaccia.

In conclusione

L’autenticazione reciproca risolve un problema preciso: stabilire chi sta parlando prima che la conversazione inizi, in contesti dove le parti sono sistemi noti. Su quel perimetro è la misura con il miglior rapporto tra efficacia e complessità, perché sposta la barriera dal livello applicativo a quello della connessione.

Il costo non sta nella configurazione ma nella gestione, e un’organizzazione che la adotta senza aver deciso chi tiene l’inventario dei certificati e le loro scadenze si troverà a spegnerla al primo fermo di servizio. È una decisione organizzativa mascherata da scelta tecnica.