Échange de clés TLS et certificat client : lequel ouvre la session ?

Transporter une valeur publique d’échange de clés dans une poignée de main n’est pas le même événement qu’un client qui se connecte. L’une établit un état cryptographique pour la connexion ; l’autre indique qui est le client, et cela n’arrive que lorsque le serveur le demande et que l’échange le permet. Prendre la première pour la seconde conduit à de mauvaises conclusions sur ce qu’un VPN masque et sur ce qu’il ne masque pas. Lisez les messages, puis décidez laquelle des quatre propriétés vous avez réellement observée.

Deux objets qui se ressemblent dans une capture

Un client TLS 1.3 peut apporter de la matière d’échange de clés dans son premier vol sans présenter le moindre certificat. Cet apport est public par conception, car le serveur en a besoin pour dériver le secret partagé. Le certificat client est un autre message, envoyé seulement après que le serveur en a demandé un. Il porte une identité que le serveur vérifie ensuite, et l’authentification mutuelle est une décision du serveur, non une propriété qu’impliquerait la suite de chiffrement. L’identité applicative est une troisième chose tout à fait distincte : un formulaire de connexion, un jeton porteur, un cookie. Rien de tout cela n’apparaît dans la poignée de main, et tout cela survit à un changement de chemin réseau.

Les quatre lignes sont indépendantes. Une connexion peut avoir les lignes une et deux, sauter la ligne trois et porter malgré tout la ligne quatre dans un en-tête de cookie.

Décidez ce qu’une poignée de main capturée peut prouver

À partir de la seule poignée de main, un observateur apprend la version négociée, la suite de chiffrement, le certificat du serveur et les valeurs publiques d’échange de clés. Cela suffit à prendre une empreinte d’une implémentation cliente et à voir quel serveur a été contacté. Ce que cela ne donne pas, c’est l’état privé nécessaire pour déchiffrer la connexion, dont le secret repose sur l’échange éphémère et non sur la part publique. Cela ne donne pas non plus une identité de compte, qui n’a jamais été dans la poignée de main.

La conclusion honnête est donc étroite : aucun certificat client n’a été présenté dans cet échange. Ce n’est pas que le client n’ait rien envoyé de rattachable, et ce n’est certainement pas que la session n’ait porté aucun identifiant.

Lisez les messages plutôt que le nom du chiffrement

Demandez au serveur ce qu’il sollicite, au lieu de le déduire de la suite de chiffrement. Une poignée de main TLS 1.3 qui contient une demande de certificat est visible dans la transcription, et son absence l’est tout autant.

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

Répétez ensuite avec un certificat client configuré, et comparez. La seconde exécution devrait montrer le certificat envoyé et accepté ; la première ne devrait en montrer aucun, et c’est la différence concrète dont il est question.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

Si vous n’avez besoin que du cas de navigation ordinaire, la sortie détaillée du client suffit pour voir la version du protocole, le résultat de la vérification et si un certificat client a été proposé. Un serveur qui n’envoie jamais de demande de certificat n’a pas pu en recevoir un.

Là où la reprise change la réponse

La reprise TLS 1.3 utilise des tickets associés à un état secret, de sorte qu’une connexion ultérieure peut aboutir sans échange complet de certificats. Cela réduit ce qu’un observateur voit et change ce que la transcription prouve. Cela ne crée pas une identité là où il n’y en avait pas. Une session reprise appartient toujours à la même session applicative, et tout cookie ou jeton de cette session reste l’identifiant qui compte.

Voilà pourquoi une revue de confidentialité qui s’arrête à « aucun certificat client » manque la partie intéressante. La question à poser est quelle partie détient un identifiant stable, non quel message a manqué dans une poignée de main.

Inscrivez quatre propriétés, pas un seul verdict

Inscrivez l’accord de clés, la vérification du serveur, l’authentification du client et l’identité applicative comme quatre lignes séparées, avec la preuve de chacune. Cet inventaire survit aux changements de version du protocole, et il rend un argument sur la confidentialité vérifiable par quelqu’un d’autre. Ajoutez ensuite ce qu’apporte le chemin réseau. Un VPN change l’adresse source qu’un service observe ; il ne supprime pas une connexion, un cookie ni une empreinte d’appareil que l’application détient déjà.

Inscrivez ensemble la version négociée de la connexion et l’issue de la demande de certificat, car c’est cette paire dont un relecteur a besoin pour reproduire votre conclusion sans capture personnelle.