Hacker News new | ask | show | jobs
by tprynn 2272 days ago
I enjoyed the post and like the idea of Tailscale[^1], but agreed. As long as there's some path to the Internet, you can't trust your LAN. I mean, that's kind of the whole point of modern network security: even on a trusted network, you can't trust the endpoints.

Consider a modernized example of the business app in the story: let's say this is an internal-facing webapp with no security features implemented. With tailscale you can implement network security controls that only allow access from specific endpoints (tied to user or service identities), but the point is that you don't trust those endpoints. Of course they could be phished/compromised, but they could also easily use a boundary-crossing attack like CSRF/SSRF to attack your insecure app. So no matter what, you need to implement standard web app security features.

[^1]: https://news.ycombinator.com/item?id=22644357

1 comments

(I'm from Tailscale) You've nailed the problem statement, but we are trying to find a better solution.

The current "zero trust networking" trend is actually not about distrusting the endpoints; it's about distrusting the network, and securing the endpoints. Tailscale lets you distrust the network and allow only trusted endpoints, which is a step.

You're right that more steps are needed before we can also prevent CSRF/SSRF attacks on internal-private services, but that ought to be done at a higher level, not in every single app. The latter is just too error prone, as we see over and over.

Curious what the higher-level solution to CSRF/SSRF is? I’m struggling to think how it could be prevented except at the browser level (for CSRF). And for SSRF if there’s a legitimate need for a network path between two services but one has an SSRF issue, how can you stop that?