Chiffrement du fichier d’état Tailscale désactivé par défaut

(tailscale.com)

1 points par GN⁺ 2026-01-09 | 2 commentaires | Partager sur WhatsApp

Dans la version Tailscale v1.92.5, les fonctionnalités de chiffrement du fichier d’état (state file encryption) et de clés d’attestation matérielle des clients Linux et Windows sont désactivées par défaut
Même si un périphérique TPM est réinitialisé ou remplacé, le client démarre normalement et l’échec du chargement d’une clé d’attestation matérielle n’empêche pas l’exécution
Dans les images de conteneur Tailscale, les clés d’attestation matérielle ne sont plus ajoutées aux Secrets d’état Kubernetes, ce qui permet de déplacer le conteneur vers un autre nœud
Le Tailscale Kubernetes Operator n’utilise pas par défaut la méthode de commande ARI lors du renouvellement des certificats et ne stocke pas les clés d’attestation matérielle dans les Secrets
Ce changement est une mise à jour qui simplifie la configuration des fonctionnalités de sécurité de Tailscale et accroît la flexibilité de déploiement dans divers environnements

Mise à jour Tailscale v1.92.5

Clients Linux et Windows
- Parmi les fonctionnalités liées à Secure node state storage, le chiffrement du fichier d’état et les clés d’attestation matérielle sont désormais désactivés par défaut
- Le démarrage du client n’est pas bloqué même si un périphérique TPM (Trusted Platform Module) est réinitialisé ou remplacé
Images de conteneur Tailscale
Publicité
- La nouvelle version est disponible sur Docker Hub et GitHub Packages
- Les clés d’attestation matérielle ne sont pas ajoutées aux Secrets d’état Kubernetes, ce qui permet de déplacer le conteneur Tailscale vers un autre nœud Kubernetes
Tailscale Kubernetes Operator
- La nouvelle version peut être déployée conformément au guide d’installation
- Lors du renouvellement des certificats, la méthode de commande ARI n’est pas utilisée par défaut, afin d’éviter les échecs de renouvellement pouvant survenir lorsqu’une clé de compte ACME est recréée
- Les clés d’attestation matérielle ne sont pas ajoutées aux Secrets d’état Kubernetes, ce qui permet de déplacer l’Operator vers un autre nœud
Tailscale tsrecorder
Publicité
- La nouvelle version est disponible sur Docker Hub
- Cette release inclut uniquement des mises à jour de bibliothèques, sans changement fonctionnel

5 janvier 2026 — API Workload Identity Federation

La Tailscale API prend en charge la création, la consultation, la modification et la suppression d’identités fédérées (federated identities)
Les mêmes fonctionnalités peuvent également être configurées dans tailscale-client-go-v2 et le provider Terraform Tailscale

23 décembre 2025 — GitHub Action v4.1.1

La Tailscale GitHub Action a été corrigée afin d’utiliser la bonne architecture lors de l’enregistrement et de la récupération du cache sur les GitHub Runners basés sur macOS

2 commentaires

joyfui 2026-01-09

Euh, il me semble avoir vu il y a peu un post de la personne qui avait publié un utilitaire à ce sujet...

GN⁺ 2026-01-09

Commentaires Hacker News

Je suis l’ingénieur qui a initialement implémenté la fonctionnalité de chiffrement de l’état du nœud dans Tailscale (@awly sur Github). Nous avons décidé de la désactiver par défaut dans la version 1.92.5
Comme certains l’ont supposé dans d’autres commentaires, cette fonctionnalité représente une charge de support beaucoup trop importante. À l’origine, elle était conçue pour considérer toute réinitialisation ou tout remplacement du TPM comme une altération, et empêcher alors le client de démarrer. Mais en pratique, il arrivait souvent que le TPM soit instable pour des raisons non malveillantes
On peut citer par exemple issue 17654, issue 18288, issue 18302.
Le TPM est un excellent outil quand une organisation maîtrise bien son parc matériel, mais pour un service comme Tailscale, qui doit prendre en charge des équipements dans des environnements très variés, c’est trop complexe. Nous avons donc choisi pour l’instant de laisser l’activation aux utilisateurs ou administrateurs sensibles aux questions de sécurité. Nous aurions dû donner davantage de contexte dans le changelog, et je m’en excuse
- J’ai été surpris en lisant les issues liées. Je pensais que les problèmes de TPM n’apparaîtraient que sur du vieux matériel ou dans des environnements particuliers, mais ils se produisaient aussi sur des Dell XPS et sur plusieurs VM.
  Je fais tourner la plupart de mes instances Tailscale dans des VM et des conteneurs, et en réalité le chiffrement TPM n’était actif que sur mon PC principal, mon iPhone et l’hôte de mon serveur Linux. Cela ne fonctionnait pas du tout dans les VM ou les conteneurs, et mon portable était sans doute trop ancien pour être pris en charge
- Cette politique me paraît tout à fait raisonnable. Merci pour l’explication
- Dans issue 17654, un utilisateur disait que le réglage TS_ENCRYPT_STATE=false n’avait pas résolu le problème, mais qu’avec la version 1.92.1 le problème avait disparu.
  Je me demande si, dans ce cas, il s’agissait vraiment d’un problème de chiffrement de l’état, ou s’il y avait une autre cause ; j’aimerais bien avoir plus d’explications
- Moi aussi, j’avais confiance dans le TPM, mais une seule mise à jour du BIOS l’a complètement réinitialisé. Depuis, j’ai décidé de ne plus en dépendre
- Merci pour cette explication aussi franche. Ce serait bien qu’un peu de ce contexte figure dans le changelog.
  Si la situation est trop complexe, un court billet de blog pour l’expliquer séparément serait aussi le bienvenu
Cette fonctionnalité n’aurait jamais dû être activée par défaut. Un administrateur devrait choisir explicitement d’utiliser le TPM
Comme l’indique aussi le changelog, quand le TPM était réinitialisé ou remplacé, le client ne parvenait plus à charger la clé d’authentification matérielle et ne démarrait plus.
Dans de nombreux environnements de déploiement, cette fonctionnalité est indispensable, mais comme Tailscale fonctionne sur une très grande diversité d’OS et de matériels, il y avait trop de collisions imprévisibles
- Chaque fois que j’essaie d’utiliser le TPM pour le chiffrement, je finis par avoir besoin d’un mot de passe de récupération ou d’une clé de secours. Mais cela vide en partie le TPM de sa raison d’être.
  Une petite erreur peut suffire à faire disparaître complètement les clés d’un utilisateur, donc en pratique j’ai du mal à m’en servir
- Windows n’utilise-t-il pas déjà le TPM par défaut ? Si c’est le cas, des millions d’utilisateurs Windows auraient dû rencontrer le problème.
  Cela ressemble donc un peu à une réaction excessive. C’est dommage de désactiver toute la fonctionnalité à cause de quelques cas particuliers liés au TPM.
  J’aurais aimé une étape intermédiaire, par exemple une activation optionnelle
- Je me demande si le fait de bloquer en cas de réinitialisation ou de remplacement du TPM n’est pas justement le bon comportement du point de vue de la défense contre une attaque physique
Cette PR explique pourquoi cela a été désactivé.
La variabilité de qualité des TPM provoquait apparemment trop de problèmes
D’après le changelog, cela semble venir des problèmes causés par l’activation par défaut (je n’ai pas d’informations internes).
Cela dit, je me demande s’il est prévu de réactiver cette option par défaut si le problème est résolu.
J’ai confiance dans l’équipe Tailscale, mais à une époque où les craintes de surveillance augmentent, j’aimerais entendre une raison claire pour être sûr que ce changement ne vient pas d’une demande gouvernementale
- Selon moi, la cause du problème n’est pas Tailscale mais l’instabilité du matériel TPM lui-même.
  Donc cette fonctionnalité ne devrait être utilisée de manière optionnelle que dans des environnements contrôlés
Sur une machine NixOS avec du vieux matériel, Tailscale plantait sans arrêt et je ne comprenais pas pourquoi ; ce changement m’a permis d’en identifier la cause. C’était le chiffrement TPM
Je suppose qu’ils l’ont probablement désactivé parce qu’il y avait trop de demandes de support
Depuis un mois, Tailscale ne cessait de tomber en panne chez moi, et le correctif publié aujourd’hui a réglé le problème.
La cause était une mise à jour du BIOS, après laquelle Tailscale restait bloqué sur l’état “Starting” sans afficher la moindre erreur
J’utilise un Linux installé sur USB que je démarre alternativement sur un desktop et un portable, et un jour Tailscale a soudainement cessé de fonctionner.
Je pensais que mon cas était atypique, mais j’ai découvert que le chiffrement basé sur le TPM pouvait aussi échouer pour d’autres raisons
Sous Linux, il semble qu’il suffise d’ajouter FLAGS="--encrypt-state" dans /etc/default/tailscaled.
Le journal affiche le message "migrated ... to TPM-sealed format", donc cela a l’air de fonctionner correctement
C’est exactement pour ce genre de raison qu’on ne peut pas activer par défaut, sur le marché grand public, une fonctionnalité qui casse ne serait-ce que dans 1 % des cas.
Au final, il faut s’aligner sur le plus petit dénominateur commun, et privilégier la stabilité plutôt qu’une sécurité parfaite.
Si c’était moi qui gérais Tailscale, j’aurais peut-être dit : “ceux dont le TPM est cassé n’ont qu’à se débrouiller, nous nous maintenons la sécurité par défaut”.
Mais je comprends qu’Avery ait ses raisons pour prendre cette décision