7 ms·
Calling out tailscale here is odd considering it's peer-to-peer and encrypted.
by vitno 2y ago
Calling out tailscale here is odd considering it's peer-to-peer and encrypted.
- chgs 2y agoWith keys controlled by a central entity
- Handprint4469 2y agodo you have a source for that?
- mikehotel 2y agoTailscale [0] says the private keys never leave the device. “Security Tailscale and WireGuard offer identical point-to-point traffic encryption. Using Tailscale introduces a dependency on Tailscale’s security. Using WireGuard directly does not. It is important to note that a device’s private key never leaves the device and thus Tailscale cannot decrypt network traffic. Our client code is open source, so you can confirm that yourself.” 0. https://tailscale.com/compare/wireguard https://tailscale.com/compare/wireguard
- sdht0 2y agoTo add to that, they also provides Tailnet lock [0], which protects from the only way the coordination server can mess with the tailnets, by connecting unauthorized nodes. [0] https://tailscale.com/kb/1226/tailnet-lock https://tailscale.com/kb/1226/tailnet-lock
- d-z-m 2y agoThat is true as far as it goes, but how does your node learn the public keys of the other nodes in your tailnet? My understanding is that they are provided by the coordination server, so you have to trust that the public key the coordination server gives you is actually the one for your peer device. Tailnet lock helps mitigate this by requiring that node public keys are signed by a trusted signing node, but it isn't bulletproof.
- Aerbil313 2y agoPublic key cryptography doesn’t work like that. If you were given wrong public keys you wouldn’t be able to connect to start with.
- d-z-m 2y ago> Public key cryptography doesn’t work like that Like what? I'm saying both sides of the connection would be given the wrong public keys by the coordination server. The private keys of which would be held by a MITM.