TLS vs mTLS Handshake

Le TLS standard authentifie le serveur auprès du client : votre navigateur vérifie qu’il parle bien à la vraie banque, pas à un imposteur. C’est suffisant pour la majorité du trafic web. Mais dans les architectures zero-trust — où aucun emplacement réseau n’est considéré comme fiable par défaut — le serveur doit aussi savoir qui est le client. C’est le TLS mutuel (mTLS).

Le cas d’usage principal est la communication service-à-service. Dans un cluster Kubernetes, des dizaines de microservices communiquent entre eux via le réseau interne. Sans mTLS, n’importe quel pod compromis peut usurper l’identité de n’importe quel service. Avec mTLS, chaque connexion exige que les deux parties présentent un certificat valide, rendant le déplacement latéral bien plus difficile pour un attaquant.

La différence conceptuelle est mince — trois messages supplémentaires dans le handshake. La différence opérationnelle est conséquente — il faut une infrastructure PKI pour émettre, distribuer et renouveler les certificats de chaque service. Les diagrammes ci-dessous montrent exactement ce qui change.

Complexité opérationnelle

La différence au niveau du handshake est simple — trois messages supplémentaires. La différence opérationnelle est là où les équipes sous-estiment mTLS. Il faut une infrastructure PKI : une autorité de certification (CA interne ou service managé comme AWS Private CA), un mécanisme d’émission de certificats pour chaque service, et un moyen de les distribuer de manière sécurisée au déploiement.

La rotation des certificats est la partie la plus complexe. Les certificats à longue durée de vie (mois/années) sont plus simples à gérer mais nécessitent une infrastructure de révocation — points de distribution CRL ou répondeurs OCSP — en cas de compromission de clé. Les certificats à courte durée de vie (heures/jours) contournent entièrement la révocation en expirant avant qu’un attaquant ne puisse utiliser une clé volée, mais ils exigent une émission automatisée et des redémarrages fréquents ou un rechargement à chaud.

En pratique, la plupart des équipes adoptent l’une de ces trois approches. Les service meshes Istio / Linkerd injectent des proxies sidecar qui gèrent mTLS de manière transparente — le code applicatif ne change pas du tout. SPIFFE/SPIRE fournit un framework d’identité de workload avec des SVID (SPIFFE Verifiable Identity Documents) à courte durée de vie, renouvelés automatiquement. Cloudflare Access et les proxies zero-trust similaires terminent mTLS en périphérie, déchargeant la gestion PKI vers un service managé.