(Tailscale CEO) You have posted here multiple times that "none of the code has had a security audit" and that the SOC2 audit "is not the same thing."
It's true that those two audits aren't the same thing. However, the SOC2 auditor confirms, in the published report, that Tailscale has regular and ongoing security audits including penetration tests and many kinds of code reviews.
The security audit report, which you perhaps imagine to be a long list of vulnerabilities... doesn't look like that. It says we don't have a long list of vulnerabilities. The security bulletins are all here: https://tailscale.com/security-bulletins
The majority of your security bulletins are as the result of third-party reports to you.
Which, by definition, means they are not done by you, which means you don't know when they will be done or how much of your code base they are looking at.
I think you know full well what I mean by a security audit. If you don't, go look at, for example, the ones that Mullvad publish for their software https://mullvad.net/en/blog/tag/audits.
Please do not try to portray SOC2 as being the same thing as a code audit.
And IF you have regular code audits, then please publish suitably redacted reports in public on your website. Just like everyone else does !
(Tailscale CEO) I don't know what to tell you. The problems that are found internally, or via security reviews and pentests we pay for, are ones that we fix before releasing. They don't need bulletins.
Bugs that are found by other people are found, by definition, after release. They are therefore more likely to need a bulletin.
Is your theory that "any competent security review" will find every security hole in a product? Because that sure would be great if it were true. Unfortunately it does not match my experience.
The post you replied you clearly asked why insecure argument handling should be discovered after release. You widened that to mean “every security hole must be discovered prior to release” which made it a much easier argument to attack.
The point stands that the insecure argument handling could’ve been discovered by a security audit even when every security hole may not have been found.
i think its probably okay to drop it when you are this far deep into a conversation and the affiliation has already been stated multiple times in the existing comment chain.
But things like insecure argument handling are low-hanging fruit for security auditors.
Insecure argument handling is not like the more advanced subtle vulnerabilities that we are seeing in some LLM-assisted reports these days. Insecure argument handling is 1990's security.
The fundamental problem remains that Tailscale has too many new "features" being added to it the whole time. New features means a whole bunch new code. Which increases bloat and exponentially increases the attack surface.
It would be really nice if you could stop shoehorning in every new feature you can think of. Remove some of the existing ones that don't really need to be there. And get your codebase back to a more focused state, get back to your roots as a VPN product.
Stop trying to be all things to all men, as the old saying goes.
It appears that you have a major bone to pick with Tailscale and direct replies to your concerns do not seem to matter. They have a good security track record and are extremely widely deployed. I don’t see the evidence for your assertions that it is bloated and insecure.
<s>Read</s> Skimmed the report (and cheers for not gating it behind request-to-obtain) and I'm a bit surprised to not see any mentions of pentests which I'd expect given the large surface you host. What gives?
Japanese manufacturing addressed this too! There’s a whole branch of Deming’s work around supply chains and how it’s often worth working with “more expensive” suppliers when their quality is consistently high, because compensating for low quality inputs to your own work is far more expensive.
(Tailscale founder here) Two main differences: first, every DERP server used by your tailnet must be accessible by every node on your tailnet at all times, otherwise you get hard-to-debug netsplits. That's a very high bar to maintain so we've historically recommended you don't try. In contrast, peer relays are "if a given pair of nodes can connect through any of the relays, go for it" so deploying one is always a performance and reliability improvement.
Secondly, peer relays support UDP while DERP is TCP-only. That would be fixable by simply improving the DERP protocol, but as we explored that option, we decided to implement the Peer Relay layer instead as a more complete solution.
Hmm got it not sure I entirely understand. The issue I have is I’m trying to connect two devices where one is behind a hard CGNAT that always causes the connection to be relayed even though the other one is not behind a cgnat with proper port forwarding. Would a peer relay solve this but is it like a DERP where I have to host it on a VPS separate from my existing two networks or is this something different where I can host the peer relay on the same network not behind a CGNAT and somehow it will link the two networks through it?
> every DERP server used by your tailnet must be accessible by every node on your tailnet at all times, otherwise you get hard-to-debug netsplits.
What would allow a given pair of nodes access a peer relay? Isn’t the peer relay by default also accessible by every node on the tailnet since it’s in the tailnet as well?
[Tailscale CEO here] I see a lot of comments asking why Tailscale would branch away from our "core product" and build this thing that seems unrelated at first. One answer is that just about every single Tailscale customer (or homelab user!) is dipping their toes into AI right now, and they often come to us and ask how to integrate their stuff into Tailscale. Aperture is our answer to that.
A separate goal I have personally: demonstrate that anyone can build really neat stuff directly on top of the "Tailscale platform." One of my rules for the Aperture team was, you're not allowed to change core Tailscale, you have to build entirely on top as if you were some partner company. So this is a demo of how anybody can make pretty slick, easy-to-use, and yet highly secure stuff by building on Tailscale (the open source packages, or the commercial product, or both).
(I'm a Tailscale employee) The recent versions of the Tailscale k8s operator actually used a pre-release of the Services feature to do exactly that. So, not much difference. The official Services release is making that functionality available for more use cases (and generally better documented and user friendly).
You’re right except in the very specific case of the App Store purchase or download process. You only get one chance at FaceID and then it demands a password. But, if you cancel and do it again, you get another chance at FaceID. It’s mystifying why they’d make that UX choice.
(Tailscale cofounder here) Tailscale already gives every node on every tailnet a globally unique internal IPv6 address, that is reachable even if you don't have IPv6 on the "outside" network. If your apps and OSes are all willing to use IPv6, you haven't had a problem since the early days of Tailscale; they've been solved for years.
Alas, the "apps and OSes are all willing to use IPv6" problem is a persistent one, so we have to make IPv4 work too.
It’s possible to build a cache without any insight, but to make a cache that works well in a given domain requires knowledge from outside the world of caching itself. The same is true of summarization and compression.
Tailscale now supports custom OIDC providers. But if you already have the ability to host one, you won’t benefit from what’s in the above article (which is about hosting stuff at home even without a public IP address). https://tailscale.com/blog/custom-oidc/
It's true that those two audits aren't the same thing. However, the SOC2 auditor confirms, in the published report, that Tailscale has regular and ongoing security audits including penetration tests and many kinds of code reviews.
The security audit report, which you perhaps imagine to be a long list of vulnerabilities... doesn't look like that. It says we don't have a long list of vulnerabilities. The security bulletins are all here: https://tailscale.com/security-bulletins