3 ms·

It's zero trust networking, unlike the internet or a traditional VPN.

mjg59 4y ago
And every definition of "zero trust networking" I can find still states that the point is that trust is something that's continually evaluated, which isn't the case if you're trusting someone simply because they're on your VPN.
- barnabee 4y ago
  Tailscale describe zero trust networking more eloquently than I can, here: https://tailscale.com/kb/1123/zero-trust/ https://tailscale.com/kb/1123/zero-trust/ The gist being that you are no longer making unverifiable trust assumptions about the identity of nodes connected to your network, as you have encrypted links between all nodes (not just between external nodes and a VPN gaetway to a non-zero-trust internal LAN) based on their verified identity and allowed access. A node's identity can be verified by its public key, so you no longer implicitly need to trust that only known and expected nodes are plugged into the switch in the office (for example). I do not have to care about whether the physical network infrastructure can be trusted (zero trust) because I can verify the identity of all nodes. This of course does not mean your entire architecture is zero trust. There are pretty much always trust decisions and assumptions somewhere, but that is why it's described as zero trust [mesh] networking, not zero trust complete end to end systems. edit/aside: some people prefer the term "trust minimising" rather than zero trust to emphasise that there's always trust somewhere and you are just pushing it outside of some component or layer, and I agree this is probably a better/more accurate term.
  - mjg59 4y ago
    You're describing the equivalent of 802.1x. Nobody would assert that enabling 802.1x turns your office LAN into a zero-trust network.
    - PLG88 4y ago
      Not quite. 802.1x provides an authentication mechanism to devices wishing to attach to a LAN or WLAN. Tailscale is describing to add E2E encryption between device to server so that if a malicious actor is on the underlay, they only see encrypted packets. I would instead assert that Tailscale's/Wireguard's approach of connecting devices is not zero trust as our focus should be on protecting 'services', not 'devices'. This requries micro-segmentation, least-privilege, attribute-based-access control, authenticate/authorise-before-connectivity as part of the overlay.
      - 7952 4y ago
        It is more zero trust than it would otherwise be though. An RDP server with tailscale can reject by default packets coming from a LAN. And you can get ALC before a connection can be made.
  - traceroute66 4y ago
    > Tailscale describe zero trust networking more eloquently than I can... Allow me to rephrase that for you ... Tailscale, a company whose business model relies on selling Wireguard-based VPN products, tries to convince people/prospective customers that a VPN can be shoehorned into the Zero Trust concept. If all you have is a hammer, everything looks like a nail as they say....
    - PLG88 4y ago
      Agreed, I literally just replied to the comment below, that TS/WG approach of connecting devices is not zero trust as our focus should be on protecting 'services', not 'devices'. This requries micro-segmentation, least-privilege, attribute-based-access control, authenticate/authorise-before-connectivity as part of the overlay.
      - roblabla 4y ago
        Tailscale does offer an ACL system[0] that allows protecting individual ports (which I assume is what is meant by services here?) and defaults to least-privilege (when ACLs are enabled, a node in the network cannot access other nodes by default). Though this configuration is centralized in the control plane. Does this not address some of those issues? I'm not well-versed in zero-trust networking, so I may be missing something fundamental. [0]: https://tailscale.com/kb/1018/acls/ https://tailscale.com/kb/1018/acls/
        PLG88 4y ago
        Good to know, the reference article does not talk about this and I was not aware of the feature set. My personal belief is that the term 'zero trust' comes in shades of grey. I personally believe that anything internet exposed is the lowest form, implementing a software-defined perimeter is the next, and that the final is to embed overlay networking into the application itself so we do not have to trust the WAN, LAN or even host OS network. I wrote a blog on this last year using Harry Potter analogies - https://netfoundry.io/demystifying-the-magic-of-zero-trust-with-my-daughter-and-opensource/ https://netfoundry.io/demystifying-the-magic-of-zero-trust-w...
dent9876543 4y ago
I would agree with that assessment — it’s applying something of a fuzzy concept to networking. Arguably it is doing it without a great explanation of how, why, and the trade offs, but then the zero trust concept itself is also still in its evolutionary phase. Zero trust isn’t about doing it in one place, and then leaving all other doors wide open (although that is one possible realisation). From a security standpoint, it should be about layering, and making it and based on relevant security anchors. For most people, the fact of being on an authenticated local network is a huge positive indicator. (Or more to the point, being outside of it is the indicator.) This is why, generally, home routers don’t leave the admin interface exposed to the WAN. Are we to advocate dropping the “deny WAN for /admin” rule simply because the admin GUI already has password access control?

And every definition of "zero trust networking" I can find still states that the point is that trust is something that's continually evaluated, which isn't the case if you're trusting someone simply because they're on your VPN.

barnabee 4y ago
Tailscale describe zero trust networking more eloquently than I can, here: https://tailscale.com/kb/1123/zero-trust/ https://tailscale.com/kb/1123/zero-trust/ The gist being that you are no longer making unverifiable trust assumptions about the identity of nodes connected to your network, as you have encrypted links between all nodes (not just between external nodes and a VPN gaetway to a non-zero-trust internal LAN) based on their verified identity and allowed access. A node's identity can be verified by its public key, so you no longer implicitly need to trust that only known and expected nodes are plugged into the switch in the office (for example). I do not have to care about whether the physical network infrastructure can be trusted (zero trust) because I can verify the identity of all nodes. This of course does not mean your entire architecture is zero trust. There are pretty much always trust decisions and assumptions somewhere, but that is why it's described as zero trust [mesh] networking, not zero trust complete end to end systems. edit/aside: some people prefer the term "trust minimising" rather than zero trust to emphasise that there's always trust somewhere and you are just pushing it outside of some component or layer, and I agree this is probably a better/more accurate term.
- mjg59 4y ago
  You're describing the equivalent of 802.1x. Nobody would assert that enabling 802.1x turns your office LAN into a zero-trust network.
  - PLG88 4y ago
    Not quite. 802.1x provides an authentication mechanism to devices wishing to attach to a LAN or WLAN. Tailscale is describing to add E2E encryption between device to server so that if a malicious actor is on the underlay, they only see encrypted packets. I would instead assert that Tailscale's/Wireguard's approach of connecting devices is not zero trust as our focus should be on protecting 'services', not 'devices'. This requries micro-segmentation, least-privilege, attribute-based-access control, authenticate/authorise-before-connectivity as part of the overlay.
    - 7952 4y ago
      It is more zero trust than it would otherwise be though. An RDP server with tailscale can reject by default packets coming from a LAN. And you can get ALC before a connection can be made.
- traceroute66 4y ago
  > Tailscale describe zero trust networking more eloquently than I can... Allow me to rephrase that for you ... Tailscale, a company whose business model relies on selling Wireguard-based VPN products, tries to convince people/prospective customers that a VPN can be shoehorned into the Zero Trust concept. If all you have is a hammer, everything looks like a nail as they say....
  - PLG88 4y ago
    Agreed, I literally just replied to the comment below, that TS/WG approach of connecting devices is not zero trust as our focus should be on protecting 'services', not 'devices'. This requries micro-segmentation, least-privilege, attribute-based-access control, authenticate/authorise-before-connectivity as part of the overlay.
    - roblabla 4y ago
      Tailscale does offer an ACL system[0] that allows protecting individual ports (which I assume is what is meant by services here?) and defaults to least-privilege (when ACLs are enabled, a node in the network cannot access other nodes by default). Though this configuration is centralized in the control plane. Does this not address some of those issues? I'm not well-versed in zero-trust networking, so I may be missing something fundamental. [0]: https://tailscale.com/kb/1018/acls/ https://tailscale.com/kb/1018/acls/
      - PLG88 4y ago
        Good to know, the reference article does not talk about this and I was not aware of the feature set. My personal belief is that the term 'zero trust' comes in shades of grey. I personally believe that anything internet exposed is the lowest form, implementing a software-defined perimeter is the next, and that the final is to embed overlay networking into the application itself so we do not have to trust the WAN, LAN or even host OS network. I wrote a blog on this last year using Harry Potter analogies - https://netfoundry.io/demystifying-the-magic-of-zero-trust-with-my-daughter-and-opensource/ https://netfoundry.io/demystifying-the-magic-of-zero-trust-w...

dent9876543 4y ago

I would agree with that assessment — it’s applying something of a fuzzy concept to networking. Arguably it is doing it without a great explanation of how, why, and the trade offs, but then the zero trust concept itself is also still in its evolutionary phase. Zero trust isn’t about doing it in one place, and then leaving all other doors wide open (although that is one possible realisation). From a security standpoint, it should be about layering, and making it and based on relevant security anchors. For most people, the fact of being on an authenticated local network is a huge positive indicator. (Or more to the point, being outside of it is the indicator.) This is why, generally, home routers don’t leave the admin interface exposed to the WAN. Are we to advocate dropping the “deny WAN for /admin” rule simply because the admin GUI already has password access control?