11 ms·

TL;DR: Significant u-turn by tailscale. Previously with Tailscale 1.90.2 or later node state storage encrypted by default on all supported platforms. As of ye

TL;DR: Significant u-turn by tailscale. Previously with Tailscale 1.90.2 or later node state storage encrypted by default on all supported platforms. As of yesterday, per changelog, state file encryption and hardware attestation keys are no longer enabled by default. This effectively rolls back history to pre 1.90.2 and you will now have to enable it manually like you did during the public beta period (>= 1.86) of this short-lived new feature.

shepherdjerred 10mo ago
what's the implication?
- usefulposter 10mo ago
  Help center - https://tailscale.com/kb/1596/secure-node-state-storage https://tailscale.com/kb/1596/secure-node-state-storage: >Secure node state storage can help protect against a malicious actor copying node state from one device to another, effectively cloning the node. By using platform-specific capabilities, Tailscale ensures node state encrypts at rest, making theft from disk and node cloning more difficult. Marketing blogpost - https://tailscale.com/blog/encrypting-data-at-rest https://tailscale.com/blog/encrypting-data-at-rest: >What we really care about here are those private keys stored in the state file, since those are used to identify your node to the coordination server and to other nodes. We need to protect them from exfiltration. >If the Tailscale state file is unencrypted, an attacker with that kind of root access could use the file’s contents from a different machine and impersonate your node. From the perspective of the Tailscale coordination server, it’s as if your device switched to a different network and got a new IP address. We call this attack “node cloning”.
  - nottorp 10mo ago
    So it protects you from an attacker who already has local root?
    - cronos 10mo ago
      Not even that. An attacker with local root can just extract the wireguard keys from process memory, or use the TPM to decrypt the state file like Tailscale would. The only scenario where it helps is a local attacker who can read the state file on disk, but is not full root. Kinda unlikely on Linux, but could happen on Windows.
      - nottorp 10mo ago
        > An attacker with local root can just extract the wireguard keys from process memory, or use the TPM to decrypt the state file like Tailscale would. That was my point :)
- traceroute66 10mo ago
  Historical blog post from tailscale (August 2025) saying how awesome and important this feature was[1]. TL;DR If you care about the stuff mentioned in that blog post (which most sensible sysadmins would) then the implication is that you are no longer protected against those threat scenarios UNLESS you manually apply the flag at install time. Which means for people using deployment scripts/tools you now need to update those to put the flag in during installation. Because previously you could rely on the feature being "on by default", which is no longer the case. [1]https://tailscale.com/blog/encrypting-data-at-rest https://tailscale.com/blog/encrypting-data-at-rest
Thaxll 10mo ago
TPM is really badly implemented. When you upgrade your firmware, OS, everything can go south. Just upgrading your firmware with bitlocker enabled can brick your PC.
- traceroute66 10mo ago
  > TPM is really badly implemented. When you upgrade your firmware, OS, everything can go south. Could you elaborate ? Firmware/OS should not affect TPM contents ? Otherwise e.g. TPM-reliant Windows installs would break ? In addition there are cloud scenarios where your VM has a TPM and you want to e.g .stop a malicious actor poaching your VM and running it elsewhere. Having the tailscale TPM tied to your cloud hypervisor prevents the "lift and shift" attack.
  - Thaxll 10mo ago
    Everytime I have to upgrade my MB firmware it breaks bitlocker and I have to either use restoring keys from microsoft website or disable bitlocker encryption before the upgrade. https://www.reddit.com/r/MSI_Gaming/comments/15w8wgj/psa_tpm_is_cleared_when_updating_biosuefi_all/ https://www.reddit.com/r/MSI_Gaming/comments/15w8wgj/psa_tpm...
  - stanac 10mo ago
    You cant reliably store secrets in tpm and expect it to work after an os update. Windows is using workarounds during windows update to avoid breaking bitlocker. https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/switch-pcr-banks-on-tpm-2-0-devices https://learn.microsoft.com/en-us/windows/security/hardware-...
  - db48x 10mo ago
    You are correct. Updating the firmware or the OS does not actually erase the TPM. What is really going on is that the TPM register holds a value that is like a hash. Each time you measure the system state you update the register with a hash of the previous value and the measurement. When you ask the TPM to hold a key you specify which register value is used to encrypt the key. Later when you use the key it will fail if the TPM cannot decrypt the key. This can only happen if the TPM register has the wrong value, which can only happen if someone has tampered with the system. But voluntarily upgrading the BIOS or the OS looks exactly like tampering. The correct procedure is to unlock the keys, copy them out of the TPM, perform the upgrade, reboot to remeasure the system state, then finally store the keys back into the TPM.
asgeirn 10mo ago
From what I can deduce from the release notes and the linked documentation, it can still be enabled? And it relates to Windows and Linux only, and using the TPM. My guess is that unreliable TPMs made it risky to have this enabled by default.
- traceroute66 10mo ago
  > it can still be enabled? Yes, just like >= 1.86, you set a flag during install. But that's not the point. The point is that >= 1.90.2 it became enabled by default. The point is that most people would expect that "by default" to be a permanent fixture, i.e. a sane secure-by-default config. This means that people with automated deployments based on >= 1.90.2 can no longer rely on the "by default" and this now needs to be flagged.
  - esseph 10mo ago
    If your threat profile has you worried about tailscale + tpm, you probably shouldn't be running talescale unless you're also running headscale... Just a thought.
snailmailman 10mo ago
Not sure if its a "significant" u-turn, when its a relatively new feature. Its only been out for a few months, and seems to be getting rolled back because it was breaking things. Its annoying that a security benefit is being turned off, but it can be turned back on if you are confident it will not break your setup.
- traceroute66 10mo ago
  > Not sure if its a "significant" u-turn I would say it is because they made a big marketing blog post about it at the time[1] (August 2025). So clearly they considered it a significant new feature. The blog post ended with the words "If we don’t spot any major regressions with 1.86, the next stable release will likely turn on state encryption by default for all new nodes". It was then enabled by default 1.90.2 onwards (October 2025). That is why I would consider it a significant u-turn. [1]https://tailscale.com/blog/encrypting-data-at-rest https://tailscale.com/blog/encrypting-data-at-rest
  - hug 10mo ago
    I don't get it. It seems like they're doing largely what they said they would. They wanted to push a feature, and they said they would if they didn't see any major regressions. Then they did see a major regression, so they pulled the feature. Exact version numbers, timelines, and builds are pretty irrelevant to that process. Or are you actually saying you would prefer they had just left their product broken for a significant portion of users, just to keep aligned with the version numbers they mentioned in a blog post?

shepherdjerred 10mo ago

what's the implication?

usefulposter 10mo ago
Help center - https://tailscale.com/kb/1596/secure-node-state-storage https://tailscale.com/kb/1596/secure-node-state-storage: >Secure node state storage can help protect against a malicious actor copying node state from one device to another, effectively cloning the node. By using platform-specific capabilities, Tailscale ensures node state encrypts at rest, making theft from disk and node cloning more difficult. Marketing blogpost - https://tailscale.com/blog/encrypting-data-at-rest https://tailscale.com/blog/encrypting-data-at-rest: >What we really care about here are those private keys stored in the state file, since those are used to identify your node to the coordination server and to other nodes. We need to protect them from exfiltration. >If the Tailscale state file is unencrypted, an attacker with that kind of root access could use the file’s contents from a different machine and impersonate your node. From the perspective of the Tailscale coordination server, it’s as if your device switched to a different network and got a new IP address. We call this attack “node cloning”.
- nottorp 10mo ago
  So it protects you from an attacker who already has local root?
  - cronos 10mo ago
    Not even that. An attacker with local root can just extract the wireguard keys from process memory, or use the TPM to decrypt the state file like Tailscale would. The only scenario where it helps is a local attacker who can read the state file on disk, but is not full root. Kinda unlikely on Linux, but could happen on Windows.
    - nottorp 10mo ago
      > An attacker with local root can just extract the wireguard keys from process memory, or use the TPM to decrypt the state file like Tailscale would. That was my point :)
traceroute66 10mo ago
Historical blog post from tailscale (August 2025) saying how awesome and important this feature was[1]. TL;DR If you care about the stuff mentioned in that blog post (which most sensible sysadmins would) then the implication is that you are no longer protected against those threat scenarios UNLESS you manually apply the flag at install time. Which means for people using deployment scripts/tools you now need to update those to put the flag in during installation. Because previously you could rely on the feature being "on by default", which is no longer the case. [1]https://tailscale.com/blog/encrypting-data-at-rest https://tailscale.com/blog/encrypting-data-at-rest

Thaxll 10mo ago

TPM is really badly implemented. When you upgrade your firmware, OS, everything can go south. Just upgrading your firmware with bitlocker enabled can brick your PC.

traceroute66 10mo ago
> TPM is really badly implemented. When you upgrade your firmware, OS, everything can go south. Could you elaborate ? Firmware/OS should not affect TPM contents ? Otherwise e.g. TPM-reliant Windows installs would break ? In addition there are cloud scenarios where your VM has a TPM and you want to e.g .stop a malicious actor poaching your VM and running it elsewhere. Having the tailscale TPM tied to your cloud hypervisor prevents the "lift and shift" attack.
- Thaxll 10mo ago
  Everytime I have to upgrade my MB firmware it breaks bitlocker and I have to either use restoring keys from microsoft website or disable bitlocker encryption before the upgrade. https://www.reddit.com/r/MSI_Gaming/comments/15w8wgj/psa_tpm_is_cleared_when_updating_biosuefi_all/ https://www.reddit.com/r/MSI_Gaming/comments/15w8wgj/psa_tpm...
- stanac 10mo ago
  You cant reliably store secrets in tpm and expect it to work after an os update. Windows is using workarounds during windows update to avoid breaking bitlocker. https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/switch-pcr-banks-on-tpm-2-0-devices https://learn.microsoft.com/en-us/windows/security/hardware-...
- db48x 10mo ago
  You are correct. Updating the firmware or the OS does not actually erase the TPM. What is really going on is that the TPM register holds a value that is like a hash. Each time you measure the system state you update the register with a hash of the previous value and the measurement. When you ask the TPM to hold a key you specify which register value is used to encrypt the key. Later when you use the key it will fail if the TPM cannot decrypt the key. This can only happen if the TPM register has the wrong value, which can only happen if someone has tampered with the system. But voluntarily upgrading the BIOS or the OS looks exactly like tampering. The correct procedure is to unlock the keys, copy them out of the TPM, perform the upgrade, reboot to remeasure the system state, then finally store the keys back into the TPM.

asgeirn 10mo ago

From what I can deduce from the release notes and the linked documentation, it can still be enabled? And it relates to Windows and Linux only, and using the TPM. My guess is that unreliable TPMs made it risky to have this enabled by default.

traceroute66 10mo ago
> it can still be enabled? Yes, just like >= 1.86, you set a flag during install. But that's not the point. The point is that >= 1.90.2 it became enabled by default. The point is that most people would expect that "by default" to be a permanent fixture, i.e. a sane secure-by-default config. This means that people with automated deployments based on >= 1.90.2 can no longer rely on the "by default" and this now needs to be flagged.
- esseph 10mo ago
  If your threat profile has you worried about tailscale + tpm, you probably shouldn't be running talescale unless you're also running headscale... Just a thought.

snailmailman 10mo ago

Not sure if its a "significant" u-turn, when its a relatively new feature. Its only been out for a few months, and seems to be getting rolled back because it was breaking things. Its annoying that a security benefit is being turned off, but it can be turned back on if you are confident it will not break your setup.

traceroute66 10mo ago
> Not sure if its a "significant" u-turn I would say it is because they made a big marketing blog post about it at the time[1] (August 2025). So clearly they considered it a significant new feature. The blog post ended with the words "If we don’t spot any major regressions with 1.86, the next stable release will likely turn on state encryption by default for all new nodes". It was then enabled by default 1.90.2 onwards (October 2025). That is why I would consider it a significant u-turn. [1]https://tailscale.com/blog/encrypting-data-at-rest https://tailscale.com/blog/encrypting-data-at-rest
- hug 10mo ago
  I don't get it. It seems like they're doing largely what they said they would. They wanted to push a feature, and they said they would if they didn't see any major regressions. Then they did see a major regression, so they pulled the feature. Exact version numbers, timelines, and builds are pretty irrelevant to that process. Or are you actually saying you would prefer they had just left their product broken for a significant portion of users, just to keep aligned with the version numbers they mentioned in a blog post?