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.
Doesn't capitalism demand infinite growth? If you don't have >= 2% YoY, the market thinks you're dead
No, it doesn't. There are plenty of businesses, and even entire industries that have operated for centuries on less than 2% growth. And yet somehow the world kept turning.
Unless you have anyone competent running the DNS config, or have a ticketing workflow of any kind, and I can't figure out what you think a DNS record with a onetime validation token could do if left unmanaged beyond some adversary discovery.
That's an overly technical way of looking at things. This issue is a whoopsie, not a catastrophic failure at AWS. It doesn't actually represent identity that much because anything critical has humans in the loop. The bank won't accept this as proof of identity. NYT won't accept this as proof of identity: if this bluesky account confessed AWS murders puppies NYT would call somebody they know at Amazon to check.
A company blog is a much bigger vulnerability when it comes to representing and verifying identity. Rather than let somebody fake identify to a computer system it allows faking identity to humans reading it. Yet I don't think most places require director signoff to post.
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.
> extra overhead for the registrars. Now they have one more thing to do:
I suppose I only take issue with "more" - as it stands don't registrars do effectively nothing today besides print money? It seems like the kind of business that doesn't require much that isn't already automated, and where the only reason I don't have a successful registrar business is that the contracts with whoever owns the actual TLDs are difficult to get. Perhaps they need to look out for DMCA letters? Idk maybe I'm way off, feel free to correct me if anyone knows it's a difficult job.
Instead of certificates, could you not use published tokens, using the same mechanism that registrars already use for publishing DNS NS "glue" records?
Find out what the CA uses for its DNS resolver. Attack it with cache poisoning, or BGP spoofing, or compromise the account controlling the target domain's nameserver records, or trick some other system into making a record you want.
The BGP attack requires knowledge of internet routing and the DNS attack requires knowledge of DNS server exploits, but either of them can be executed with very minimal network access that any consumer can get. Target the nameserver account admin with a phishing attack, account reset attack, lateral password bruteforce, etc.
You'd be surprised how incredibly stupid the admins of some of the largest computer networks are. It's really not hard to get access to some accounts. It should require more than just a username and password to hijack a domain, but usually it doesn't.
In any case, if all you want is a valid cert, you can do it a number of ways that nobody will notice. Again, this only has to work once, on any one of 130+ different organizations. Not all of them have stellar security.
And I'm not even talking about social engineering either the CA, Nameserver, or Registrar's support people, which I consider cheating because it's so much easier.
It's not as much that it's trivial (but it seems like it always is because social engineering never stops working) but that once the attacker has authed they can generally delete whatever extra file or record they made and stay authed, potentially hiding the attack.
Whereas, if that required a signature from a private key, with a counter or other log of use in the TPM, it'd be caught by an audit without having to notice the symptoms.
I know that in security design that I've been involved with there's a lot more scrutiny given to each use of a privileged key than there is to making sure that all website logging lists each file in the directory at each request, or logging the full public state of your DNS every minute. Requiring a signed request makes the attacker come in through the front door.
The person who owns the domain creates a private key and uploads the public key to the registrar when they buy the domain. Literally a 68 byte string. Not exactly hard to store. The domain name itself may be longer.
The domain owner creates a CSR and signs it using their private key. Sends it to the registrar. The registrar uses the public key the user uploaded to validate the signature. This happens millions of times a day on shitty computers, this is completely old boring technology.
Now the registrar sends the Registrar-Signed-CSR back to the user. The user sends the RS-CSR to a CA. The CA uses the Registrar's public key to validate the Registrar's signature (exact same process as before). Now the CA can see the Registrar signed it, so it's legit.
Easy to automate. Boring old technology. Same flow millions of computers use every day, just with one extra party in the middle.
How does the CA get the registrar's public key in a way that cannot be spoofed or hacked like you say DNS and HTTP verification can? If your thread model already includes hacking a CA's network infrastructure, getting them to accept the wrong key as valid doesn't seem any more difficult than the others.
DNSSEC adoption is pretty low outside of customers of large nameserver providers (that support DNSSEC out of the box), and also requires the registrar and registry support DNSSEC too. Unfortunately there are still some out there that don't.
> 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.
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.
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.
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.
