tls-auth ou tls-crypt : ce que chacun protège dans OpenVPN

Les deux options utilisent un fichier de clé partagé et toutes deux rendent le trafic de la poignée de main plus difficile à falsifier, c’est pourquoi on les traite comme deux noms d’une même fonction. Ce n’est pas le cas. L’une signe les paquets de contrôle, l’autre les chiffre en plus, et aucune n’a de rapport avec le chiffrement qui protège vos données.

Cette distinction compte lorsqu’un profil ne parvient pas à se connecter, lorsqu’un audit de sécurité demande ce que protège la clé et lorsque quelqu’un suppose que le fichier supplémentaire rend le tunnel chiffré d’une manière indéfinie.

Ce que protège réellement la clé partagée

La clé utilisée par ces options appartient au canal de contrôle : l’échange qui négocie les paramètres, prouve les identités et dérive les clés de données. C’est un secret prépartagé que les deux extrémités doivent détenir avant que la poignée de main puisse se poursuivre. Comme il intervient avant les vérifications d’identité, une clé erronée arrête la conversation plus tôt qu’un mot de passe erroné ne le ferait. Cet ordre explique pourquoi le mode de défaillance est si silencieux.

tls-auth utilise ce secret pour calculer un HMAC sur les paquets de contrôle. Un paquet sans signature valide est écarté avant d’atteindre le traitement TLS, plus coûteux, et c’est pourquoi l’option est souvent décrite comme un premier filtre plutôt qu’un remplacement de TLS.

tls-crypt va plus loin en chiffrant le trafic de contrôle protégé en plus de l’authentifier. Le contenu des certificats, les noms de chiffrement négociés et d’autres détails de la poignée de main ne sont plus visibles sur le réseau, et un observateur sans la clé ne peut même pas voir quelle version de TLS est tentée. Pour un déploiement qui craint de révéler son empreinte VPN, cette propriété est la raison principale de le choisir. Il reste un secret de groupe, pas un identifiant par utilisateur.

Aucun des deux mécanismes n’émet d’identité. La clé partagée est un secret de groupe, et quiconque la détient peut satisfaire cette couche de la vérification.

Où les deux options diffèrent

La différence observable est ce que voit un observateur. Avec tls-auth, la poignée de main est visible mais invérifiable sans la clé. Avec tls-crypt, la poignée de main est opaque pour quiconque ne détient pas la clé.

La configuration diffère aussi. tls-auth s’utilise avec une valeur de direction, si bien qu’un côté utilise une moitié du matériel de clé et l’autre côté l’autre moitié. tls-crypt utilise une clé unique dans les deux sens, donc la directive de direction ne fait pas partie de son schéma.

Les deux options s’excluent mutuellement dans les versions modernes. Un profil doit en porter une seule, pas les deux, et le serveur comme le client doivent s’accorder sur laquelle, avec un matériel de clé identique. Conserver une ancienne directive à côté d’une nouvelle est un résidu de migration courant. Supprimez l’inactive pour que le prochain lecteur sache quelle couche est réellement en vigueur.

Une variante plus récente, tls-crypt-v2, lie chaque client à sa propre clé enveloppée, de sorte que révoquer un client n’exige pas de réémettre la clé de groupe. Cela vaut la peine d’être connu, mais c’est une option différente et non un synonyme de l’une ou l’autre de celles présentées ici.

Pourquoi une incompatibilité donne l’impression que rien ne se passe

Quand le matériel partagé ne correspond pas, l’homologue écarte les paquets sans dire à l’expéditeur pourquoi. Il n’y a aucune erreur d’authentification à lire, car le paquet n’a jamais atteint la couche qui en produirait une.

Le client réessaie, le serveur ne dit rien, et le symptôme ressemble à un problème de réseau. Les gens redémarrent alors le service, ressaisissent le mot de passe du compte ou retirent la directive de protection pour la « tester », ce qui modifie le déploiement au lieu de le diagnostiquer.

Lisez dans le journal du serveur la première plainte au niveau des paquets plutôt que la dernière ligne de nouvelle tentative. Confirmez que les deux côtés portent la même option avec un matériel de clé identique et que le fichier de clé n’a pas été régénéré d’un seul côté.

Retirer la directive n’est pas une réparation sûre. Cela désactive une couche de protection pour chaque client, et un tunnel qui fonctionne ensuite prouve seulement que cette couche était l’incompatibilité.

Ce qu’il faut encore configurer séparément

Ces options ne vérifient pas qui est l’homologue. La validation des certificats, l’ancre de confiance et le nom de serveur attendu restent des exigences distinctes, et aucune ne devient facultative parce qu’une clé partagée est présente.

Elles ne choisissent pas non plus le chiffrement des données. C’est une négociation distincte, contrôlée par les réglages du canal de données des deux côtés, et un tunnel protégé par tls-crypt peut encore utiliser un chiffrement que vous ne vouliez pas.

Enfin, la clé partagée elle-même demande un traitement. Traitez-la comme un secret, distribuez-la par un canal approuvé et remplacez-la quand quelqu’un qui la détenait part. Comme elle est partagée, son exposition est l’exposition de chaque extrémité qui l’utilise.