Tailscale-Statusdatei-Verschlüsselung in der Standardeinstellung deaktiviert

• In Tailscale v1.92.5 sind bei Linux- und Windows-Clients die Funktionen Statusdatei-Verschlüsselung (state file encryption) und Hardware-Authentifizierungsschlüssel standardmäßig deaktiviert.
• Selbst wenn ein TPM-Gerät zurückgesetzt oder ausgetauscht wurde, startet der Client normal; ein Fehler beim Laden des Hardware-Authentifizierungsschlüssels verhindert die Ausführung nicht.
• Im Tailscale-Container-Image werden Hardware-Authentifizierungsschlüssel nicht mehr zu Kubernetes-State-Secrets hinzugefügt, sodass Container auf andere Nodes verschoben werden können.
• Der Tailscale Kubernetes Operator verwendet bei der Zertifikatserneuerung standardmäßig nicht die ARI-Bestellmethode und speichert Hardware-Authentifizierungsschlüssel nicht in Secrets.
• Diese Änderung ist ein Update, das die Konfiguration der Sicherheitsfunktionen von Tailscale vereinfacht und die Flexibilität bei Deployments in unterschiedlichen Umgebungen erhöht.

---

Tailscale v1.92.5 Update

• Linux- und Windows-Clients

  • Bei den Funktionen rund um Secure node state storage sind Statusdatei-Verschlüsselung und Hardware-Authentifizierungsschlüssel standardmäßig deaktiviert.
  • Auch wenn ein TPM-Gerät (Trusted Platform Module) zurückgesetzt oder ersetzt wird, wird der Start des Clients nicht blockiert.

• Tailscale-Container-Image

  • Die neue Version ist auf Docker Hub und bei GitHub Packages verfügbar.
  • Hardware-Authentifizierungsschlüssel werden nicht zu Kubernetes-State-Secrets hinzugefügt, sodass der Tailscale-Container auf einen anderen Kubernetes-Node verschoben werden kann.

• Tailscale Kubernetes Operator

  • Die neue Version kann gemäß dem Installationsleitfaden bereitgestellt werden.
  • Bei der Zertifikatserneuerung wird die ARI-Bestellmethode standardmäßig nicht verwendet, um mögliche Erneuerungsfehler zu vermeiden, die auftreten können, wenn der ACME-Account-Schlüssel neu erstellt wird.
  • Hardware-Authentifizierungsschlüssel werden nicht zu Kubernetes-State-Secrets hinzugefügt, sodass der Operator auf einen anderen Node verschoben werden kann.

• Tailscale tsrecorder

  • Die neue Version ist auf Docker Hub verfügbar.
  • Diese Release enthält nur Bibliotheks-Updates, keine Funktionsänderungen.

5. Januar 2026 — Workload Identity Federation API

• Die Tailscale API unterstützt das Erstellen, Abrufen, Ändern und Löschen von federierten Identitäten (federated identities).
• Dieselben Funktionen lassen sich auch mit tailscale-client-go-v2 und dem Tailscale Terraform provider konfigurieren.

23. Dezember 2025 — GitHub Action v4.1.1

• Die Tailscale GitHub Action wurde so korrigiert, dass sie auf macOS-basierten GitHub Runnern beim Speichern und Abrufen des Caches die richtige Architektur verwendet.

[joyfui]

Oh, ich glaube, ich habe vor Kurzem einen Beitrag von jemandem gesehen, der in Zusammenhang damit ein Utility verteilt hat...

[GN⁺]

Hacker-News-Kommentare

• Ich bin der Ingenieur, der die Funktion node state encryption bei Tailscale ursprünglich implementiert hat (@awly auf Github). Diesmal wurde entschieden, sie in Version 1.92.5 standardmäßig zu deaktivieren.
  Wie in anderen Kommentaren vermutet wurde, verursacht diese Funktion zu viel Support-Aufwand. Ursprünglich war sie so konzipiert, dass ein TPM-Reset oder -Austausch immer als Manipulation gilt und der Client dann den Start verweigert. In der Praxis war TPM aber aus nicht böswilligen Gründen oft instabil.
  Beispiele sind Issue 17654, Issue 18288 und Issue 18302.
  TPM ist ein großartiges Werkzeug, wenn eine Organisation ihre Geräte gut kontrollieren kann, aber für einen Dienst wie Tailscale, der Geräte in sehr unterschiedlichen Umgebungen unterstützen muss, ist es zu komplex. Deshalb ist es jetzt so, dass sicherheitssensible Nutzer oder Administratoren es selbst aktivieren müssen. Im Changelog hätte mehr von diesem Kontext stehen sollen; dafür entschuldige ich mich.
  • Als ich die verlinkten Issues gelesen habe, war ich überrascht. Ich dachte, TPM-Probleme würden nur auf alter Hardware oder in Spezialumgebungen auftreten, aber sie traten auch bei Dell XPS und mehreren VMs auf.
    Ich betreibe die meisten meiner Tailscale-Instanzen in VMs und Containern, und tatsächlich war TPM-Verschlüsselung nur auf meinem Haupt-PC, meinem iPhone und dem Host meines Linux-Servers aktiv. In VMs oder Containern funktionierte sie überhaupt nicht, und mein Laptop ist wohl zu alt und unterstützt sie nicht.
  • Ich halte die Entscheidung für sehr vernünftig. Danke für die Erklärung.
  • In Issue 17654 schrieb ein Nutzer, dass es auch mit der Einstellung TS_ENCRYPT_STATE=false nicht gelöst wurde, später hieß es aber, dass das Problem in Version 1.92.1 verschwunden sei.
    Mich würde interessieren, ob das in diesem Fall wirklich ein Problem mit state encryption war oder ob eine andere Ursache dahintersteckte.
  • Ich habe TPM auch vertraut, aber schon ein einziges BIOS-Update hat mein TPM vollständig zurückgesetzt. Seitdem verlasse ich mich nicht mehr darauf.
  • Danke für diese offene Erklärung. Es wäre gut, wenn etwas von diesem Hintergrund auch im Changelog stünde.
    Wenn die Lage zu komplex ist, wäre auch ein kurzer Blogpost dazu willkommen.
• Diese Funktion hätte von Anfang an nicht standardmäßig aktiviert sein dürfen. Ein Administrator sollte TPM ausdrücklich auswählen müssen.
  Wie auch im Changelog steht, konnte der Client nach einem TPM-Reset oder -Austausch nicht starten, weil der hardwaregebundene Schlüssel nicht geladen werden konnte.
  In vielen Deployment-Umgebungen ist diese Funktion wichtig, aber weil Tailscale auf so vielen verschiedenen Betriebssystemen und Geräten läuft, gab es einfach zu viele unvorhersehbare Konflikte.
  • Jedes Mal, wenn man TPM für Verschlüsselung einsetzen will, braucht man am Ende doch ein Wiederherstellungspasswort oder einen Backup-Schlüssel. Damit wird der Zweck von TPM im Grunde ad absurdum geführt.
    Schon ein kleiner Fehler kann dazu führen, dass der Schlüssel eines Nutzers vollständig verloren ist, deshalb wirkt das in der Praxis schwer nutzbar.
  • Verwendet Windows TPM nicht standardmäßig? Wenn ja, hätten dann nicht Millionen Windows-Nutzer Probleme haben müssen?
    Deshalb wirkt das etwas wie eine überzogene Reaktion. Schade, dass die gesamte Funktion wegen einiger TPM-Sonderfälle abgeschaltet wurde.
    Eine Zwischenlösung, etwa eine optionale Aktivierung, wäre vielleicht sinnvoll gewesen.
  • Wenn TPM zurückgesetzt oder ausgetauscht wird und dann blockiert wird, ist das nicht gerade aus Sicht der Abwehr physischer Angriffe das richtige Verhalten?
• In diesem PR wird der Grund für die Deaktivierung erklärt.
  Dort heißt es, dass die Qualität von TPM zu stark schwankt und deshalb viele verschiedene Probleme verursacht wurden.
• Wenn man das Changelog liest, scheint es an Problemen durch die standardmäßige Aktivierung zu liegen (ich habe keine internen Informationen).
  Ich frage mich allerdings, ob geplant ist, die Funktion wieder standardmäßig zu aktivieren, falls diese Probleme gelöst werden.
  Ich vertraue dem Tailscale-Team, aber in einer Zeit wachsender Überwachungsbedenken hätte ich gern eine klare Erklärung, dass diese Änderung nicht auf Druck von Behörden erfolgt ist.
  • Ich denke, die Ursache des Problems liegt nicht bei Tailscale, sondern an der Instabilität der TPM-Hardware selbst.
    Deshalb sollte diese Funktion meiner Meinung nach nur in kontrollierten Umgebungen optional verwendet werden.
• Auf einer NixOS-Maschine mit alter Hardware ist Tailscale ständig abgestürzt, und ich wusste nicht warum; dank dieser Änderung kenne ich jetzt die Ursache. Es lag an der TPM-Verschlüsselung.
• Ich vermute, sie haben es deaktiviert, weil es einfach zu viele Support-Anfragen gab.
• Im letzten Monat war Tailscale bei mir ständig kaputt, aber das heute veröffentlichte Patch hat das Problem behoben.
  Die Ursache war ein BIOS-Update, danach hing Tailscale im Status „Starting“ fest und zeigte keinerlei Fehler an.
• Ich boote ein auf USB installiertes Linux abwechselnd auf Desktop und Laptop, und eines Tages funktionierte Tailscale plötzlich nicht mehr.
  Ich dachte, mein Fall sei ein Sonderfall, aber jetzt sehe ich, dass TPM-basierte Verschlüsselung auch aus anderen Gründen scheitern kann.
• Unter Linux scheint man in /etc/default/tailscaled einfach FLAGS="--encrypt-state" hinzufügen zu müssen.
  Im Log erscheint die Meldung "migrated ... to TPM-sealed format", also scheint es korrekt zu funktionieren.
• Aus genau diesem Grund kann man im Massenmarkt keine Funktion standardmäßig ausrollen, die selbst bei nur 1 % der Fälle kaputtgeht.
  Am Ende muss man sich nach dem kleinsten gemeinsamen Nenner richten und Stabilität vor perfekter Sicherheit stellen.
  Wenn ich Tailscale betreiben würde, hätte ich vielleicht gesagt: „Wer ein kaputtes TPM hat, soll es selbst reparieren, wir behalten Sicherheit standardmäßig bei.“
  Aber ich verstehe, dass Avery Gründe für diese Entscheidung hat.