10 ms·

Let's Encrypt now supports ACME-CAA: closing the DV loophole

309 points by pabs3 4y ago

pabs3 4y ago
I note that this requires DNSSEC, which isn't very popular here on HN.
- ilyt 4y ago
  I still don't understand how industry got conned into thinking sending all your DNS requests to essentially one actor (DoH) is a good idea
  - mjevans 4y ago
    Too many ISPs hijacking requests to user configured DNS servers and too many ISPs providing default servers that 'helpfully' redirect to a placeholder domain with ads rather than just an NX record.
  - dinosaurdynasty 4y ago
    https://dnscrypt.info/public-servers https://dnscrypt.info/public-servers Lots of servers out there support DoH
  - pabs3 4y ago
    I got the impression that DoH/DoT are mainly for request privacy rather than security.
    - DistractionRect 4y ago
      It's about security. It keeps intermediate hops from hijacking your query and providing their own response. Unfortunately, it offers no privacy. DNS is usually the precursor to a tls connection, and the domain name is sent in cleartext during the tls handshake. So the same people who would hijack your DNS queries are still privy to them if you use DoH (routers, ISPs, governments, etc).
      - pabs3 4y ago
        DoT/DoH only stops one hop of the DNS resolution process from hijacking requests, so it isn't as good as DNSSEC for security. There is encrypted TLS handshaking for hiding the TLS domain name indicator. https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
        duskwuff 4y ago
        > ... so it isn't as good as DNSSEC for security. And DNSSEC doesn't provide any privacy to the end user. Both mechanisms provide something of value, and ideally they'd both be used together.
  - josephcsible 4y ago
    There's a lot of different DoH providers. And don't most people who aren't using DoH send all of their DNS requests to the same actor (usually their ISP) anyway?
  - mindslight 4y ago
    Centralized servers run by trusted [0] third parties is the foundation that most of the industry is built on. Surveillance dollars flow in, and mindshare follows. DNS seems eminently easy to secure against eavesdropping, given it is just distributed database, and a slowly consistent one at that. Someone just needs to step up to the plate and make a p2p resolver that communicates with a secure protocol, rather than the naive one spelled out in rfc1035. And with DNSSEC you wouldn't even have to worry about trusting/verifying other peers. [0] The formal definition of someone who can break you, not the common usage that implies "trustworthy".
    - pabs3 4y ago
      I like the GNU Name System for replacing DNS: https://www.gnunet.org/gns https://www.gnunet.org/gns
      - duskwuff 4y ago
        Every time people bring this project up, I have to say this again, so here goes: The purpose of a naming system is to give users a common way to consistently reference specific things. Anyone should be able to mention a name for a thing, and know that any other user will be able to look up that name and resolve it to the same thing. GNS missed this lesson. Under GNS, every user has their own, slightly different view of naming; a name which one user is able to resolve may not be resolvable for another user, or (even worse) other users might see it resolve to something completely different. There are many ways of defining how a "decentralized" naming system should work. This is one of them, and I'm sure it sounds cool, but it is not a good idea. Try again.
  - dimensi0nal 4y ago
    DNSSEC is not the same thing as DoH or DoT or DNSCrypt
  - dogecoinbase 4y ago
    It's to prevent DNS-based ad blocking (e.g. Pi-hole).
    - josephcsible 4y ago
      This isn't true. There are DoH servers that do ad blocking.
      - candiddevmike 4y ago
        Parent means from the IoT device side. DoH lets devices (say your TV) bypass a pi-hole and still reach ad servers. That's why I blackhole DoH on my network. Don't connect to my wireless if you want DoH privacy.
        SAI_Peregrinus 4y ago
        Bypassing your network's DNS doesn't require DoH, it just requires the IoT device to use its own DNS servers.
        candiddevmike 4y ago
        I redirect all outbound TCP/UDP 53 traffic to my DNS servers. I can't do that with DoH, so into the blackhole it goes
        josephcsible 4y ago
        Remember, if you can censor traffic at the network level, so can Comcast and China. Hopefully, there will eventually be a day when Microsoft, Google, Amazon, and CloudFlare all serve DoH from the same IPs they serve the rest of the websites they host from, so that it won't be feasible to block them anymore.
        SAI_Peregrinus 4y ago
        But they can run DoH on any server, they don't have to use CloudFlare or Google or whatever. So any port 80 connection is suspect. Same for any port 443 connection with DoT. Or any port whatsoever if they run their DNS (on any transport) on a "non-standard" port, which is not unheard of for such devices. DNS works on port 5353 just as well as it does on port 53. Redirecting outbound port 53 to your own servers has never been an effective way to stop devices from using their own DNS. DoH and DoT do make it harder to block (since they're authenticated), but even classic DNS can evade simple port-based redirection.
- akerl_ 4y ago
  It doesn't seem to actually require DNSSEC. Let's Encrypt will happily use these new fields to restrict issuance, the same way they were checking CAA records previously, for domains with and without DNSSEC.
  - dinosaurdynasty 4y ago
    It requires DNSSEC to prevent MITM between the CA and the domain's nameservers.
    - regecks 4y ago
      In this context, I think "requires DNSSEC" is an opinion at best. "Requires" is probably the wrong word. You are welcome to use CAA accounturi without DNSSEC and it will be effective. Your zone may be vulnerable to an active man-in-the-middle DNS attack (which is hard to pull off), but it will still be protected against somebody figuring out how to upload an /.well-known/acme-challenge/ file on your domain and issue an unauthorized certificate from a foreign ACME account. This attack is much easier - I did it against a popular mail provider a few years ago.
      - zinekeller 4y ago
        > This attack is much easier - I did it against a popular mail provider a few years ago. I guess this is Fastmail :)
        holigot 4y ago
        Can't even understand, why they do not give us some features like IPv6, DANE, DNSSEC and so on... https://fastmail.blog/historical/fastmail-dns-hosting/ https://fastmail.blog/historical/fastmail-dns-hosting/ In 2014 Rob Mueller wrote: "Our future DNS plans include DNSSEC support (which then means we can also do DANE properly, which allows server-to-server email sending to be more secure), DMARC record support, and ideally one day Anycast support to make DNS lookups faster."
  - 4y ago
- teddyh 4y ago
  I only ever see one person argue persistently against DNSSEC here on HN.
  - fomine3 4y ago
    I saw some criticism https://news.ycombinator.com/item?id=29378633 https://news.ycombinator.com/item?id=29378633
    - teddyh 4y ago
      …by that person.
  - akvadrako 4y ago
    Why should anybody? DNSSEC is almost irrelevant for the majority of domains. I've worked at a place that was pioneering it and found it over complicated and fragile, so haven't touched it since. If you implement it correctly you are slightly more secure but there are better ways to spend your time.
    - josephg 4y ago
      This is a big problem. I feel like the security world is trusting DNSSEC to close the unencrypted / unsigned DNS record shaped security hole. If its not something people actually want to implement because its a mess, what do we do? Do we need something better than DNSSEC? Is DoH good enough?
    - teddyh 4y ago
      I’ll just say that the same thing could be said (and was said, frequently and loudly) about HTTPS.
      - tptacek 4y ago
        No, it wasn't. I've been working in security since 1995. People have at times said that HTTPS was unnecessary for things like static content sites and blogs, sure. There has been pushback against the idea of doing HTTPS everywhere. But no serious person has ever pushed back against the need for HTTPS in some places. HTTPS and DNSSEC are not comparable. We've spent 25 years trying to have DNSSEC and not having it, and for a lot of us, the verdict is in: DNSSEC isn't necessary for a secure Internet.
Arnavion 4y ago
deleted I misread the text. The account binding is a new feature that's opt-in.
- CGamesPlay 4y ago
  Sounds like you didn't add "accounturi=https://some/lets-encrypt/account-id https://some/lets-encrypt/account-id", which is what your quoted excerpt is probably referring to.
  - Arnavion 4y ago
    Yes, I had a reading comprehension fail. I thought it was implying that the browser would be using the CAA record to validate the cert's issuing account, but it's the CA that uses it to validate new issuance requests.
jdong 4y ago
>(This isn't a particularly idle concern. Amazingly Microsoft once got a court to let it take operational control of the domain no-ip.org — that is, to actually hijack the domain — a dynamic DNS service used by countless people — simply because one user was apparently using it for malware-related purposes.) What a dishonest take. Microsoft didn't wasn't granted this court order because there was one bad no-ip user, Microsoft was granted the court order because there was a bad no-ip user that no-ip wouldn't take action against. Oh, and it wasn't one bad user. It was 22000 different hostnames.
- Fatnino 4y ago
  I have a domain on no-ip.org I remember when this happened and I was trying to debug why I couldn't reach my home server.
- Rygian 4y ago
  That's like your landlord handing the keys to your condo to the bully upstairs because you have a cockroach problem.
  - dotancohen 4y ago
    More like your landlord handing the keys to your condo to the bully upstairs because somebody else on your floor has a cockroach problem.
    - RobotToaster 4y ago
      Or to be more precise, the keys to every condo in the building.
  - rosnd 4y ago
    It's like a judge ordering you to hand over your keys to the person living underneath because you have a water leak you refuse to fix. Perhaps the water leak was caused by someone else, but it's still in your apartment.
    - 4y ago
teddyh 4y ago
To summarize: a CAA record might point to Let’s Encrypt, but anybody could sign up at Let’s Encrypt, so this does not protect anyone. But if the CAA record points at a specific account name at Let’s Encrypt (which it can now do), this closes that hole. This is similar to the lame delegation problem; i.e. where some old forgotten subdomain has a CNAME record pointing to some big hosting provider; although the site does not work anymore, the CNAME record is still there, and an attacker could get an account at that same big hosting provider and sign up with the same subdomain name, since the CNAME record is still valid. This way, they would get access to providing connectivity (web content, incoming e-mail) for a domain name they should not have.
bruce511 4y ago
>> Except, when this Domain Validation is performed, you don't have a certificate yet. That's why you're going through the process in the first place: to get a certificate. Which means that when the CA verifies that your domain is correctly hosting the challenge, it does so via ordinary, unencrypted HTTP... which can be trivially subject to man-in-the-middle attacks. This is not completely true. For HTTP challenge, yes its true. But for DNS Challenge its not. DNS Challenge requires the provisioning of a special DNS Text record. Assuming you are using an API with your DNS provider this can happen over HTTPS. (Indeed I can confidently say it would Have to be over HTTPS, or similar.)
- nmadden 4y ago
  > For HTTP challenge, yes its true. I know very little about ACME, but surely this (not having a cert yet) is only true the very first time you get a cert, or if you let the existing cert expire?
  - bruce511 4y ago
    Alas no. The http challenge method is http,regardless of whether you have an existing cert or not. However the protocol consists of a number of steps. Around 8 to 10 steps. For all but 1 of the steps you are the client connection, so these happen over https. So its not like the whole conversation is in the clear. The only step where the content is retrieved from the server is LE fetching a file, which is itself encrypted. So not over TLS, but the content itself is encrypted. So I'm not really sure how an MITM attack works here.
    - nmadden 4y ago
      As I understand it, the MITM attack is relying on the lack of authentication rather than lack of confidentiality. The attacker can go to LE and get a challenge file (AIUI), which they host on a fake version of the website. They then use DNS spoofing/cache poisoning/ARP spoofing/whatever to get the CA to hit their spoof website rather than the real one. This “proves” the attacker owns that domain and so they can then carry out the rest of the steps to get a cert. IMO its much harder to carry out this MITM against a CA compared to typical MITM attacks against end users. CAs generally speaking aren’t connecting to random wifi hotspots or using random ISPs etc. So you’d need to be in a pretty privileged network position to carry this out. And the multi-endpoint resolution approach seems like it would make it very hard indeed to pull off. That said, it seems a bit of a shame not to use the existing cert where one exists (which is presumably the case for most requests, which I’d expect are renewals).
diervo 4y ago
After all of the block-chain hype nonsense all these years, this might be the first truly prefect use case for append-only, publically auditable ledgers that makes all the sense in the world
- voiper1 4y ago
  ... which was still implemented without blockchain.
  - bawolff 4y ago
    To be fair, the definition of blockchain is so vauge that there is a reasonable argument that certificate transparency is a block chain. But yes i agree, CT is awesome and avoids the bitcoin BS.
- ajvs 4y ago
  Whilst blockchain-based domains like Namecoin are great for security they don't go far enough in my opinion. Certificate authorities and DNS infrastructure are heavily centralised at the root level, so something like the Handshake Protocol[1] is a necessary decentralised alternative. [1] https://handshake.org/ https://handshake.org/
- eru 4y ago
  Git is an append-only ledger of this kind. (Well, append-only plus regular garbage collection.)
Ayesh 4y ago
As much as a footgun HTTP Public Key Pinning was, HPKP would have solved a lot of issues/caveats mentioned in the article. That said, I'm going to add this for my domains (all of which use Letsencrypt anyway).
vbezhenar 4y ago
My ideal certificate issuance process should look as follows: I create private key. I publish corresponding public key at some standard DNS record. Then I can curl http://letsencrypt.org/cert/mywebsite.com http://letsencrypt.org/cert/mywebsite.com and letsencrypt responds with certificate (probably cached unless it decides to issue new one). So I can spend some time preparing this DNS configuration and then writing simple cronjob to fetch certificate every day and restart apache. That would be vastly superior to current certbot horror and as secure.
- xurukefi 4y ago
  That's a different proof of ownership model, though. If I understand it correctly, you set the DNS record once and then forget about it. Hence, you will only prove that you had control over the zone at some point in time. With the DNS-01 challenge you prove that you have control over the zone at the time you request the certificate, because it requires a new TXT record every time.
  - teddyh 4y ago
    But what could an attacked actually do in vbezhenar’s proposed protocol? An attacker could… get a new certificate for a private key they don’t have? How is that bad?
    - xurukefi 4y ago
      Well, you would only need to compromise a dns zone once and sneak in your DNS record. If the actual owner of the domain/zone does not carefully watch their records and if they use a different verification method for their certificates, then you'll have a continously operating backdoor. Maybe this is somewhat fabricated, but if you require a fresh challenge everytime, then that means the attacker has to maintain a compromised channel to the dns zone, which one could argue raises the bar significantly.
      - teddyh 4y ago
        A bit far-fetched, but sure. You could require that the certificate put into the DNS record also had, say, today’s date on it (UTC). This way, you’d fix the problem you describe but still have a vastly simpler process than ACME.
jesprenj 4y ago
> example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01" I have a domain with configured DNSSEC. Would publishing this make me as secure as publishing an accounturi? Would LetsEncrypt strictly disregard any non-DNSSEC queries to a DNSSEC domain?
- teddyh 4y ago
  The article states that Let’s Encrypt uses a validating resolver, so yes.
T3RMINATED 4y ago
ocdtrekkie 4y ago
We're just gonna keep patching holes in the PKI design instead of admitting it doesn't really work, I guess.
- tialaramex 4y ago
  Does "the PKI design" here mean specifically the Web PKI? Or do you mean Public Key Infrastructure in general? For PKI in general, you don't have any actual choice. This is actually why the Web PKI exists. SSL was originally conceived with no PKI, but upon analysis there's a trust problem. Why is this the right key? If I have no reason to believe it's the right key, Mallory can MITM me, the protocol achieved very little of value. So that's why there's the web PKI. If you don't like how the Web PKI works, it seems to me that improvements (of which there have been a great many in the 20+ years I've cared about it) are exactly "patching holes in the design" and so, yeah, duh, of course that's what we are going to do.
Snawoot 4y ago
Situation with certificate authorities is just getting ridiculous. Before that a lot of extensions were introduced to somehow (poorly) cover other security risks (CRL, OSCP, CT Log, ...). Now we admit that secure certificate issuance requires DNSSEC to be in place in order to make CAA work securely. Then why we have ditched DANE[1] in the first place? Why not infer public key trust directly from domain keys of DNSSEC? With dependence on DNSSEC, certificate authorities becoming fifth wheel. [1]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
- tialaramex 4y ago
  DANE wasn't deployable. It turns out that a lot of clients out there use some crappy DNS server, maybe they're required to, maybe that's just default configuration but either way that's not going to get fixed. Crappy DNS servers basically only know how to "make the web work" in the sense it worked in about 1995. They expect questions like A? some.web.server.example and they reply with an IP address, it might be the right IP address, but not always. These servers of course have no idea DNSSEC exists. When we send them anything else except 1995 style web browser queries they freak out, and either try to reply to it as though it was an A? query or they ignore the query. So you ask FANCY_MODERN_RECORD? web.site.example and it replies with an IP address even though that record's answer is a 64 byte compressed blob, or it silently ignores you... Here in 2022 things have changed... but only slightly. We mostly got DNS servers to answer AAAA? by doing something at least vaguely sane, in some cases even actual IPv6 answers like the specification says. We think some other records work, although not always. And clients learned "Happy eyeballs" a strategy to just try everything and use whatever worked. But many of the servers out there are still crap. The biggest change in 2022 is that lots of clients (especially web browsers) talk DoH. If you speak DoH (or DoT or any of these protocols but in practice it's DoH) you can actually get good answers from somebody whose DNS server works, a tremendous improvement. The browsers have by various means forced outfits who run such servers to actually do a competent job. Which means they implement DNSSEC, and, since the transport is TLS encrypted, you can choose to trust their validation answer. Which means today arguably DANE is somewhat deployable. But more practically, meanwhile we built a bunch of stuff which means instead of clients needing to do DANE, we can get away with DNSSEC to specialists. Many real world web users have crappy DNS, but Let's Encrypt can get traction or change to a different provider or build their own servers or whatever they want because it's part of their core mission.

309 points by pabs3 4y ago

pabs3 4y ago

I note that this requires DNSSEC, which isn't very popular here on HN.

ilyt 4y ago
I still don't understand how industry got conned into thinking sending all your DNS requests to essentially one actor (DoH) is a good idea
- mjevans 4y ago
  Too many ISPs hijacking requests to user configured DNS servers and too many ISPs providing default servers that 'helpfully' redirect to a placeholder domain with ads rather than just an NX record.
- dinosaurdynasty 4y ago
  https://dnscrypt.info/public-servers https://dnscrypt.info/public-servers Lots of servers out there support DoH
- pabs3 4y ago
  I got the impression that DoH/DoT are mainly for request privacy rather than security.
  - DistractionRect 4y ago
    It's about security. It keeps intermediate hops from hijacking your query and providing their own response. Unfortunately, it offers no privacy. DNS is usually the precursor to a tls connection, and the domain name is sent in cleartext during the tls handshake. So the same people who would hijack your DNS queries are still privy to them if you use DoH (routers, ISPs, governments, etc).
    - pabs3 4y ago
      DoT/DoH only stops one hop of the DNS resolution process from hijacking requests, so it isn't as good as DNSSEC for security. There is encrypted TLS handshaking for hiding the TLS domain name indicator. https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
      - duskwuff 4y ago
        > ... so it isn't as good as DNSSEC for security. And DNSSEC doesn't provide any privacy to the end user. Both mechanisms provide something of value, and ideally they'd both be used together.
- josephcsible 4y ago
  There's a lot of different DoH providers. And don't most people who aren't using DoH send all of their DNS requests to the same actor (usually their ISP) anyway?
- mindslight 4y ago
  Centralized servers run by trusted [0] third parties is the foundation that most of the industry is built on. Surveillance dollars flow in, and mindshare follows. DNS seems eminently easy to secure against eavesdropping, given it is just distributed database, and a slowly consistent one at that. Someone just needs to step up to the plate and make a p2p resolver that communicates with a secure protocol, rather than the naive one spelled out in rfc1035. And with DNSSEC you wouldn't even have to worry about trusting/verifying other peers. [0] The formal definition of someone who can break you, not the common usage that implies "trustworthy".
  - pabs3 4y ago
    I like the GNU Name System for replacing DNS: https://www.gnunet.org/gns https://www.gnunet.org/gns
    - duskwuff 4y ago
      Every time people bring this project up, I have to say this again, so here goes: The purpose of a naming system is to give users a common way to consistently reference specific things. Anyone should be able to mention a name for a thing, and know that any other user will be able to look up that name and resolve it to the same thing. GNS missed this lesson. Under GNS, every user has their own, slightly different view of naming; a name which one user is able to resolve may not be resolvable for another user, or (even worse) other users might see it resolve to something completely different. There are many ways of defining how a "decentralized" naming system should work. This is one of them, and I'm sure it sounds cool, but it is not a good idea. Try again.
- dimensi0nal 4y ago
  DNSSEC is not the same thing as DoH or DoT or DNSCrypt
- dogecoinbase 4y ago
  It's to prevent DNS-based ad blocking (e.g. Pi-hole).
  - josephcsible 4y ago
    This isn't true. There are DoH servers that do ad blocking.
    - candiddevmike 4y ago
      Parent means from the IoT device side. DoH lets devices (say your TV) bypass a pi-hole and still reach ad servers. That's why I blackhole DoH on my network. Don't connect to my wireless if you want DoH privacy.
      - SAI_Peregrinus 4y ago
        Bypassing your network's DNS doesn't require DoH, it just requires the IoT device to use its own DNS servers.
        candiddevmike 4y ago
        I redirect all outbound TCP/UDP 53 traffic to my DNS servers. I can't do that with DoH, so into the blackhole it goes
        josephcsible 4y ago
        Remember, if you can censor traffic at the network level, so can Comcast and China. Hopefully, there will eventually be a day when Microsoft, Google, Amazon, and CloudFlare all serve DoH from the same IPs they serve the rest of the websites they host from, so that it won't be feasible to block them anymore.
        SAI_Peregrinus 4y ago
        But they can run DoH on any server, they don't have to use CloudFlare or Google or whatever. So any port 80 connection is suspect. Same for any port 443 connection with DoT. Or any port whatsoever if they run their DNS (on any transport) on a "non-standard" port, which is not unheard of for such devices. DNS works on port 5353 just as well as it does on port 53. Redirecting outbound port 53 to your own servers has never been an effective way to stop devices from using their own DNS. DoH and DoT do make it harder to block (since they're authenticated), but even classic DNS can evade simple port-based redirection.
akerl_ 4y ago
It doesn't seem to actually require DNSSEC. Let's Encrypt will happily use these new fields to restrict issuance, the same way they were checking CAA records previously, for domains with and without DNSSEC.
- dinosaurdynasty 4y ago
  It requires DNSSEC to prevent MITM between the CA and the domain's nameservers.
  - regecks 4y ago
    In this context, I think "requires DNSSEC" is an opinion at best. "Requires" is probably the wrong word. You are welcome to use CAA accounturi without DNSSEC and it will be effective. Your zone may be vulnerable to an active man-in-the-middle DNS attack (which is hard to pull off), but it will still be protected against somebody figuring out how to upload an /.well-known/acme-challenge/ file on your domain and issue an unauthorized certificate from a foreign ACME account. This attack is much easier - I did it against a popular mail provider a few years ago.
    - zinekeller 4y ago
      > This attack is much easier - I did it against a popular mail provider a few years ago. I guess this is Fastmail :)
      - holigot 4y ago
        Can't even understand, why they do not give us some features like IPv6, DANE, DNSSEC and so on... https://fastmail.blog/historical/fastmail-dns-hosting/ https://fastmail.blog/historical/fastmail-dns-hosting/ In 2014 Rob Mueller wrote: "Our future DNS plans include DNSSEC support (which then means we can also do DANE properly, which allows server-to-server email sending to be more secure), DMARC record support, and ideally one day Anycast support to make DNS lookups faster."
- 4y ago
teddyh 4y ago
I only ever see one person argue persistently against DNSSEC here on HN.
- fomine3 4y ago
  I saw some criticism https://news.ycombinator.com/item?id=29378633 https://news.ycombinator.com/item?id=29378633
  - teddyh 4y ago
    …by that person.
- akvadrako 4y ago
  Why should anybody? DNSSEC is almost irrelevant for the majority of domains. I've worked at a place that was pioneering it and found it over complicated and fragile, so haven't touched it since. If you implement it correctly you are slightly more secure but there are better ways to spend your time.
  - josephg 4y ago
    This is a big problem. I feel like the security world is trusting DNSSEC to close the unencrypted / unsigned DNS record shaped security hole. If its not something people actually want to implement because its a mess, what do we do? Do we need something better than DNSSEC? Is DoH good enough?
  - teddyh 4y ago
    I’ll just say that the same thing could be said (and was said, frequently and loudly) about HTTPS.
    - tptacek 4y ago
      No, it wasn't. I've been working in security since 1995. People have at times said that HTTPS was unnecessary for things like static content sites and blogs, sure. There has been pushback against the idea of doing HTTPS everywhere. But no serious person has ever pushed back against the need for HTTPS in some places. HTTPS and DNSSEC are not comparable. We've spent 25 years trying to have DNSSEC and not having it, and for a lot of us, the verdict is in: DNSSEC isn't necessary for a secure Internet.

Arnavion 4y ago

deleted I misread the text. The account binding is a new feature that's opt-in.

CGamesPlay 4y ago
Sounds like you didn't add "accounturi=https://some/lets-encrypt/account-id https://some/lets-encrypt/account-id", which is what your quoted excerpt is probably referring to.
- Arnavion 4y ago
  Yes, I had a reading comprehension fail. I thought it was implying that the browser would be using the CAA record to validate the cert's issuing account, but it's the CA that uses it to validate new issuance requests.

jdong 4y ago

>(This isn't a particularly idle concern. Amazingly Microsoft once got a court to let it take operational control of the domain no-ip.org — that is, to actually hijack the domain — a dynamic DNS service used by countless people — simply because one user was apparently using it for malware-related purposes.) What a dishonest take. Microsoft didn't wasn't granted this court order because there was one bad no-ip user, Microsoft was granted the court order because there was a bad no-ip user that no-ip wouldn't take action against. Oh, and it wasn't one bad user. It was 22000 different hostnames.

Fatnino 4y ago
I have a domain on no-ip.org I remember when this happened and I was trying to debug why I couldn't reach my home server.
Rygian 4y ago
That's like your landlord handing the keys to your condo to the bully upstairs because you have a cockroach problem.
- dotancohen 4y ago
  More like your landlord handing the keys to your condo to the bully upstairs because somebody else on your floor has a cockroach problem.
  - RobotToaster 4y ago
    Or to be more precise, the keys to every condo in the building.
- rosnd 4y ago
  It's like a judge ordering you to hand over your keys to the person living underneath because you have a water leak you refuse to fix. Perhaps the water leak was caused by someone else, but it's still in your apartment.
  - 4y ago

teddyh 4y ago

To summarize: a CAA record might point to Let’s Encrypt, but anybody could sign up at Let’s Encrypt, so this does not protect anyone. But if the CAA record points at a specific account name at Let’s Encrypt (which it can now do), this closes that hole. This is similar to the lame delegation problem; i.e. where some old forgotten subdomain has a CNAME record pointing to some big hosting provider; although the site does not work anymore, the CNAME record is still there, and an attacker could get an account at that same big hosting provider and sign up with the same subdomain name, since the CNAME record is still valid. This way, they would get access to providing connectivity (web content, incoming e-mail) for a domain name they should not have.

bruce511 4y ago

>> Except, when this Domain Validation is performed, you don't have a certificate yet. That's why you're going through the process in the first place: to get a certificate. Which means that when the CA verifies that your domain is correctly hosting the challenge, it does so via ordinary, unencrypted HTTP... which can be trivially subject to man-in-the-middle attacks. This is not completely true. For HTTP challenge, yes its true. But for DNS Challenge its not. DNS Challenge requires the provisioning of a special DNS Text record. Assuming you are using an API with your DNS provider this can happen over HTTPS. (Indeed I can confidently say it would Have to be over HTTPS, or similar.)

nmadden 4y ago
> For HTTP challenge, yes its true. I know very little about ACME, but surely this (not having a cert yet) is only true the very first time you get a cert, or if you let the existing cert expire?
- bruce511 4y ago
  Alas no. The http challenge method is http,regardless of whether you have an existing cert or not. However the protocol consists of a number of steps. Around 8 to 10 steps. For all but 1 of the steps you are the client connection, so these happen over https. So its not like the whole conversation is in the clear. The only step where the content is retrieved from the server is LE fetching a file, which is itself encrypted. So not over TLS, but the content itself is encrypted. So I'm not really sure how an MITM attack works here.
  - nmadden 4y ago
    As I understand it, the MITM attack is relying on the lack of authentication rather than lack of confidentiality. The attacker can go to LE and get a challenge file (AIUI), which they host on a fake version of the website. They then use DNS spoofing/cache poisoning/ARP spoofing/whatever to get the CA to hit their spoof website rather than the real one. This “proves” the attacker owns that domain and so they can then carry out the rest of the steps to get a cert. IMO its much harder to carry out this MITM against a CA compared to typical MITM attacks against end users. CAs generally speaking aren’t connecting to random wifi hotspots or using random ISPs etc. So you’d need to be in a pretty privileged network position to carry this out. And the multi-endpoint resolution approach seems like it would make it very hard indeed to pull off. That said, it seems a bit of a shame not to use the existing cert where one exists (which is presumably the case for most requests, which I’d expect are renewals).

diervo 4y ago

After all of the block-chain hype nonsense all these years, this might be the first truly prefect use case for append-only, publically auditable ledgers that makes all the sense in the world

voiper1 4y ago
... which was still implemented without blockchain.
- bawolff 4y ago
  To be fair, the definition of blockchain is so vauge that there is a reasonable argument that certificate transparency is a block chain. But yes i agree, CT is awesome and avoids the bitcoin BS.
ajvs 4y ago
Whilst blockchain-based domains like Namecoin are great for security they don't go far enough in my opinion. Certificate authorities and DNS infrastructure are heavily centralised at the root level, so something like the Handshake Protocol[1] is a necessary decentralised alternative. [1] https://handshake.org/ https://handshake.org/
eru 4y ago
Git is an append-only ledger of this kind. (Well, append-only plus regular garbage collection.)

Ayesh 4y ago

As much as a footgun HTTP Public Key Pinning was, HPKP would have solved a lot of issues/caveats mentioned in the article. That said, I'm going to add this for my domains (all of which use Letsencrypt anyway).

vbezhenar 4y ago

My ideal certificate issuance process should look as follows: I create private key. I publish corresponding public key at some standard DNS record. Then I can curl http://letsencrypt.org/cert/mywebsite.com http://letsencrypt.org/cert/mywebsite.com and letsencrypt responds with certificate (probably cached unless it decides to issue new one). So I can spend some time preparing this DNS configuration and then writing simple cronjob to fetch certificate every day and restart apache. That would be vastly superior to current certbot horror and as secure.

xurukefi 4y ago
That's a different proof of ownership model, though. If I understand it correctly, you set the DNS record once and then forget about it. Hence, you will only prove that you had control over the zone at some point in time. With the DNS-01 challenge you prove that you have control over the zone at the time you request the certificate, because it requires a new TXT record every time.
- teddyh 4y ago
  But what could an attacked actually do in vbezhenar’s proposed protocol? An attacker could… get a new certificate for a private key they don’t have? How is that bad?
  - xurukefi 4y ago
    Well, you would only need to compromise a dns zone once and sneak in your DNS record. If the actual owner of the domain/zone does not carefully watch their records and if they use a different verification method for their certificates, then you'll have a continously operating backdoor. Maybe this is somewhat fabricated, but if you require a fresh challenge everytime, then that means the attacker has to maintain a compromised channel to the dns zone, which one could argue raises the bar significantly.
    - teddyh 4y ago
      A bit far-fetched, but sure. You could require that the certificate put into the DNS record also had, say, today’s date on it (UTC). This way, you’d fix the problem you describe but still have a vastly simpler process than ACME.

jesprenj 4y ago

> example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01" I have a domain with configured DNSSEC. Would publishing this make me as secure as publishing an accounturi? Would LetsEncrypt strictly disregard any non-DNSSEC queries to a DNSSEC domain?

teddyh 4y ago
The article states that Let’s Encrypt uses a validating resolver, so yes.

T3RMINATED 4y ago

ocdtrekkie 4y ago

We're just gonna keep patching holes in the PKI design instead of admitting it doesn't really work, I guess.

tialaramex 4y ago
Does "the PKI design" here mean specifically the Web PKI? Or do you mean Public Key Infrastructure in general? For PKI in general, you don't have any actual choice. This is actually why the Web PKI exists. SSL was originally conceived with no PKI, but upon analysis there's a trust problem. Why is this the right key? If I have no reason to believe it's the right key, Mallory can MITM me, the protocol achieved very little of value. So that's why there's the web PKI. If you don't like how the Web PKI works, it seems to me that improvements (of which there have been a great many in the 20+ years I've cared about it) are exactly "patching holes in the design" and so, yeah, duh, of course that's what we are going to do.

Snawoot 4y ago

Situation with certificate authorities is just getting ridiculous. Before that a lot of extensions were introduced to somehow (poorly) cover other security risks (CRL, OSCP, CT Log, ...). Now we admit that secure certificate issuance requires DNSSEC to be in place in order to make CAA work securely. Then why we have ditched DANE[1] in the first place? Why not infer public key trust directly from domain keys of DNSSEC? With dependence on DNSSEC, certificate authorities becoming fifth wheel. [1]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

tialaramex 4y ago
DANE wasn't deployable. It turns out that a lot of clients out there use some crappy DNS server, maybe they're required to, maybe that's just default configuration but either way that's not going to get fixed. Crappy DNS servers basically only know how to "make the web work" in the sense it worked in about 1995. They expect questions like A? some.web.server.example and they reply with an IP address, it might be the right IP address, but not always. These servers of course have no idea DNSSEC exists. When we send them anything else except 1995 style web browser queries they freak out, and either try to reply to it as though it was an A? query or they ignore the query. So you ask FANCY_MODERN_RECORD? web.site.example and it replies with an IP address even though that record's answer is a 64 byte compressed blob, or it silently ignores you... Here in 2022 things have changed... but only slightly. We mostly got DNS servers to answer AAAA? by doing something at least vaguely sane, in some cases even actual IPv6 answers like the specification says. We think some other records work, although not always. And clients learned "Happy eyeballs" a strategy to just try everything and use whatever worked. But many of the servers out there are still crap. The biggest change in 2022 is that lots of clients (especially web browsers) talk DoH. If you speak DoH (or DoT or any of these protocols but in practice it's DoH) you can actually get good answers from somebody whose DNS server works, a tremendous improvement. The browsers have by various means forced outfits who run such servers to actually do a competent job. Which means they implement DNSSEC, and, since the transport is TLS encrypted, you can choose to trust their validation answer. Which means today arguably DANE is somewhat deployable. But more practically, meanwhile we built a bunch of stuff which means instead of clients needing to do DANE, we can get away with DNSSEC to specialists. Many real world web users have crappy DNS, but Let's Encrypt can get traction or change to a different provider or build their own servers or whatever they want because it's part of their core mission.