Analyzing the public hostnames of Tailscale users

Getting the data

Browsers have been increasingly pushing for higher HTTPS adoption in recent times. Many browsers now display a “Not secure” indicator for websites that still use HTTP. For the most part, this is a good thing: HTTPS provides better privacy and security for users. However, it presents an issue for internal websites that are always accessed over a secure underlying transport layer anyways. The most common secure transport layer is the loopback address: since the traffic never leaves your computer, there is no risk of someone intercepting your traffic. As such, localhost is special cased to be treated a secure origin in Chromium and other browsers.

Another case of when the underlying transport layer already provides transport security is when the host is accessed over a virtual private network (VPN) that provides sufficent security. Tailscale is one such VPN solution. When the Tailscale daemon is running, it attempts to set the local DNS server to 100.100.100.100, and handles DNS traffic to that address locally, resolving certain special domains to CGNAT addresses that are used for aidentifying hosts.

# querying tailscaled's internal DNS server
$ dig @100.100.100.100 +short pop1.xerus-coho.ts.net
100.96.112.51

# querying public DNS server
$ dig @9.9.9.9 +short pop1.xerus-coho.ts.net
# [no addresses found]

When visiting websites hosted on nodes in one’s Tailscale network (Tailnet) in a browser, they are not treated as a secure origin – even though they are! Tailscale encrypts traffic as it is sent through the network using the public key of the recieving node. But since VPNs are completely transparent to the browser, it just doesn’t know that the underlying transport layer is secure.

Tailscale offers a solution to this problem: the tailscale cert, which provisions a Let’s Encrypt certificate for your ts.net subsubdomain using a DNS challenge. The Tailscale client asks the Tailscale backend to update the DNS for a subdomain to prove ownership of the domain. The private key and certificate signing request are generated locally, so Tailscale servers never know your private key. This provides no real additional security, it only serves to make browsers not display certificate warnings.

All certificates issued by Let’s Encrypt are appended to a public Certificate Transparency log. Certificates are added to a tamper-evident Merkle tree (like a blockchain, except each certificate gets its own block) by certificate authorities after they are issued. Browsers require that certain certificates appear in Certificate Transparency logs, and this includes the ones issued for ts.net subdomains. We can search through these Certificate Transparency logs to find all domains that have certificates issued for them. We can use this to find out what hostnames people are running tailscale cert on! (and Tailscale informs users of this fact when setting up TLS support for a Tailnet). Keep in mind that this data is biased towards hostnames that people want to create certificates for, so it might not be representive of all hostnames.

The data

I got all ts.net subdomains listed in certificate transparency logs on October 18, 2021, and ontologized all of them into a single category. In cases like johnny-surface-laptop, which include multiple categories, I used a category that combines the two: OS+User in this case. I probably have made some mistakes in collating the data. If you want to play with the data, you can grab the spreadsheet as a CSV (or from Kaggle, if for some reason that’s a thing you want).

Interesting results

The data includes the 312 Tailscale users who used tailscale cert, and a total of 464 hostnames. This means that the average user has 1.49 hostnames exposed using tailscale cert. First-level subdomains of ts.net represent Tailnets, and second-level subdomains are the actual hosts in Tailnets. The first-level subdomains have random labels, like xerus-coho to anonymize the Tailnet owner somewhat. The most is tailnet-cdb8 with 26, and in second place is corp with 9. corp appears to be used for services internal to Tailscale Inc. It shouldn’t be possible for the Tailnet part of the domain to be corp – it doesn’t fit the allowed name structures, but Tailscale gave themselves the one and only vanity name.¹ Here are those hostnames in corp: builds, bradfitz, paintest, tshello, test-builder, tsdev, changelog, bronzong, and pain(?).

Here’s what the most popular categories I assigned are:

Most hostnames describe how the host is intended to be used. More interesting are the 37% of names that are entirely unrelated to the intended use or hardware. This includes hostnames like:

• Non-descriptive words: spike, slab, cardinal
• Made-up words: lois, gimli, thopter
• Pokémon: mewtwo, mew, bronzong
• Random characters: nas484e5d, otx82wn9xnzcygap6bsc, o25e62iw8ab88gg8

Using a hostname unrelated to what is happening on the host allows for more flexibility if the use changes in the future. It makes less sense for host with a particular use determined at creation time, which can be reimaged or have their VM destroyed if that use isn’t needed anymore. Hostnames reflect if the host is treated like cattle or like a pet.

Only 14.2% of hostnames have duplicates: 86% of hostnames are unique.

Raspberry Pi related hostnames are suprisingly popular there.

Shared-hostname graph

Two Tailnets have a line between them if they share a hostname: The biggest clusters are networks with raspberrypi, the second largest is networks with pihole.