6 ms·

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

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?

chrismorgan 4y ago
Convenience. DNS is routinely not automatable by API, or inconvenient to automate. HTTP, however, is normally easy to work with.
- AdamJacobMuller 4y ago
  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.
deleted 4y ago
[deleted]
NavinF 4y ago
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.
CameronNemo 4y ago
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.
- yokem55 4y ago
  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 https://github.com/joohoi/acme-dns
- aaronmdjones 4y ago
  > 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.
AdamJacobMuller 4y ago
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.
paxys 4y ago
If you control a domain's DNS entry but I can serve arbitrary content to users from its servers, who really owns the domain?
ilyt 4y ago
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".
zippergz 4y ago
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.
- reaperducer 4y ago
  Especially for business accounts, the level of friction was STUNNING. Honestly, that's a feature, not a bug.
  - unethical_ban 4y ago
    [flagged]
    - CydeWeys 4y ago
      Anything touching the DNS records for the root of your entire web presence is not simple and needs substantial review.
      - unethical_ban 4y ago
        Adding a new DNS record for a new, specific purpose is simple and low-impact, technically.
        UncleEntity 4y ago
        …which gets promptly forgotten about after it’s initial use case and years later your user database gets sold on the internet. How many “low-impact” things have been compromised over the years, I wonder?
throwawaaarrgh 4y ago
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.
- mikea1 4y ago
  > ...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".
  - LawTalkingGuy 4y ago
    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.
  - throwawaaarrgh 4y ago
masukomi 4y ago
> 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.
gregmac 4y ago
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.

chrismorgan 4y ago

Convenience. DNS is routinely not automatable by API, or inconvenient to automate. HTTP, however, is normally easy to work with.

AdamJacobMuller 4y ago
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.

deleted 4y ago

[deleted]

NavinF 4y ago

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.

CameronNemo 4y ago

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.

yokem55 4y ago
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 https://github.com/joohoi/acme-dns
aaronmdjones 4y ago
> 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.

AdamJacobMuller 4y ago

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.

paxys 4y ago

If you control a domain's DNS entry but I can serve arbitrary content to users from its servers, who really owns the domain?

ilyt 4y ago

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".

zippergz 4y ago

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.

reaperducer 4y ago
Especially for business accounts, the level of friction was STUNNING. Honestly, that's a feature, not a bug.
- unethical_ban 4y ago
  [flagged]
  - CydeWeys 4y ago
    Anything touching the DNS records for the root of your entire web presence is not simple and needs substantial review.
    - unethical_ban 4y ago
      Adding a new DNS record for a new, specific purpose is simple and low-impact, technically.
      - UncleEntity 4y ago
        …which gets promptly forgotten about after it’s initial use case and years later your user database gets sold on the internet. How many “low-impact” things have been compromised over the years, I wonder?

throwawaaarrgh 4y ago

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.

mikea1 4y ago
> ...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".
- LawTalkingGuy 4y ago
  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.
- throwawaaarrgh 4y ago

masukomi 4y ago

> 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.

gregmac 4y ago

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.