Analyzing the public hostnames of Tailscale users | Hacker News Reader

Analyzing the public hostnames of Tailscale users

smitop.com

38 pointssmitop31 comments

Open articleView on HN

Made-up words: lois, gimli, thopter

I think this category is "pop culture references".

Extra funny that in the list under the chart these are separate lines:

> Non-descriptive words: spike, slab, cardinal

> Made-up words: lois, gimli, thopter

> Pokémon: mewtwo, mew, bronzong

Like... sort of valid groups, but not mutually exclusive.

*Hostnames belonging to the emperor*: corp

*Trained hostnames*: pihole, homeassistant

*Fabulous hostnames*: mewtwo, mew, bronzong

*Innumerable hostnames*: otx82wn9xnzcygap6bsc

Microservices that resemble flies from a distance.

I enjoy Tailscale, but their split-DNS approach for letsencrypt is a huge turn off. There's no need for my network topology to be exposed via certificate transparency logs.

What's the alternative?

Private PKI with Root CA

I made a little bash-only ditty on managing private CA

https://github.com/egberts/tls-ca-manage

The Caddy web server has a built in ACME compliant CA. Works well for a private CA, and it’s a couple lines in the config file.

That requires modifying your OS trust store[1], doesn’t it?

[1] And browser trust store if it doesn’t use the OS, and OpenSSL trust store if you use tools that don’t use the OS trust store, etc

What do you see as the alternative? And isn't all this opt-in, you can run your own dns and do let's encrypt yourself if you prefer?

This is the one big downside to certificate transparency. Allowing anyone to ascertain private host names is far from ideal. The immediate counter is to, “run your own CA,” but that comes with its own headaches for small use cases.

I use wildcard LetsEncrypt certs for securing internal stuff which seems to solve this particular issue.

Something like *.internal.mydomain.com - so that’s all that would appear in transparency logs.

I guess this means you have to manage your own internal DNS mapping to your Tailscale IPs though rather than using Tailscale’s convenience split-DNS.

If I can create a wildcard certificate for a domain by proving that I control DNS, why can't I use that cert as a "mini CA" to create valid certs that are a limited subset of the wildcard cert? Say I get a 90-day cert for *.example.com, and I want to use that to create a 30-day cert for a.example.com. I don't see how this would be abusable, and it would be nice for these scenarios where certs are used in a private network so you don't have to expose your internal hostnames to the world.

The short answer is: because client software doesn't implement that.

The longer answer is: the certificate system absolutely does support issuing sub-CAs with "name constraints", which would let LE issue you, instead of a wildcard host certificate, an intermediate CA which you can use to issue host certs only in your own part of the name space. It solves this problem very neatly.

However, see point 1 again: client support is lacking. OpenSSL and NSS handle it, IIRC the Windows and Android implementations are tolerable, but Apple's homegrown SSL implementation doesn't. (It's not even a new feature — it's in the original PKIX RFCs from, what, 25 years ago.)

And without client support, CAs aren't going to do the work to be able to issue them, which means we're stuck with the far-less-secure approach of wildcard certs with shared (!) private keys, or unconstrained sub-CAs.

Thanks, that makes sense. The only way I can see Apple making this change is if there were external pressure, which means implementing it without support for Apple products at first. Someone has to make the first move, and it won't be Apple.

I did a bit of searching and it looks like this feature has been requested a few times on the LetsEncrypt community site, and this [1] is the best thread I think. Commenters there bring up another potential roadblock: aiui current regulatory requirements mean that there's a bunch of manual paperwork for every issued CA, name constrained or not. If anyone could automate and operationalize that process it would be LetsEncrypt. It would still be a lot of work, on the same scale as their initial (long, arduous) effort to automate issuance of leaf certs. Maybe a solution could be found by leaning on DNSSEC as a stronger validation of domain ownership than dns01. (As a side benefit, it would also be a small step towards eliminating the need for CAs in general.)

[1]: https://community.letsencrypt.org/t/standardized-tools-for-a...

On-the-wire DNS forgery isn't even close to the biggest DNS hijacking threat (that'd be registrar account takeover), so it's hard to imagine a CA policy shift motivated by DNSSEC.

Isn't a sub-CA just another "intermediate", basically in the same way the actually CA certificate Let's Encrypt uses to sign is an intermediate?

In that case, I'd have expected the failure mode of something not supporting the name constraints extension to be that it doesn't recognize the constraints: it would accept any certificate issued by the sub-CA.

Is that not true? Or is the problem that Apple devices are a big enough target that allowing these bad certificates to be issued in the wild would be too much of a problem?

Mostly right, yes: You can mark the field containing the constraint as "critical" or "non critical", which indicates to the end software what it should do if it doesn't understand this constraint. Apple software doesn't understand it, so it looks at the critical bit (at least Apple got that right): you can choose whether to fail by having it accept invalid certificates for any other website on the planet, or to fail by having it reject the intermediate completely.

I just assume that any general CA who's issuing a sub-CA instead of a wildcard would be unwilling to leave it marked non-critical.

I would be satisfied with that solution. Sure it would exclude Apple devices until Apple gets its act together but at least we'd have something. Mark it as Beta and note that it doesn't support Apple prominently and maybe we can start making progress. CA management and issuance software is not very well developed and needs broad scale active use to get it into a usable state.

Apparently this issue has been resolved in newer Apple OS versions: https://news.ycombinator.com/item?id=29812443

Interesting. I’m using Tailscale with the split dns feature and my hosts don’t appear to be in the transparency logs. So which feature needs to be enabled to get exposed like this?

This happens when you turn on the HTTPS beta feature.

Why is the dataset so small? Surely there must be more than 312 Tailscale users who used tailscale cert?

I thought this seemed low too, but it’s a pretty new feature and if you’re the security conscious type already (by virtue of being a Tailscale user) you may already have your own certs setup for these internal hosts.

Why is the "community server" only allowing 25 users and other stuff. Is that a hard requirement or just to deter users from rolling their own server?

It appears to be a limit of 20 for the free tier, limited by the non-open-source hosted coordination server backend.

There is "headscale", where you can self-host the backend. https://github.com/juanfont/headscale

Everything in Tailscale is Open Source, except the GUI clients for proprietary OS (Windows and macOS/iOS), and the 'coordination/control server'.

this is confusing. is the "control server" proprietary? is that headscale?

Yes, the coordination/control server is closed source, and runs on Tailscale's servers.

Headscale is a 3rd party, open source, self-hosted, replacement for that piece.

oh. this is great. thank you.

Also for anyone wondering, the desktop clients can be pointed to a custom control server (eg self-hosted headscale) relatively easily; but the android app needs to be edited / recompiled / sideloaded; and the iOS app can’t be pointed at a custom server at all :(

Reply on news.ycombinator.com