4 ms·

The concern is not encryption. Wireguard encrypts the traffic, and users could indeed verify this fact before traffic leaves their machines. The concern is tha

by aborsy 5y ago

The concern is not encryption. Wireguard encrypts the traffic, and users could indeed verify this fact before traffic leaves their machines. The concern is that, if an attacker (such as a government) compromises Tailscale, or Tailscale wants, they could probe your applications. It would be like your SSH being exposed to internet. These products bypass firewalls, which is a good thing if they are secure, and a terrible thing if they are not. There have been cases where the coordination servers have been (sometimes silently) compromised; see stories about encrypted phones. Users thought they were secure. And unfortunately small companies may not have sufficient resources to secure their infrastructure against more resourceful adversaries. That’s why it’s better to pay, so that the startups have funds to improve the product.

dblohm7 5y ago
Tailscale ACLs can prevent that.
- infogulch 5y ago
  This doesn't solve the problem it just shifts it so that the attacker also has to control ACL assignments as well as node creation.
  - klabb3 5y ago
    My knowledge in this domain isn't deep, but.. Isn't the main alternative also an ACL, just in the form of a more course grained firewall? The idea of these networks AIUI is that some of the existing infra, such as firewalls and even application level encryption, are replaced by something that is subjectively easier to administer and monitor. Not saying it is better, just that's it's different. And if it's different, then it makes sense that the attack surface is different too.
    - infogulch 5y ago
      Surely ACLs are controlled by the central authority (Tailscale), and not set on each individual device outside of the central authority's control. If so, then the whole ACL argument is moot because the threat model under consideration is that tailscale is compromised and attackers can modify the control plane.
      - chipsa 5y ago
        You have to worry about attackers modifying the control plane regardless of whether it's under your control or Tailscale's. You do need to collect the logs of how the nodes allowed to connect are changing to your SIEM. Which should be already done, because they already shove the (extremely verbose) logs into the appropriate places (eventlog on windows, journalctl on linux)
        infogulch 5y ago
        Obviously you have to secure your control plane. The question is who is securing it. I would rather be segregated from other users so I'm not swept up in a breach in tailscale that can compromise every user at once. It's a big single point of failure.
imran-iq 5y ago
Would something like headscale (https://github.com/juanfont/headscale https://github.com/juanfont/headscale) solve that concern?
jrockway 5y ago
I think by "adding encryption", they mean using mTLS internally. Your application can request that the client authenticate the connection by presenting a certificate, your application then applies whatever validation it wants before allowing that session to do anything. If someone were to compromise Tailscale, they can open a TCP connection to your application, but your application will then reject the connection because it doesn't trust the certificate. That's "zero trust" as I understand it. This is the direction I'd like to see networking go in general. Everything can have a public IP, but applications won't talk to anything that's unauthenticated. No more VPCs, VPNs, "kubectl port-forward", jumpboxes, etc. In practice, this is a colossal pain that nobody really knows how to do right. It requires rewriting all existing software, a secure way of issuing certificates (ideally not controlled by the cloud provider that runs your applications), and it can very easily fail open. (I do mTLS for my personal projects, but my cloud provider can easily issue themselves a trusted cert and use that to poke around if they really wanted to. They own the machines that my CA runs on, so they are the root of trust. At some point, what you end up with is something that feels correct, but is in practice the same thing as just trusting Tailscale. The first 99% of security is making sure some rando on the Internet can't download your HR database and secret plans for world domination. The remaining 99% of security is making sure the NSA can't do that. Maybe you're OK with the NSA mucking about with your internal network, and in that case, you can save yourself a lot of trouble.)

by aborsy 5y ago

dblohm7 5y ago

Tailscale ACLs can prevent that.

infogulch 5y ago
This doesn't solve the problem it just shifts it so that the attacker also has to control ACL assignments as well as node creation.
- klabb3 5y ago
  My knowledge in this domain isn't deep, but.. Isn't the main alternative also an ACL, just in the form of a more course grained firewall? The idea of these networks AIUI is that some of the existing infra, such as firewalls and even application level encryption, are replaced by something that is subjectively easier to administer and monitor. Not saying it is better, just that's it's different. And if it's different, then it makes sense that the attack surface is different too.
  - infogulch 5y ago
    Surely ACLs are controlled by the central authority (Tailscale), and not set on each individual device outside of the central authority's control. If so, then the whole ACL argument is moot because the threat model under consideration is that tailscale is compromised and attackers can modify the control plane.
    - chipsa 5y ago
      You have to worry about attackers modifying the control plane regardless of whether it's under your control or Tailscale's. You do need to collect the logs of how the nodes allowed to connect are changing to your SIEM. Which should be already done, because they already shove the (extremely verbose) logs into the appropriate places (eventlog on windows, journalctl on linux)
      - infogulch 5y ago
        Obviously you have to secure your control plane. The question is who is securing it. I would rather be segregated from other users so I'm not swept up in a breach in tailscale that can compromise every user at once. It's a big single point of failure.

imran-iq 5y ago

Would something like headscale (https://github.com/juanfont/headscale https://github.com/juanfont/headscale) solve that concern?

jrockway 5y ago

I think by "adding encryption", they mean using mTLS internally. Your application can request that the client authenticate the connection by presenting a certificate, your application then applies whatever validation it wants before allowing that session to do anything. If someone were to compromise Tailscale, they can open a TCP connection to your application, but your application will then reject the connection because it doesn't trust the certificate. That's "zero trust" as I understand it. This is the direction I'd like to see networking go in general. Everything can have a public IP, but applications won't talk to anything that's unauthenticated. No more VPCs, VPNs, "kubectl port-forward", jumpboxes, etc. In practice, this is a colossal pain that nobody really knows how to do right. It requires rewriting all existing software, a secure way of issuing certificates (ideally not controlled by the cloud provider that runs your applications), and it can very easily fail open. (I do mTLS for my personal projects, but my cloud provider can easily issue themselves a trusted cert and use that to poke around if they really wanted to. They own the machines that my CA runs on, so they are the root of trust. At some point, what you end up with is something that feels correct, but is in practice the same thing as just trusting Tailscale. The first 99% of security is making sure some rando on the Internet can't download your HR database and secret plans for world domination. The remaining 99% of security is making sure the NSA can't do that. Maybe you're OK with the NSA mucking about with your internal network, and in that case, you can save yourself a lot of trouble.)