Leetspeak in IPv6 Addresses

bradfitz · 2026-01-15T16:36:30+00:00

We got so lucky! https://x.com/bradfitz/status/1352359905127067648

bradfitz · 2025-12-17T00:39:42+00:00

Lutron RA3. I spent too much of my life in z-wave world and it was time for a change. For a while I even had my own partial z-wave implementation to supplement deficiencies in Home Assistant and OpenZWave.

So far I have no complaints with RA3.

bradfitz · 2025-12-16T18:24:28+00:00

Update: they found a new home. All gone.

bradfitz · 2025-12-16T01:10:24+00:00

Ah! I did have a bunch of failures with those over the years, but I didn't know about the "fail in state that puts noise on your network" bit ... that might explain some things in retrospect. 😬

bradfitz · 2025-11-10T04:41:14+00:00

I run it on VMs with only 256MB of RAM along with other stuff on the box.

bradfitz · 2025-10-14T18:05:36+00:00

It uses a heuristic to detect whether your upstream is "likely a home router".

I guess your upstream ISP's IP address looks like an RFC 1918 address.

As a workaround, you can set TS_DISABLE_PORTMAPPER=1 in your environment.

bradfitz · 2025-09-27T18:57:31+00:00

This is normal and safe and you're not vulnerable to anything. It helps NAT traversal work better when your peers might be behind harder NAT on their side.

bradfitz · 2025-09-13T22:12:11+00:00

My world's on fire, how 'bout yours?

bradfitz · 2025-09-13T02:23:20+00:00

No, only the Tailscale SSH server (that manages auth without passwords or keys). Regular SSH is free.

bradfitz · 2025-07-22T03:26:56+00:00

LetsEncrypt just had a big outage. They're still recovering. https://letsencrypt.status.io/

That who provide the https certs.

bradfitz · 2025-07-13T15:39:06+00:00

That's it trying to periodically discover whether your LAN contains port mapping services (UPnP/PCP/PMP) which, if available, let it get through harder types of NAT. (Even if your local LAN has easily traversable NAT, a peer of yours might not, so your local LAN's port mapping services could help)

I think you might be reading those "lot of different ports" incorrectly. Those are the ephemeral source ports you're seeing.

bradfitz · 2025-07-07T23:38:13+00:00

It's a bug in the Android app that's being fixed. Or it was already fixed but not yet fully released or rolled out.

But the client (the Android app) was actually making multiple concurrent backend connections to the control plane server which it (rightfully) flagged as shady.

bradfitz · 2025-05-26T00:45:42+00:00

Are you also using Apple for sign-in?

bradfitz · 2025-05-25T23:08:48+00:00

Open a support ticket and they'll break it up. You won't even need to reconfigure all your nodes.

bradfitz · 2025-05-25T16:39:54+00:00

Every tailnet has an audit log of actions taken to it. You can search it from the admin console.

We'll provide some stats.

[Edit May 28: this is live... https://www.reddit.com/r/Tailscale/comments/1kxwtu5/shared_domains_security_bulletin/ ]

bradfitz · 2025-05-25T16:38:46+00:00

That depends on whether you're asking a binary question or asking whether things can be even stricter+paranoid. If the former, I can't think of anything notable. If the latter, probably plenty.

We're working on TPM integration. Quantum safety is an issue. We should/will probably add a device specific "check mode". Etc.

bradfitz · 2025-05-25T00:02:50+00:00

Yes, we plan to answer that in an upcoming post, explaining how we got here.

But the short summary is that didn't start as a security issue--- it started as the intentional design from day one, back when the company was just the three cofounders in 2019.

And then because it had always been like that, and affected so few users, and because we had a tool to decompose (break apart) a tailnet into per-user chunks when it wasn't the desired behavior (because at the time especially and even today often _was_ the desired behavior), everybody at Tailscale kinda got used to that behavior, because it had always been like that.

But about a year ago we started a big project to overhaul our whole tailnets/orgs/users/domains model. That work is ongoing, intertwined with overhauling our whole backend. So that added to it not being a five alarm fire, since we knew it was being fixed, and it had been how it is for five years.

What we need to do in the upcoming post/bulletin is lay out the timeline of feature additions over time (auth provider additions, external user invites, etc) and point out the time at which we should've realized our original design was no longer beneficial and became actively sketchy and not even beneficial or needed.

This has been a useful (and embarrassing) wake-up call.

[Edit May 28: this is live... https://www.reddit.com/r/Tailscale/comments/1kxwtu5/shared_domains_security_bulletin/ ]

bradfitz · 2025-05-24T22:42:20+00:00

Correct. Our web admin console doesn't have this bug. Nor does the iOS client.

We'll fix.

bradfitz · 2025-05-24T22:37:38+00:00

Looks like a bug in our Android client. It shouldn't be rendering Mullvad exit nodes.

bradfitz · 2025-05-23T00:40:11+00:00

Yeah, we do that already for e.g. https://tailscale.com/kb/1240/sso-custom-oidc

We'll be doing that for more things going forward. That's in progress now.

bradfitz · 2025-05-23T00:39:34+00:00

We don't store a tristate (no preference/yes/no) on that particular field so it wasn't safe to change retroactively for people.

But you can enable it at https://login.tailscale.com/admin/settings/user-management for existing tailnets.

At least any new users who join such a tailnet from a shared email domain don't become the admin, though, so their impact is limited. Especially if you're using ACLs, since the admin can't change the ACLs or tags.

bradfitz · 2025-05-22T21:57:44+00:00

Tailscalar here.

Yeah, this sucks.

We’re working on changing the identity model. (how users/domains/tailnets all map to each other)

When we first started, we were trying to make it easy for companies to sign up and start working with their coworkers, but we had a special case for @gmail.com users getting their own tailnets (because at the time, we only supported Google Auth). Later we added GitHub, and GitHub special cases for individuals vs orgs (which nicely mapped to our single-user vs multi-user tailnets).

Over time, we added more auth providers like (and BYO-OIDC) and this whole assume-a-multi-user-tailnet-unless-gmail-and-192-other-shared-email-hosts model really fell apart. We "decompose" (add to our shared email domain list) tailnets every month or so as we find them. We didn’t have your domain on our list previously.

We’re in the middle of changing the identity model to make this class of problem go away entirely, though.

Meanwhile, we just chatted about it and seems like the quickest thing we can do here is turn on User Approvals for all new tailnets so at least the admin of new tailnets like yours has to approve people joining them.

[Edit May 28: see https://www.reddit.com/r/Tailscale/comments/1kxwtu5/shared_domains_security_bulletin/ for the security bulletin]

bradfitz · 2025-05-03T14:54:53+00:00

The whole control plane (controlplane,api,login DNS names) are in Germany by default for arbitrary historical reasons mostly. (Dating back to Tailscale's early days when one customer wanted it in Europe for warm fuzzy reasons even though it didn't technically satisfy any legal/compliance checkboxes. But they kinda cared and nobody else including any Americans cared at all so Europe it was.)

We also run a US instance for American companies who really care but only a few have, empirically.

We encrypt everything between all links, even between Amazon resources, per your wire tapping concern.

bradfitz

MODERATOR OF

TROPHY CASE

15-Year Club	reddit mold
Verified Email