News for hackers. Stuff that matters.
Re:Tailscale SSH by tptacek on Wednesday June 22, 2022 @01:30PM (#31839100)
How do you figure? The idea is that Tailscale is bypassing the kernel, which it can only do for requests coming in over the tailnet --- it gets those packets raw, directly from WireGuard, unlike the normal IP packets your kernel routes to/from localhost or an egress interface.
Re:Tailscale SSH by password4321 on Wednesday June 22, 2022 @02:10PM (#31839682)
It's not the same, but "Docker Network bypasses Firewall, no option to disable" https://github.com/moby/moby/issues/22054 (2016)
Re:Tailscale SSH by tptacek on Wednesday June 22, 2022 @02:13PM (#31839719)
You're right, it's not at all the same. The Tailscale bypass exists (1) only for traffic traversing Tailscale interfaces (by design, that's the only traffic it can impact, because Tailscale can't run a userland TCP/IP stack for non-Tailscale traffic), and (2) only for this one feature, and (3) only if you've explicitly allowed it for particular users in your Tailscale ACLs. It's not clear to me how you could screw it up to, e.g., amplify an SSRF attack.
Re:Tailscale SSH by password4321 on Wednesday June 22, 2022 @02:28PM (#31839897)
All I'm trying to point out is that advertising "this bypasses the firewall, by design" has been abused in the past.

[edit] It boils down to principle of least surprise, managing expectations, etc. - proper documentation is indeed key.

Re:Tailscale SSH by tptacek on Wednesday June 22, 2022 @04:22PM (#31841401)
You have to explicitly enable Tailscale SSH, both on the host and in the ACLs that allow users to use the feature. Tailscale's ACLs are much, much better than iptable rules (for instance: they have built-in unit testing).

(I'm not impartial about Tailscale.)

Re:Tailscale SSH by dekhn on Wednesday June 22, 2022 @08:02PM (#31843469)
> Tailscale's ACLs are much, much better than iptable rules (for instance: they > have built-in unit testing).

Humility helps a lot on the internet- the important thing about iptables is that it runs on millions, possibly billions of machines. Production systems that don't have unit tests but run at scale aren't worse than systems which are newly introduced but have fairly unknown implications.

Re:Tailscale SSH by tptacek on Wednesday June 22, 2022 @08:53PM (#31843854)
I'm sorry, I really don't know what you're trying to say here. I'm evaluating a set of engineering tradeoffs and reaching a conclusion about them; I'm not trying to psychoanalyze them.
Re:Tailscale SSH by dekhn on Thursday June 23, 2022 @11:42AM (#31850695)
Im trying to say you're better than iptables because your code has unit tests makes you look arrogant because iptables is a production system that operates successfully at such a large scale that it shows unit tests aren't an accurate measure of quality. I'm saying that when people talk like you did and criticize prod systems, you look arrogant, and humility- using terms like "we believe" rather than "is" help a lot in building user confidence.
Re:Tailscale SSH by tptacek on Thursday June 23, 2022 @12:31PM (#31851489)
Again: these are engineering details, not people; they aren't "arrogant". There is lesser engineering and there is better engineering. As someone who does quite a bit of work with iptables and who has used ACL systems like Tailscale's, I can tell you right off the bat that Tailscale's system is better, and if you have the option of using one or the other --- there are good reasons you might not be able to --- you should use something like Tailscale's, which is identity-aware, testable, dynamic, and simple. Obviously, if you're not using Tailscale at all, this is a moot point, for many reasons, including the fact that if you're not using Tailscale, you don't have to think about how it interacts with your iptables rules.

I'm not making a value judgement about people who need to keep using iptables. I might be making a value judgement about people who demand that everyone else keep using iptables.

Re:Tailscale SSH by dekhn on Thursday June 23, 2022 @12:38PM (#31851590)
OK, you're free to completely ignore my advice that you look arrogant, and that it might affect the uptake of your product from the very people who could lead the way to increased adoption.

But, my point still stands. You can't simply assert your system is better, it has to be proven at a scale similar to iptables before you can say that.

Re:Tailscale SSH by tptacek on Thursday June 23, 2022 @02:21PM (#31853163)
It's not my product.

(I'm not impartial about Tailscale, but I don't work there).

Re:Tailscale SSH by bbarnett on Wednesday June 22, 2022 @03:17PM (#31840555)
This sounds like more of a marketing thing, where the wording needs to employ care?
Re:Tailscale SSH by e12e on Wednesday June 22, 2022 @04:36PM (#31841554)
> [only for..] requests coming in over the tailnet

Well, that's certainly different from "all TCP port 22 packets" - I suppose some emphasis should be on "after the WireGuard decryption" (ie: over the wireguard interface). It's not entirely clear from the comment (but probably clear to engineers working on the tailscale code).

I read it as if tailscale snapped up packets before the kernel from (all) network interfaces...

Re:Tailscale SSH by tptacek on Wednesday June 22, 2022 @04:51PM (#31841707)
How could it possibly work otherwise? Tailscale owns the WireGuard connection, so it gets raw packets from WireGuard before the kernel.
Re:Tailscale SSH by e12e on Wednesday June 22, 2022 @08:29PM (#31843669)
It could work like a full userspace network stack, getting the packets on the wire before (instead of) the kernel (network stack)?
Re:Tailscale SSH by tptacek on Wednesday June 22, 2022 @08:58PM (#31843893)
How? (I can think of ways, and they're all horrible).
Re:Tailscale SSH by e12e on Thursday June 23, 2022 @06:53PM (#31856100)
The fact that all the ways are horrible is indeed why I was so surprised to (mis)read tailscale as having such capabilities... I'm happy I misunderstood.