4 ms·

Does the DNS method require proving you control the IP space for the domain, or is a DNS TXT really the only thing you need to generate a certificate?

schoen 9y ago
Just a TXT record. https://tools.ietf.org/html/draft-ietf-acme-acme-03#section-7.4 https://tools.ietf.org/html/draft-ietf-acme-acme-03#section-...
- peterwwillis 9y ago
  Wow. A lot of sites are going to get owned.
  - schoen 9y ago
    We've been using TXT records to authenticate certificate requests since Let's Encrypt launched. That hasn't changed.
    - peterwwillis 9y ago
      Without verifying who controls the IP space? If you don't verify who controls the IP space, then if you can control the DNS, you can generate certs. Certs that appear valid to unsuspecting users. Putting that kind of trust in DNS is pretty crazy considering how insecure most DNS setups are. Not to mention general attacks on DNS. There's even a potential chicken and egg problem, if you need DNS to secure your HTTPS, but you use HTTPS to manage your DNS. What's really crazy too is it seems like this can't even be avoided. Even if I'm not using Let's Encrypt, if someone owns my DNS, they can use Let's Encrypt to get valid certs for my domain. That's insane. What am I missing here?
      - cbo100 9y ago
        > What am I missing here? If I "own your DNS" wouldn't I just change them all to an IP space I control anyway? (If that was a requirement). Unless I'm missing something, requiring "owning the IP space" seems to be an impossible requirement to fulfil. I'm on a virtual host in Azure/AWS/Linode I have no way of proving I own the IP (because I don't).
        deleted 9y ago
        [deleted]
      - tialaramex 9y ago
        If you're concerned about DNS security you can use DNSSEC and Let's Encrypt will cheerfully require DNSSEC signed answers. If your situation really is that you have unsecured DNS that routinely gets hacked and you just sort of muddle among somehow with users frequently getting phished, malware downloaders, and so on, well, I guess Let's Encrypt doesn't magically solve the trouble you've stepped in.
      - schoen 9y ago
        I'm not quite sure how to answer this. DNS is used as ground truth for an enormous amount of certificate issuance by a broad range of CAs. This has been true for many years. Let's Encrypt didn't invent domain validation or the notion of relying on DNS as a basis for issuing DV certificates.
        peterwwillis 9y ago
        Honestly, it just hadn't occurred to me at all that DNS was the only thing stopping a blackhat from generating valid certs and siphoning or modifying traffic without anyone's knowledge. And users literally can't stop this other than to only accept EV certs, breaking most of the web. This is pretty nutty. At the very least, a public key in WHOIS should be required to generate certs. Why in the world isn't this being done? And is there some way Let's Encrypt can start checking for this (to not issue invalid certs for domains that do list a public key), so maybe the above insanity can be stemmed?
        snowwolf 9y ago
        How do you add that public key to the WHOIS register - Via your domain registrar (and it would have to be updateable/changeable outside of renewal cycles). Who is your DNS provider 90% of the time? Your domain registrar...
        schoen 9y ago
        > At the very least, a public key in WHOIS should be required to generate certs. Why in the world isn't this being done? And is there some way Let's Encrypt can start checking for this (to not issue invalid certs for domains that do list a public key), so maybe the above insanity can be stemmed? I would welcome an authenticated channel to domain registrars, and I would welcome making checking it mandatory for CAs. I think the lack of this is an unfortunate gap, although I don't think we've seen the epidemic of misissuance that you've worried about. In order to make this happen, it would probably require some coordination between ICANN and the CA/Browser Forum. You can become an Interested Party at the CA/Browser Forum yourself in order to propose this kind of mechanism, or you can find an existing Member or Interested Party to bring it up. I already participate as an Interested Party and I could bring it up eventually but I'm currently working on certificates for Tor onion services, and I'd rather get that finished before taking on something else. There may have been previous discussions of this idea in some forum, but I don't know for sure where. By the way, DNSSEC plus DNS CAA can already allow a domain registrant to use cryptographic means to forbid issuance by unauthorized CAs, and checking this is already mandatory for CAs. https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au... This can achieve some of what you want on the negative side, but it's presumably not all the way there.
      - pfg 9y ago
        By "verifying who controls the IP space", do you mean verifying control over the IP a domain resolves to? In that case, what you're missing here is that control over DNS lets you alter that IP address to whatever you'd like. The attacker will have no difficulty demonstrating control over an IP address they own.
      - alwillis 9y ago
        https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#dns-security https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-... DNS security As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates. Servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP. An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names. Because the security of such validations ultimately depends on the authenticity of DNS data, every possible precaution should be taken to secure DNS queries done by the CA. It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains which choose to make use of DNSSEC. An ACME-based CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed. It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.).
      - snowwolf 9y ago
        How would you go about verifying the domain from who controls the "IP space"? A cloud provider/datacenter controls the IP space in the majority of cases. If someone owns your DNS, they can use almost any CA to get valid certs for your domain (apart from EV only ones). That's kind of how Domain Certs work. "A domain-validated certificate (DV) is an X.509 digital certificate typically used for Transport Layer Security (TLS) where the identity of the applicant has been validated by proving some control over a DNS domain" If this is something that worries you, then you should only trust sites that have Extended Validation certificates.
        peterwwillis 9y ago
        > If this is something that worries you, then you should only trust sites that have Extended Validation certificates. Every user of the web in the world would have to do this in order to avoid this vulnerability.
        snowwolf 9y ago
        Exactly. Domain verified certificates guarantee one thing and one thing only. The data transmitted is encrypted and cannot be tampered with. That's it. They do not guarantee you are communicating with who you think you are. But to be honest if your DNS service is compromised, you have bigger problems.
        peterwwillis 9y ago
        The thing is... it shouldn't be this way. The whole point of TLS is to provide privacy, integrity, and authority. Having a secured connection is pointless if it's a connection to an attacker. Oh, great, nobody can spy on my connection to the NSA. All DNS is supposed to do is to point you at the server to get your connection from. It isn't supposed to mediate the security of the connection. This is back to the old chicken-and-egg of public key crypto: public key connections are secure, as long as you provide the initial host key in a secure, out-of-bound method. If an attacker can circumvent this and inject their own initial host key, they can MITM. Hence why PKI exists: to prevent an outside service from defeating the security of the connection. But apparently, DNS can compromise the connection, by allowing attackers to just generate certs willy-nilly if they can guess your GoDaddy account password.
  - alwillis 9y ago
    >Wow. A lot of sites are going to get owned. Why would you say such a thing? Tens of millions of certificates have been provisioned using the ACME protocol without issue. There’s a lot of cryptography behind the scenes that leads up to the TXT record being generated. You can read all about it at https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#dns-challenge https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-...

schoen 9y ago

Just a TXT record. https://tools.ietf.org/html/draft-ietf-acme-acme-03#section-7.4 https://tools.ietf.org/html/draft-ietf-acme-acme-03#section-...

peterwwillis 9y ago
Wow. A lot of sites are going to get owned.
- schoen 9y ago
  We've been using TXT records to authenticate certificate requests since Let's Encrypt launched. That hasn't changed.
  - peterwwillis 9y ago
    Without verifying who controls the IP space? If you don't verify who controls the IP space, then if you can control the DNS, you can generate certs. Certs that appear valid to unsuspecting users. Putting that kind of trust in DNS is pretty crazy considering how insecure most DNS setups are. Not to mention general attacks on DNS. There's even a potential chicken and egg problem, if you need DNS to secure your HTTPS, but you use HTTPS to manage your DNS. What's really crazy too is it seems like this can't even be avoided. Even if I'm not using Let's Encrypt, if someone owns my DNS, they can use Let's Encrypt to get valid certs for my domain. That's insane. What am I missing here?
    - cbo100 9y ago
      > What am I missing here? If I "own your DNS" wouldn't I just change them all to an IP space I control anyway? (If that was a requirement). Unless I'm missing something, requiring "owning the IP space" seems to be an impossible requirement to fulfil. I'm on a virtual host in Azure/AWS/Linode I have no way of proving I own the IP (because I don't).
      - deleted 9y ago
        [deleted]
    - tialaramex 9y ago
      If you're concerned about DNS security you can use DNSSEC and Let's Encrypt will cheerfully require DNSSEC signed answers. If your situation really is that you have unsecured DNS that routinely gets hacked and you just sort of muddle among somehow with users frequently getting phished, malware downloaders, and so on, well, I guess Let's Encrypt doesn't magically solve the trouble you've stepped in.
    - schoen 9y ago
      I'm not quite sure how to answer this. DNS is used as ground truth for an enormous amount of certificate issuance by a broad range of CAs. This has been true for many years. Let's Encrypt didn't invent domain validation or the notion of relying on DNS as a basis for issuing DV certificates.
      - peterwwillis 9y ago
        Honestly, it just hadn't occurred to me at all that DNS was the only thing stopping a blackhat from generating valid certs and siphoning or modifying traffic without anyone's knowledge. And users literally can't stop this other than to only accept EV certs, breaking most of the web. This is pretty nutty. At the very least, a public key in WHOIS should be required to generate certs. Why in the world isn't this being done? And is there some way Let's Encrypt can start checking for this (to not issue invalid certs for domains that do list a public key), so maybe the above insanity can be stemmed?
        snowwolf 9y ago
        How do you add that public key to the WHOIS register - Via your domain registrar (and it would have to be updateable/changeable outside of renewal cycles). Who is your DNS provider 90% of the time? Your domain registrar...
        schoen 9y ago
        > At the very least, a public key in WHOIS should be required to generate certs. Why in the world isn't this being done? And is there some way Let's Encrypt can start checking for this (to not issue invalid certs for domains that do list a public key), so maybe the above insanity can be stemmed? I would welcome an authenticated channel to domain registrars, and I would welcome making checking it mandatory for CAs. I think the lack of this is an unfortunate gap, although I don't think we've seen the epidemic of misissuance that you've worried about. In order to make this happen, it would probably require some coordination between ICANN and the CA/Browser Forum. You can become an Interested Party at the CA/Browser Forum yourself in order to propose this kind of mechanism, or you can find an existing Member or Interested Party to bring it up. I already participate as an Interested Party and I could bring it up eventually but I'm currently working on certificates for Tor onion services, and I'd rather get that finished before taking on something else. There may have been previous discussions of this idea in some forum, but I don't know for sure where. By the way, DNSSEC plus DNS CAA can already allow a domain registrant to use cryptographic means to forbid issuance by unauthorized CAs, and checking this is already mandatory for CAs. https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au... This can achieve some of what you want on the negative side, but it's presumably not all the way there.
    - pfg 9y ago
      By "verifying who controls the IP space", do you mean verifying control over the IP a domain resolves to? In that case, what you're missing here is that control over DNS lets you alter that IP address to whatever you'd like. The attacker will have no difficulty demonstrating control over an IP address they own.
    - alwillis 9y ago
      https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#dns-security https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-... DNS security As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates. Servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP. An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names. Because the security of such validations ultimately depends on the authenticity of DNS data, every possible precaution should be taken to secure DNS queries done by the CA. It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains which choose to make use of DNSSEC. An ACME-based CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed. It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.).
    - snowwolf 9y ago
      How would you go about verifying the domain from who controls the "IP space"? A cloud provider/datacenter controls the IP space in the majority of cases. If someone owns your DNS, they can use almost any CA to get valid certs for your domain (apart from EV only ones). That's kind of how Domain Certs work. "A domain-validated certificate (DV) is an X.509 digital certificate typically used for Transport Layer Security (TLS) where the identity of the applicant has been validated by proving some control over a DNS domain" If this is something that worries you, then you should only trust sites that have Extended Validation certificates.
      - peterwwillis 9y ago
        > If this is something that worries you, then you should only trust sites that have Extended Validation certificates. Every user of the web in the world would have to do this in order to avoid this vulnerability.
        snowwolf 9y ago
        Exactly. Domain verified certificates guarantee one thing and one thing only. The data transmitted is encrypted and cannot be tampered with. That's it. They do not guarantee you are communicating with who you think you are. But to be honest if your DNS service is compromised, you have bigger problems.
        peterwwillis 9y ago
        The thing is... it shouldn't be this way. The whole point of TLS is to provide privacy, integrity, and authority. Having a secured connection is pointless if it's a connection to an attacker. Oh, great, nobody can spy on my connection to the NSA. All DNS is supposed to do is to point you at the server to get your connection from. It isn't supposed to mediate the security of the connection. This is back to the old chicken-and-egg of public key crypto: public key connections are secure, as long as you provide the initial host key in a secure, out-of-bound method. If an attacker can circumvent this and inject their own initial host key, they can MITM. Hence why PKI exists: to prevent an outside service from defeating the security of the connection. But apparently, DNS can compromise the connection, by allowing attackers to just generate certs willy-nilly if they can guess your GoDaddy account password.
- alwillis 9y ago
  >Wow. A lot of sites are going to get owned. Why would you say such a thing? Tens of millions of certificates have been provisioned using the ACME protocol without issue. There’s a lot of cryptography behind the scenes that leads up to the TXT record being generated. You can read all about it at https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#dns-challenge https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-...