← Back to context

Comment by traceroute66

2 days ago

@cronos

Question:

You link to https://github.com/tailscale/tailscale/issues/17654 where a user states[1]:

"Previous workaround from some comments (TS_ENCRYPT_STATE=false, FLAGS="--encrypt-state=false") didn't help on this problematic Debian 13 host"

And the same user states "I confirm this issue is NOT found anymore with tailscale version 1.92.1".

Could you provide a little extra context to clarify those types of comments which seem to suggest it wasn't state encryption after all ?

[1] https://github.com/tailscale/tailscale/issues/17654#issuecom...

3 comments

traceroute66

Reply
cronos  2 days ago

There are two new-ish features in Tailscale that use TPMs: node state encryption (https://tailscale.com/kb/1596/secure-node-state-storage) and hardware attestation keys.

Hardware key attestation is a yet-unfinished feature that we're building. The idea is to generate a signing key inside of the TPM and use it to send signatures to our control plane and other nodes, proving that it's the same node still. (The difference from node state encryption is that an attacker can still steal the node credentials from memory while they are decrypted at runtime).

We started by always generating hardware attestation keys on first start or loading them from the TPM if they were already generated (which seemed safe enough to do by default). That loading part was causing startup failures in some cases.

To be honest, I didn't get to the bottom of all the reports in that github issue, but this is likely why for some users setting `--encrypt-state=false` didn't help.