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 :(
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.
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 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.
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?
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.)
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.
31 comments
[ 1.1 ms ] story [ 96.5 ms ] threadI think this category is "pop culture references".
> 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.
*Trained hostnames*: pihole, homeassistant
*Fabulous hostnames*: mewtwo, mew, bronzong
*Innumerable hostnames*: otx82wn9xnzcygap6bsc
There is "headscale", where you can self-host the backend. https://github.com/juanfont/headscale
this is confusing. is the "control server" proprietary? is that headscale?
Headscale is a 3rd party, open source, self-hosted, replacement for that piece.
https://github.com/egberts/tls-ca-manage
[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
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.
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.
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...
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?
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.