111–120 of 157 posts
Earlier quoted context omitted.
If you don't care to invest half an hour into learning some basics of how computer networking and in particular CIDR notation and subnet masks work, maybe it is not for you.
I see that you don't know what AllowedIPs does :)
At $work we use Tailscale mostly because we were running into too many random issues with NAT with our standard DIY Wireguard setup, especially when people were working from hotels and other places with half-ass network setups. But we don't trust Tailscale. Just look at the thousands of unresolved Github issues, many of which are actually quite important/useful but have been ignored for months and years. We very much…
Did you try Headscale? https://github.com/juanfont/headscale or netbird? The latter has been great for me.
Am aware of them but IIRC they are both unaudited which kind of brings us back to square one ? We would still end up running them at arms-length as we do with Tailscale at the moment.
Isn't Headscale server-side only ?
Also a bit strange that "Tailscale vs Netbird" doesn't feature more prominently on their "Compare Netbird" page. It is hidden behind "Load More". ;D
Earlier quoted context omitted.
Good point. I self host headscale but it also has the ssh feature, probably also insecure.
Not necessarily, it's a clean room implementation. Even if leading dashes was known/documented/tested to implement they might have done it differently. And maybe it was an implementation detail that it was ever allowed, but that's a weird username, headscale implementation happened not to allow it, and nobody ever noticed the discrepancy.
Earlier quoted context omitted.
The proper fix would be to not use getent CLI tool in their logic, but instead use proper system APIs for looking up user account entries, like one of earlier comments here already mentions. This is shocking amateur hour! My guess is they hastily threw together something hacky in early development, and forgot to replace it with a real, safe solution later.
The issue here is there is NO single system API for looking up user account entries on Linux. It's implemented in libc. So you need to link to libc. Tailscale is a Go binary, and they probably prefer it to be statically-linked. glibc NSS implementation also REQUIRES you to load `.so` so you just can't emulate it in Go. Then, "link to libc". Which libc? glibc? musl?
If you are writing go, you usually want to set CGO_ENABLED=0 by default, to avoid inadvertently introducing nonportable code. In this way, only the pure Go implementations are used and there is no need to link (statically or dynamically) against a libc implementation to compile and run your programs.
At $work we use Tailscale mostly because we were running into too many random issues with NAT with our standard DIY Wireguard setup, especially when people were working from hotels and other places with half-ass network setups. But we don't trust Tailscale. Just look at the thousands of unresolved Github issues, many of which are actually quite important/useful but have been ignored for months and years. We very much…
This is a poor measure of quality. I've spent considerable time knee-deep in these issues in particular and the vast, vast majority of them are feature requests, bug reports awaiting more information from the submitter, or bug reports that cannot easily be reproduced (likely conflicts with other software). On the whole, Tailscale does an excellent job of "just working" in practically every possible environment. They do an incredible job thriving in the diverse ecosystem of software networking and their work will naturally never be remotely done. There will always be gaps, it's the nature of the beast. I'm not aware of any other product that does a better job here.
If you've spent any time dealing with enterprise software you'd know that there is an infinite firehose of these sort of issues. We're lucky that Tailscale keeps these public. Many other vendors track these sort of issues privately.
If there are particular issues which jeopardize the security posture of Tailscale deployments that have been open for a significant amount of time, my clients and I would love to know. Please share!
> We very much fear at $work that there are vulnerabilities in the Tailscale product awaiting discovery. Especially as, AFAIK, Tailscale have never had a formal security audit on their software.
I can't take this seriously. If you were a customer you could, you know, ask them? Or inspect their SOC2 documents?
I absolutely guarantee they undergo regular formal security audits. There's no question.
> So we install it on hardened bastion hosts in an old-school "jump host" model. So people can still get access to where they need to be, but we don't need to install Tailscale's unaudited shit on every single server / vm / etc.
Bastion hosts are a terrible model in 2026. I can't take this approach seriously.
> we don't need to install Tailscale's unaudited shit on every single server / vm / etc.
You never need to do this. Simply create an exit node into your subnet, and everything you want becomes routable.
It sounds to me like your architecture struggles with a zero-trust network approach if you view this as a blocker. I've got some slots available if you need a consultation!
> In terms of SSH, we use old-school OpenSSH and SSH certificates. Its really not that difficult and its really not expensive, you can do offline signing with Yubikeys, no need for expensive HSMs.
It's expensive in terms of engineer-hours, especially compared to Tailscale. It's also easy to get wrong, and end up with the same vulnerability as TFA, or worse.
But my main issue is that if you see this as equivalent it's telling me that you're not really the target audience. Your set-up is far more vulnerable than the out-of-the-box experience you get with Tailscale. If you don't mind, then I'm happy for you.
Lastly, I don't work for Tailscale and I'm not affiliated with them in any way beyond being a happy user that has solved a lot of problems very easily with their product. I highly recommend it to practically everyone. It's great.
I'm having a hard time taking your comment seriously. It just seems like non-constructive FUD.
> Tailscale SSH now rejects usernames with leading dashes. Is the proper fix not restricting users not possible in these poorly designed ancient systems? Similarly re another issue: why not just fix the permission issues instead of restricting users? > Tailscale now disallows the use of UIDs or numeric-only usernames via SSH to avoid this ambiguity
There is a whole class of security issues where fixes are worse that the issues themselves . Case in point, the OpenSSH itself that sends 100 packets on each keystroke to avoid timing attacks.
No ED25519 host key is known for $host and you have requested strict checking.Earlier quoted context omitted.
The issue here is there is NO single system API for looking up user account entries on Linux. It's implemented in libc. So you need to link to libc. Tailscale is a Go binary, and they probably prefer it to be statically-linked. glibc NSS implementation also REQUIRES you to load `.so` so you just can't emulate it in Go. Then, "link to libc". Which libc? glibc? musl?
But of course there is, it's part of POSIX, implemented in libc. And if you're using a higher level language, they all have their own wrappers around libc/POSIX APIs. Here is golang's: https://pkg.go.dev/os/user
At $work we use Tailscale mostly because we were running into too many random issues with NAT with our standard DIY Wireguard setup, especially when people were working from hotels and other places with half-ass network setups. But we don't trust Tailscale. Just look at the thousands of unresolved Github issues, many of which are actually quite important/useful but have been ignored for months and years. We very much…
> we don't trust Tailscale. Just look at the thousands of unresolved Github issues, many of which are actually quite important/useful but have been ignored for months and years. This is a poor measure of quality. I've spent considerable time knee-deep in these issues in particular and the vast, vast majority of them are feature requests, bug reports awaiting more information from the submitter, or bug reports that ca…
Well, they clearly don't if they have an "insecure argument handling" vulnerability.
As others here have said already here, its an "venerable and ancient class of bugs".
Its the sort of thing that should be picked up by modern defensive programming that includes fuzz testing.
And it is CERTAINLY the sort of thing that should be flagged by any competent security audit. "insecure argument handling" is bread-and-butter for security auditors.
> I can't take this seriously. If you were a customer you could, you know, ask them? Or inspect their SOC2 documents?
SOC2, ISO27001 and all that shit is not the same thing.
As I said, anyone serious who is proud of having had their software audited as clean would publish their reports in public. Nothing to hide. And it strengthens your case with customers.
It can always be a suitably redacted management summary written by the auditor. That's what everyone else does.
I'll stick to my 100% self-hosted Wireguard setup, thank you very much.
Why not tailscale plus head scale for self hosting?