TLS reciproco (mTLS): modelli di implementazione

Il TLS standard autentica solo il server presso il client tramite un certificato. Il TLS reciproco (mTLS) estende questo meccanismo: entrambe le parti presentano e verificano i propri certificati. Il client presenta un certificato client dopo che il server lo ha richiesto tramite CertificateRequest nell'handshake TLS. Il server verifica il certificato client rispetto a una CA attendibile. mTLS è la base delle reti zero trust: invece di affidarsi alla sicurezza del perimetro di rete, i servizi si autenticano reciprocamente tramite crittografia a ogni connessione. Service mesh come Istio, Linkerd e Consul Connect implementano mTLS in modo trasparente tra i microservizi.

L'handshake mTLS estende TLS 1.3 come segue: dopo ServerHello e il certificato/Finished del server, il server invia un messaggio CertificateRequest che specifica le autorità di certificazione e gli algoritmi di firma accettabili. Il client risponde con il proprio Certificate (la catena di certificati client) e CertificateVerify (una firma sulla trascrizione ottenuta usando la chiave privata del client). Il server verifica la catena del certificato client rispetto al proprio archivio di CA attendibili e convalida la firma CertificateVerify. Se entrambe le verifiche hanno esito positivo, la connessione è autenticata reciprocamente. Il client non può falsificare CertificateVerify senza la chiave privata corrispondente al certificato.

Negli ambienti service mesh, i certificati client vengono generalmente emessi da una CA interna. Istio utilizza SPIFFE (Secure Production Identity Framework for Everyone) SVID: ogni workload riceve un certificato con un URI SAN (Subject Alternative Name) SPIFFE come spiffe://cluster.local/ns/default/sa/payment-service. Questi certificati hanno durata breve (24 ore) e vengono ruotati automaticamente dal control plane della mesh (istiod). Nel mTLS rivolto agli utenti, ad esempio per VPN aziendali e client API, i certificati possono essere emessi da una CA aziendale con durate più lunghe e distribuiti tramite MDM (Mobile Device Management) ai dispositivi dei dipendenti.

La verifica mTLS lato server prevede diversi passaggi: (1) Convalida della catena: verificare che la catena del certificato client risalga a una CA radice attendibile nell'archivio di CA client del server. (2) Verifica del periodo di validità: assicurarsi che il certificato non sia scaduto e che sia già valido. (3) Verifica della revoca: verificare tramite OCSP o CRL che il certificato non sia stato revocato. (4) Corrispondenza SAN/CN: estrarre l'identità dichiarata dal SAN del certificato (URI SPIFFE, nome DNS o indirizzo email). (5) Autorizzazione: verificare che l'identità autenticata sia autorizzata ad accedere alla risorsa richiesta. I passaggi 4 e 5 richiedono una logica a livello applicativo che va oltre la configurazione TLS di base.

I certificati di breve durata eliminano la necessità di una revoca esplicita: se un certificato scade dopo 24 ore, l'impatto di una compromissione è limitato alla finestra temporale residua. La rotazione richiede: (1) Pre-rotazione: emettere un nuovo certificato prima della scadenza di quello precedente (ruotare all'80% della durata). (2) Sostituzione senza downtime: il servizio deve accettare sia i certificati vecchi sia quelli nuovi durante la finestra di transizione. (3) Ricaricamento controllato: lo stack TLS deve ricaricare le credenziali senza interrompere le connessioni esistenti (nginx: nginx -s reload; Envoy: dynamic xDS certificate update). SPIFFE Workload API, implementata da SPIRE, automatizza la distribuzione e la rotazione dei certificati tramite un'API basata su socket Unix.

Istio implementa mTLS in modo trasparente tramite proxy sidecar Envoy iniettati in ogni pod. Il piano di controllo (istiod) funge da CA utilizzando un certificato intermedio firmato dalla CA radice della mesh. Il sidecar di ogni pod riceve uno SPIFFE SVID tramite l'API SDS (Secret Discovery Service). Le policy PeerAuthentication configurano la modalità mTLS: STRICT (mTLS obbligatorio), PERMISSIVE (accetta sia mTLS sia il testo in chiaro, per la migrazione) o DISABLE. Le risorse AuthorizationPolicy definiscono quali servizi possono comunicare; la verifica viene effettuata rispetto all'identità SPIFFE presente nel certificato client. In questo modo si implementa un modello zero trust all'interno del cluster senza modificare il codice dell'applicazione.

Per i client API esterni, mTLS offre un'autenticazione più robusta rispetto alle chiavi API o ai token OAuth. Il client conserva una chiave privata in un archivio sicuro (HSM, keystore del sistema operativo o chiave software protetta da passphrase). Il certificato client è associato tramite pinning alla CA prevista dall'endpoint API. Ogni richiesta API viene autenticata a livello TLS: non è necessario alcun header Authorization separato. API Shield di Cloudflare, i certificati client di AWS API Gateway e il mTLS degli account di servizio di Google Cloud implementano tutti questo modello. Una chiave API compromessa può essere utilizzata da qualsiasi luogo; per sfruttare una chiave privata mTLS compromessa è inoltre necessario sottrarre il dispositivo su cui è in esecuzione il client.

Le implementazioni mTLS devono affrontare diverse sfide operative. (1) Distribuzione dei certificati: fornire in modo sicuro i certificati client a tutti i servizi, soprattutto negli ambienti dinamici in cui i pod vengono scalati aumentando o riducendo il numero di istanze. (2) Compromissione della CA: la CA interna è un obiettivo di grande valore; se viene compromessa, tutti i certificati dei servizi vengono invalidati. Le CA protette da HSM e le CA radice offline riducono questo rischio. (3) Debug: il traffico mTLS cifrato è opaco agli strumenti standard di debug; sono necessarie le funzionalità di osservabilità della service mesh (Jaeger, Kiali). (4) Compatibilità con i middlebox: i proxy di ispezione TLS interrompono mTLS, a meno che non siano configurati esplicitamente per inoltrare i certificati client. (5) Incidenti dovuti alla scadenza dei certificati: un errore nella rotazione può causare interruzioni complete dei servizi.

SPIFFE (Secure Production Identity Framework for Everyone) definisce uno standard per l'identità dei workload tramite SVID X.509. SPIRE (SPIFFE Runtime Environment) è l'implementazione di riferimento. SPIRE Server funge da autorità di registrazione e da CA. SPIRE Agents vengono eseguiti su ogni nodo e attestano l'identità dei workload utilizzando node attestors (AWS instance identity, Kubernetes service account JWT, TPM) e workload attestors (Unix PID, metadati del container runtime). La Workload API fornisce gli SVID ai workload tramite un socket di dominio Unix, utilizzando una semplice API gRPC. SPIRE si integra con Envoy, Nginx e le principali service mesh come sorgente di certificati.

Per le implementazioni mTLS ad alta sicurezza, le chiavi private dovrebbero risiedere in Hardware Security Modules (HSM) anziché in archivi di chiavi software. La libreria TLS (OpenSSL, BoringSSL) carica la chiave privata tramite l'interfaccia PKCS#11, che reindirizza le operazioni di firma all'HSM. La chiave privata non lascia mai i confini dell'HSM in forma testuale. Le opzioni Cloud HSM includono AWS CloudHSM, Azure Dedicated HSM e Google Cloud HSM. Per il mTLS a livello di dispositivo (IoT, laptop aziendali), TPM 2.0 offre una funzione analoga: la chiave client TLS è associata al TPM e la firma richiede l'autorizzazione del TPM, rendendo estremamente difficile estrarre la chiave da un dispositivo compromesso.

Per testare mTLS sono necessari strumenti che supportino la presentazione del certificato client. OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. Per testare la service mesh, istioctl proxy-config secret pod/name mostra il certificato attuale e la relativa scadenza. Eseguire kubectl exec in un pod e usare curl sull'endpoint admin del sidecar (localhost:15000) per esaminare i listener attivi e la loro configurazione mTLS. I test automatizzati della rotazione dovrebbero verificare che le connessioni rimangano stabili durante gli eventi di rotazione dei certificati.

Quale passaggio aggiuntivo introduce mTLS rispetto al TLS standard?

mTLS aggiunge l'autenticazione tramite certificato client a TLS: entrambe le parti verificano i certificati dell'altra. Gli SPIFFE SVID forniscono un'identità standardizzata per i workload tramite URI SPIFFE nei SAN dei certificati. Istio implementa mTLS in modo trasparente tramite sidecar Envoy con modalità STRICT/PERMISSIVE. I certificati a breve durata (24 ore) eliminano la necessità di revoca e limitano la finestra di esposizione in caso di compromissione. SPIRE automatizza l'emissione e la rotazione dei certificati tramite la Workload API. In un'implementazione ad alta sicurezza, le chiavi private mTLS dovrebbero risiedere in HSM o TPM. Le sfide operative includono la protezione della chiave della CA, la compatibilità con i middlebox e la rotazione senza downtime.