Those aren't really comparable situations to an externally hosted "coordination server" which explicitly allows a third party to control access to your internal networks.
Security breaches happen every day, with serious consequences. These are real threats, and there are ways to mitigate against them.
A target like that coordination server is particularly risky because, as we saw with the massive Solarwinds attack, attackers will look for and expend effort to compromise the most attractive targets, and that's a particularly juicy one.
Dismissing such threats with false equivalences is a pretty good way to find yourself on the wrong side of a security breach.
Seems like it would be particularly tough to secure that coordination server. It handles metadata about not just nodes, but routing, ACLs, DNS, pre-auth keys, etc. And apparently in a way where it needs to understand the data versus just passing on encrypted bits that it can't read.
I guess you could split it in half, and pair it with some actual service that the customer runs, and let it just be a dumb relay of encrypted/signed/whatever data.
They are exactly the same situation. When you run other people's code you are explicitly giving them control over your stuff. Ken Thompson pointed this out back in 1984. ( https://dl.acm.org/doi/pdf/10.1145/1283920.1283940 )
Either you trust the entity whose code you are consuming or you don't.
Do you trust WireGuard to not get owned via a supply chain attack? Like Solar Winds.
Do you trust any open source project you currently use to be free from bugdoors? Like University of Minnesota recently demonstrated by submitting intentionally-vulnerable patches to the Linux kernel.
There a significant difference. When I run code, it is isolated from the people who wrote it. Someone providing a github library I compile into my code has no ability to later unilaterally come in and modify it. There is a gate where I have to ask them in, and I do tend to read the diffs first. There are only isolated windows of temporal vulnerability where I have to trust them, with mechanisms for dealing with that coherently.
An always-on service is an ongoing, continuous trust relationship with continuous temporal vulnerability
Consequently, while I can reasonably safely apply a lower bar of trust to libraries and code, someone asking to be continuously trusted must be held to a distinctly higher standard.
It is can be valid to trust that as well, but you're operating from a crippled starting point for your security engineering if you don't see those as separate categories of issues to address.
>Consequently, while I can reasonably safely apply a lower bar of trust to libraries and code, someone asking to be continuously trusted must be held to a distinctly higher standard.
Also, this seems backwards to me. You trust Tailscale at the network layer. If they abuse your trust to inject routes/keys your machine becomes network-reachable but all of your other controls are still in tact.
That's not true when you applications violate trust.
You can do AppSec if you don't trust the network.
You can't to NetSec if you don't trust the application.
You are necessarily claiming that a single person (you) is capable of adequately verifying the trustworthiness of the work of hundreds (perhaps even thousands) of developers.
That's just the story you tell yourself to convince yourself that you are in control.
Mean while FAANG have been doing it all wrong by hiring thousands of security engineers. They should've hired you.
Security breaches happen every day, with serious consequences. These are real threats, and there are ways to mitigate against them.
A target like that coordination server is particularly risky because, as we saw with the massive Solarwinds attack, attackers will look for and expend effort to compromise the most attractive targets, and that's a particularly juicy one.
Dismissing such threats with false equivalences is a pretty good way to find yourself on the wrong side of a security breach.