Security consideration: MITM

[Gigadoc2]

Hi, since you mention using this project for remote disk unlocking, I wanted to make you aware of another security risk with this approach.

You already mention how an attacker can read the tailscale authentication key, but focus on their ability on making connections into your tailnet (which you mitigate with ACLs). However, at this point the attacker can also just impersonate the machine in question and wait for you to connect and enter the disk encryption secret, exfiltrating it (possibly transparently as they can modify the initramfs to not connect to your tailnet afterwards, so you won't even see two devices instead of one on the tailnet).

Plain SSH-based initramfs solutions have a similar problem, in that an attacker can read out the SSH host key (alternatively it is generated on the fly and you have no way to verify it).

One way to combat this is to involve the TPM in this: You could encrypt the tailscale authkey with the TPM and bind it to either measured boot or secure boot, but AFAIK Debian neither measures nor verifies the initramfs, so it would require more custom setup.

[Radiergummi]

I'm also pondering this right now. There's the Mandos project, which is basically a service hosted somewhere in your infra that provides the decryption keys on-demand, if a client running in the initramfs authenticates with a token. Now, that token must be stored in plaintext in the boot disk; however, the Mandos server regularly checks whether servers are still up, and will refuse decryption key requests for servers that have been offline for too long.

Maybe that, in combination with tailscale-initramfs, would be a more robust solution. That introduces a lot of moving parts though, so there may be a better way.