5 ms·

Not without the ability to add a TXT record to the root domain.

by milankragujevic 7y ago

joosters 7y ago
Which root domain? If they own has-a.name then that is good enough, right?
- LeonM 7y ago
  No, they'd have to get a cert for your domain name. Which they can't, because they cannot prove they own your domain name. All they are doing if pointing to your IPv6 address, anyone can do that, that is why DNS TXT validation if needed in the first place.
  - MrOxiMoron 7y ago
    whatever.has-a.name is the domain name they are suggesting you use, if you had your own you wouldn't need their service. So yes, you are basically giving them control that way. But for simple solution to temporarily get SSL to work on your container during development it's fine. But in that case a self signed certificate works too.
    - LeonM 7y ago
      I haven't looked at it from that angle yet, but you are right: If you share the whatever.has-a.name address with other people and tell them to trust it, then this is very dangerous. However, the OP wrote this: > but keep in mind that the operator can also get SSL certs for your site Which made it sound as if they can get a cert for your domain, which they cannot.
      - yzmtf2008 7y ago
        > Which made it sound as if they can get a cert for your domain, which they cannot. Why? They own and operate the DNS server for has-a.name, so (if they wish to) they can just add any record that they wish, to any domain, right? Of course this is true for any registrar, but that's also why not anyone can just become a registrar.
        ownagefool 7y ago
        Obviously if you can sign a cert which is trusted by browsers, then you technically have the ability to impersonate anyone, but processes are used to fight against this. PSL (https://publicsuffix.org/ https://publicsuffix.org/), DNS Certification Authority Authorization , and Certificate Transparency could be combined so browsers are allowed to know who can sign what, who's a registrar, and who's doing what.
        yzmtf2008 7y ago
        PSL protects the other way around: it can only prevent whatever.has-a.name to compromise has-a.name or another.has-a.name DNS Certification Authority Authorization assumes trust of the DNS server. Doesn't work if the DNS server itself is compromised / malicious. (Maybe with DNSSEC, but DNSSEC has its own problems and definitely doesn't work when your TLD itself is compromised.) CT is really the only thing that works in this scenario (attackers/third party gaining write access to DNS records), but not every CA has CT and not everyone has the means to monitor CT logs. CT isn't even required for every browser/certificate (only EV certs (dead) for Chrome, and you need HPKP (dead) or Expect-CT (no browser support) for this to work reliably). Plus, what are you supposed to do when you find out there's a bad cert for your domain out there? Yell at someone on Twitter? It's going to be hard to convince a CA that you're not doing business with that someone with write access to DNS does not own the domain. Attackers are already impersonating you while it takes hours to sort things out. ... all of this is not to say that these security measures are bad, just not enough. We really put more trust on DNS servers than we ought to.
        ownagefool 7y ago
        PSL could/should also stop sub.has-a.name trusting signed certs such as wildcard.has-a.name, depending on the configuration of the PSL. I'm just not really sure any actual browsers implement it like this though, as reading the PSL "how this is used page" doesn't turn up any such thing. CAA does rely on DNS working, which your registrar can probably hijack. Fair point. CT would help protect against the registrar but not against a malicious CA who simply wouldn't log if they were going to sign a cert maliciously. You're generally right though.
      - stevekemp 7y ago
        They can get an SSL certificate for "example.has-a.name", i.e. your subdomain, in one of two ways: 1. They complete a DNS challenge and get a certificate for "\\*.has-a.name" - which obviously includes your subdomain. 2. They sneakily point "your-address-here.has-a.name" to an IP they control, get a certificate issued, then point it back to where it should go. The second option is more hassle, and easier to notice, but the first makes it needlessly complex. Of course if your actual domain is "bob.com" then this is just a distraction. We're using "your domain" in this case to refer to the subdomain that points to your IPv6 address.
        treysis 7y ago
        And then they have a certificate. What are they going to do with it? It's still not installed on your server.
        yzmtf2008 7y ago
        Suddenly whatever.has-a.name is pointing to a different IP address and that server has the cert installed. Oops.
        treysis 7y ago
        So same trust you put in any 3rd party DNS service. But I agree there's less contractual bindings to this service than an account somewhere that you even might pay some money for it.
        yzmtf2008 7y ago
        I guess the point of all this discussion is "don't trust a random guy on the Internet that offers to host DNS for you", but also we place way too much trust on DNS.
  - jrockway 7y ago
    ACME is entirely based on DNS. The HTTP and ALPN challenges look up which IP address to speak to via DNS. The DNS challenges look for a TXT record in DNS. (Letsencrypt tries pretty hard to ensure that the DNS is legitimately being served by looking up the IP address from multiple networks, so you can't disrupt one of their networks to issue fake certs. But it has no idea who really controls your DNS server or glue records.) If you host your site at foo.example.com, then example.com can get a wildcard certificate for *.example.com that will be valid even if you have your own foo.example.com certificate and they can also change the A or AAAA record for foo.example.com to get a certificate with an HTTP challenge. You could always petition browser vendors to pin your foo.example.com certificate, and thus override any tampering by the example.com DNS server. It is exceedingly unlikely they would do this for you. TLS certificates these days only prove one thing: control over the DNS server at the time of provisioning.
milankragujevic 7y ago
Can all the nice people who have downvoted explain what I said wrong?

Not without the ability to add a TXT record to the root domain.

joosters 7y ago

Which root domain? If they own has-a.name then that is good enough, right?

LeonM 7y ago
No, they'd have to get a cert for your domain name. Which they can't, because they cannot prove they own your domain name. All they are doing if pointing to your IPv6 address, anyone can do that, that is why DNS TXT validation if needed in the first place.
- MrOxiMoron 7y ago
  whatever.has-a.name is the domain name they are suggesting you use, if you had your own you wouldn't need their service. So yes, you are basically giving them control that way. But for simple solution to temporarily get SSL to work on your container during development it's fine. But in that case a self signed certificate works too.
  - LeonM 7y ago
    I haven't looked at it from that angle yet, but you are right: If you share the whatever.has-a.name address with other people and tell them to trust it, then this is very dangerous. However, the OP wrote this: > but keep in mind that the operator can also get SSL certs for your site Which made it sound as if they can get a cert for your domain, which they cannot.
    - yzmtf2008 7y ago
      > Which made it sound as if they can get a cert for your domain, which they cannot. Why? They own and operate the DNS server for has-a.name, so (if they wish to) they can just add any record that they wish, to any domain, right? Of course this is true for any registrar, but that's also why not anyone can just become a registrar.
      - ownagefool 7y ago
        Obviously if you can sign a cert which is trusted by browsers, then you technically have the ability to impersonate anyone, but processes are used to fight against this. PSL (https://publicsuffix.org/ https://publicsuffix.org/), DNS Certification Authority Authorization , and Certificate Transparency could be combined so browsers are allowed to know who can sign what, who's a registrar, and who's doing what.
        yzmtf2008 7y ago
        PSL protects the other way around: it can only prevent whatever.has-a.name to compromise has-a.name or another.has-a.name DNS Certification Authority Authorization assumes trust of the DNS server. Doesn't work if the DNS server itself is compromised / malicious. (Maybe with DNSSEC, but DNSSEC has its own problems and definitely doesn't work when your TLD itself is compromised.) CT is really the only thing that works in this scenario (attackers/third party gaining write access to DNS records), but not every CA has CT and not everyone has the means to monitor CT logs. CT isn't even required for every browser/certificate (only EV certs (dead) for Chrome, and you need HPKP (dead) or Expect-CT (no browser support) for this to work reliably). Plus, what are you supposed to do when you find out there's a bad cert for your domain out there? Yell at someone on Twitter? It's going to be hard to convince a CA that you're not doing business with that someone with write access to DNS does not own the domain. Attackers are already impersonating you while it takes hours to sort things out. ... all of this is not to say that these security measures are bad, just not enough. We really put more trust on DNS servers than we ought to.
        ownagefool 7y ago
        PSL could/should also stop sub.has-a.name trusting signed certs such as wildcard.has-a.name, depending on the configuration of the PSL. I'm just not really sure any actual browsers implement it like this though, as reading the PSL "how this is used page" doesn't turn up any such thing. CAA does rely on DNS working, which your registrar can probably hijack. Fair point. CT would help protect against the registrar but not against a malicious CA who simply wouldn't log if they were going to sign a cert maliciously. You're generally right though.
    - stevekemp 7y ago
      They can get an SSL certificate for "example.has-a.name", i.e. your subdomain, in one of two ways: 1. They complete a DNS challenge and get a certificate for "\\*.has-a.name" - which obviously includes your subdomain. 2. They sneakily point "your-address-here.has-a.name" to an IP they control, get a certificate issued, then point it back to where it should go. The second option is more hassle, and easier to notice, but the first makes it needlessly complex. Of course if your actual domain is "bob.com" then this is just a distraction. We're using "your domain" in this case to refer to the subdomain that points to your IPv6 address.
      - treysis 7y ago
        And then they have a certificate. What are they going to do with it? It's still not installed on your server.
        yzmtf2008 7y ago
        Suddenly whatever.has-a.name is pointing to a different IP address and that server has the cert installed. Oops.
        treysis 7y ago
        So same trust you put in any 3rd party DNS service. But I agree there's less contractual bindings to this service than an account somewhere that you even might pay some money for it.
        yzmtf2008 7y ago
        I guess the point of all this discussion is "don't trust a random guy on the Internet that offers to host DNS for you", but also we place way too much trust on DNS.
- jrockway 7y ago
  ACME is entirely based on DNS. The HTTP and ALPN challenges look up which IP address to speak to via DNS. The DNS challenges look for a TXT record in DNS. (Letsencrypt tries pretty hard to ensure that the DNS is legitimately being served by looking up the IP address from multiple networks, so you can't disrupt one of their networks to issue fake certs. But it has no idea who really controls your DNS server or glue records.) If you host your site at foo.example.com, then example.com can get a wildcard certificate for *.example.com that will be valid even if you have your own foo.example.com certificate and they can also change the A or AAAA record for foo.example.com to get a certificate with an HTTP challenge. You could always petition browser vendors to pin your foo.example.com certificate, and thus override any tampering by the example.com DNS server. It is exceedingly unlikely they would do this for you. TLS certificates these days only prove one thing: control over the DNS server at the time of provisioning.

milankragujevic 7y ago

Can all the nice people who have downvoted explain what I said wrong?