FRESH

Hacker News

Home

Tailscale state file encryption no longer enabled by default

364 points by traceroute66

by cronos

14 subcomments

I'm one of the Tailscale engineers who built node state encryption initially (@awly on Github), and who made the call to turn it off by default in 1.92.5.
Another comment in this thread guessed right - this feature is too support intensive. Our original thinking was that a TPM being reset or replaced is always sign of tampering and should result in the client refusing to start or connect. But turns out there are many situations where TPMs are not reliable for non-malicious reasons. Some examples: * https://github.com/tailscale/tailscale/issues/17654 * https://github.com/tailscale/tailscale/issues/18288 * https://github.com/tailscale/tailscale/issues/18302 * plus a number of support tickets
TPMs are a great tool for organizations that have good control of their devices. But the very heterogeneous fleet of devices that Tailscale users have is very difficult to support out of the box. So for now we leave it to security-conscious users and admins to enable, while avoiding unexpected breakage for the broader user base.
We should've provided more of this context in the changelog, apologies!

by xyzzy_plugh

3 subcomments

This never should have been on by default. The end user (read: administrator) needs to know they want to use the TPM.
This is a huge foot gun for many devices.
The accompanying changelog note hints at why:
> Failure to load hardware attestation keys no longer prevents the client from starting. This could happen when the TPM device is reset or replaced.
This is unfortunate as for many, many deployments, you absolutely want this on. But because it's a time bomb for certain device/OS combinations that Tailscale can't control or predict, and folks install Tailscale on pretty much everything, then the incidence of borked installs can only rise.

by rstat1

0 subcomment

Here’s the PR explaining why they disabled this function
https://github.com/tailscale/tailscale/pull/18336
Seems like it caused tons of problems due to the variability of TPM quality among other things

by jkaplowitz

1 subcomments

From the changelog, it seems like this may have been due to issues caused by the on-by-default setting, although I don’t work for Tailscale and am speculating here with no inside info.
I wonder, would Tailscale be willing to confirm that they plan to fix whatever the issues are and re-enable this default within a short-ish timeframe? I currently have plenty of trust in the good intentions of the people running Tailscale, but with geopolitics as it currently is, I’d love to have a concrete reason even beyond that positive track record to believe that this change isn’t attempting to satisfy ease-of-surveillance concerns expressed by government agencies in whichever country.

by jsiepkes

0 subcomment

Guessing it was too support intensive? Caused too many issues for people who then reached out to support?

by zero0529

0 subcomment

Thank god, I was running Tailscale on a nixos machine on some really old hardware and I couldn’t figure out why it kept crashing. It was because of this but it just failed silently.

by issung

0 subcomment

My Tailscale was broken for the past month and I only just fixed it yesterday, and today this patch is released that would have made it a non-issue.
Updating my BIOS caused the issue. The main problem was that Tailscale's behaviour was very poor in this case. It simply got stuck "Starting" and never provided any error information.

by maufl

0 subcomment

Oh, I got bitten by that! I have my work Linux installation on an USB stick so I can boot it on either my desktop or laptop and one day tailscale stopped working. I thought that might be a rare situation, but it looks like TPM based encryption failed for other reasons too.

by sp_c

0 subcomment

So in linux it looks like we just update /etc/default/tailscaled with:
FLAGS="--encrypt-state"
...and hope for the best?
edit: I see this in my logs, I guess it is working:
migrated "/var/lib/tailscale/tailscaled.state" from plaintext to TPM-sealed format

by quotemstr

0 subcomment

And this is why in computing we can't have nice things. Any mass market profit can't, in a business realistic evaluation, ship something that breaks even 1% of users.
Consequently, we're stuck with lowest common denominator everything and have a hard time delaying software fixes for what ails us. Instead of fixing things, we are best encapsulate the damage.
If I were running Tailscale, I'd say "Fuck the people with broken TPMs. Fix your computers. We're going to be secure by default."
I guess there's a reason Avery and not I call the shots there

by maximgeorge

0 subcomment

[dead]

by lubasara

0 subcomment

[dead]

by 486sx33

0 subcomment

[dead]

by unit149

0 subcomment

[dead]

by lubasara

0 subcomment

[dead]

by l34zgl45y

0 subcomment

[flagged]

0 subcomment

by traceroute66

4 subcomments

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.