Comment by paxys
3 years ago
This is a terrible implementation of domain verification. dns-01 and http-01 are more or less standardized at this point. Use them, and don't roll your own. Reference: https://letsencrypt.org/docs/challenge-types/.
3 years ago
This is a terrible implementation of domain verification. dns-01 and http-01 are more or less standardized at this point. Use them, and don't roll your own. Reference: https://letsencrypt.org/docs/challenge-types/.
They definitely should have used HTTP-01 if they’re doing verification on the web, but since this is about using a domain as identity this really belongs in DNS.
The issue with DNS-01 (and HTTP-01 to a lesser extent) as someone else mentioned is that the user friction is really high.
I’ve been working on a solution to this that I’ve been meaning to post to HN and this seems like as good an opportunity as any so here it is: [1]
It’s a method of storing a hashed (and optionally salted) verifiable identifier (think email or mobile) at a subdomain to prove authority for a domain.
1. https://www.domainverification.org
> this really belongs in DNS.
And the primary way of identifying yourself is in fact DNS.
> I’ve been working on a solution to this
Your solution is almost identical to the BlueSky one: put a TXT record at _atproto.<domain> that resolves to a DID. The difference is that they mandate the DID spec and you do not. Which is totally fine! Just figured I'd let you know :)
Thanks for taking a look and for your comment.
Another key difference is that the _atproto TXT record is discoverable since it’s always at _atproto. Whereas the “verifiable identifier” I use isn’t discoverable because it’s hashed and used as a dns label.
The ultimate goal here would be for these records to be populated by domain registrars upon a domain being registered (with registrant’s permission obviously).
This could create a kind of fast lane for domain verification across providers like Google Ads, Facebook, Office365 and everyone else that requests DNS verification.
The worst thing is that hundreds of providers request domain verification TXTs at the zone apex:
dig target.com TXT
I don't get http-based verification in general. If you want to really prove someone owns a domain, make them change an authoritative DNS record. Everything else feels like it is begging for edge cases to crop up. Why should my social media or SSL certificate vendor care about my web servers?
I worked on a product that required DNS changes to set up. Especially for business accounts, the level of friction was STUNNING. We had it take months to get set up because the contact had to submit a ticket to IT, write up the business justification, get director level approval, get security approval, and so on before it could get done. We had customers who couldn't even figure out which group in their company managed DNS. Yeah, you can argue that those companies are broken, but as an outsider I have no influence over that. The result was just that they couldn't use our product. On the flip side, we had consumer and small business customers who had purchased domains through simple webhosting things that didn't give them the required level of access to create a record (and/or they couldn't figure out how to do it). We eventually added an HTTP option and the success rate and time to success both improved hugely.
Especially for business accounts, the level of friction was STUNNING.
Honestly, that's a feature, not a bug.
14 replies →
Both http and dns verification are stupid. Neither of them prove you own the domain.
http verification proves you temporarily control IP space relative to a viewer. dns verification proves you temporarily control name resolution relative to a viewer.
Both are trivially hacked, multiple ways. By the time someone finds out you did it (if they closely monitor CT logs, which nobody does) you've already had hours, days, weeks to run a MITM on any domain you want. The attack only has to work once, on any of 130+ CAs.
The solution is registrar-level proof. Cert request signed by the private key of the domain owner, sent to the registrar to verify, the registrar signs it if its true, it's sent to the CA who can see the registrar signed it. Now you know for a fact the domain owner asked for the cert. The only possible attack is to steal all three of the owner's private key, the registrar's private key, and a CA's private key.
I have been shouting about this for 10 years, none of the industry incumbents care. The internet is run by morons.
I can get behind registrar-level proof. And I can see why it won't happen, and it isn't because it's a bad idea.
One problem I see is the extra overhead for the registrars. Now they have one more thing to do: verify (sign) certificate requests. That extra work is probably enough to get registrars to push back against such a system.
The registrar would be assuming some of the functions of a CA. This would make it easier for a single entity be both registrar and CA. That would threaten the business model CAs and thus they'd push back against such a system.
If the CA were responsible for getting the registrar's verification for a certificate request then that'd add extra work for CAs, and thus the CAs would push back against it. If the domain owner was responsible for getting the registrar's verification for a certificate before submitting it to a CA, then the domain owners would be against it.
And this is all assuming that people could agree on a common set of protocols or data formats for this new system.
2 replies →
> ...dns verification proves you temporarily control name resolution relative to a viewer.
> Both are trivially hacked, multiple ways.
I'm genuinely curious how it is trivial to "control [authoritative] name resolution relative to a viewer".
2 replies →
> I have been shouting about this for 10 years, none of the industry incumbents care. The internet is run by morons.
Or maybe, just maybe, hear me out on this... maybe your proposal is not as smart as you think it is.
For one thing:
> Cert request signed by the private key of the domain owner, sent to the registrar to verify, the registrar signs it if its true
What exactly does the registrar verify, and how?
2 replies →
Doesn't mandatory DNSSEC also fix this?
1 reply →
> If you want to really prove someone owns a domain, make them change an authoritative DNS record.
You're not wrong (ignoring how easy it is to hack DNS), but at the same time it's hard enough to get people to buy their own domain name, nevermind understand the system well enough to add a TXT record.
It's a strategy that's fine to implement when your target audience is server admins. It's a terrible strategy when your target audience is everyday users who you hope own their own domain. Doubly so in a world where owning your own domain is so rare for individuals.
Convenience. DNS is routinely not automatable by API, or inconvenient to automate. HTTP, however, is normally easy to work with.
It's not even that it's not automatable, it's just that it follows a completely different control scheme and path than DNS.
for 99.99% of cases when a domain is pointed at me and I want to serve an SSL certificate for it, I can answer an HTTP-01 challenge. Needing to orchestrate a DNS challenge will always be a more complicated external thing.
HTTP challenge (and TLS-ALPN) are in-band, DNS is out-of-band.
Sure, adding a TXT record to verify domain ownership is fairly common and lots of tools still use it. But you either have to self host DNS (yet another container to maintain) or use your provider's API (yet another credential, yet another mailing list to subscribe to for inevitable breaking changes to the API).
In contrast, HTTP based verification often has built-in support with your webserver (Caddy) or only requires copy-pasting a few lines to your docker compose file.
There are edge cases, but they're also widely exploited so you won't run into them if you follow best practices.
If you control a domain's DNS entry but I can serve arbitrary content to users from its servers, who really owns the domain?
I think people don't want to put DNS admin credentials in places where they might get leaked. Would be cool if a DNS server or provider offered credentials that could only do ACME challenges and not change any other records.
> Would be cool if a DNS server or provider offered credentials that could only do ACME challenges
There's nothing preventing you from making the DNS record a CNAME to something under a zone that you're allowed to modify.
This is how one of my setups works; _acme-challenge.someservice.example.net is a CNAME to someservice.acme.example.net, and acme.example.net is served by a bind9 that allows dynamic zone updates based on TSIG-signed DNS update requests over WireGuard.
So the machine that hosts someservice has a DDNS key that signs DNS update requests for someservice.acme.example.net, and bind9 is configured to allow that key to change that record.
acme-dns[1] is probably what you might want if you are up for running your own bit of infra. Implements a simple rest api for changing the txt records for acme verifications and nothing more. It works nicely as a delegated nameserver.
[1] https://github.com/joohoi/acme-dns
DNS challenge is required for wildcards on LE at the very least.
But the reason for HTTP is pretty simple - it's extremely easy to implement. You only need to tell your ops to redir a subdomain to your app and you're done, you don't need DNS with API that have narrow enough permission to allow that one team in whole company to generate ACME stuff; most providers ACLs on DNS end at "this client have acesss to that domain via API".
It's not about proving ownership, if it was about proving ownership we would do this via something at the registrar level.
It's about proving /control/. If a domain name is pointed to me (my IP/CNAME) I control it and it is reasonable to allow that person to issue an SSL certificate for a domain (or subdomain) under their control. If you, as the domain owner, want to restrict that, CAA exists as your tool to do so.
HTTP-01 works really well for when you host a custom domain on a SaaS application. The domain ownership stays with the customer, and all they have to do is CNAME/ANAME to your server. No messing with DNS TXT or NS records, 3rd party DNS provider API keys, etc.