8 ms·

There's a couple things about modern DNS that just doesn't make sense. There's probably a good explanation buried somewhere in a mailing list or three. The oth

There's a couple things about modern DNS that just doesn't make sense. There's probably a good explanation buried somewhere in a mailing list or three. The other one that still astounds me is that DV certificates rely entirely on DNS control for validation prior to issuance, and browsers trust that system, but there still exists no way for me to cut out the middle man and put my own domain-specific CA Cert in DNS directly.

vbezhenar 8y ago
CA can expect that its connection to your DNS server is reliable and not tampered. So their check is reliable. User can't expect that his DNS is reliable. So HTTPS must work with those conditions: when user's DNS server might be controlled by bad actor. DNS security is supposed to solve that, but it's not widely used AFAIK.
- deleted 8y ago
  [deleted]
- CKN23-ARIN 8y ago
  Why is it that the CA can expect no tampering? It seems to me that it would not be hard for certain classes of attackers to MitM a CA.
  - miniflux 8y ago
    Can you elaborate this MITM attack? How would it work?
    - fulafel 8y ago
      Local network tampering (ARP etc) at registrar end, routing attacks such as BGP hijack, below-IP attacks in transit (eg MPLS hijack, malicious transit router, QUANTUM INSERT, other fiber tap approaches, ...) DNS implementation bugs in UDP spoofing countermeasures, local network tampering at domain holder end, social engineering or extortion against transit or stakeholder sysadmins, etc. It's a long list of possibilities.
      - Arnt 8y ago
        Right. Which ones of those leave the signatures on root zone, the .com zone and the cert unaffected and are transparent in any real sense of the word?
  - viraptor 8y ago
    CAs should be able to afford to make the requests from multiple sources and compare the results. Alternatively they can use secondary challenge-response auth which depends on some credentials being deployed to your server. Mitm-ing it wouldn't give the attacker anything interesting in that case.
    - skissane 8y ago
      > CAs should be able to afford to make the requests from multiple sources and compare the results. Do they actually do that in practice? Are they required to do so? (How many sources and how far distinct?)
      - CKN23-ARIN 8y ago
        To test this, I just now acquired a Let's Encrypt cert using `certbot certonly` while tailing the logs. I received only a single request, from 64.78.149.164. The cert was issued. They did not appear to take a second measurement.
        zaarn 8y ago
        On your DNS or on your webserver? Did you use a fresh domain or a domain that has been previously seen in DNS?
        CKN23-ARIN 8y ago
        On my webserver (http-01 challenge type). Fresh hostname. Fresh VM. Fresh certbot install.
        shawnz 8y ago
        That's not a DNS challenge.
        peterwwillis 8y ago
- miniflux 8y ago
  > User can't expect that his DNS is reliable. Yet both the user and DV certificate issuers rely on the same DNS that you consider unreliable. So you seem to dismiss DV certificates altogether but your comment seems to imply that you only want to dismiss certificates as DNS records. There's something very inconsistent about your comment.
  - lathiat 8y ago
    That inconsistency is that users are generally on much less trustworthy networks and DNS right now is rarely authenticated (DNSSEC is not wide spread and even then most clients don’t authenticate it) While not perfect it’s generally quite true for the majority case.
    - phicoh 8y ago
      Actually, a large number of hosts are behind a DNSSEC validating resolver. And that's because the use of Google's public resolvers is extremely wide spread. I don't know if they document it somewhere, but it is essentially trivial for letsencrypt to use a DNSSEC validating resolver. So that means that if you care about DV security, you enable DNSSEC.
      - tptacek 8y ago
        DNSSEC doesn't protect the connection between a browser and Google's DNS server. Attackers can simply edit the responses generated by Google's DNS. Moreover, virtually nobody signs their domains with DNSSEC (why would they? It's all downside.) So CA's can't require DNSSEC, or depend on it being there. You can enable it, but it's pointless, because the attack against DV that DNSSEC is meant to prevent can be launched whether or not you enable it. DNSSEC has essentially no practical impact on DV.
        phicoh 8y ago
        If we are talking about obtaining DV certificates, then why do you bring up the connection between a browser and Google DNS? The good thing about Google doing DNSSEC validation that on average zones can either be unsigned or need to have valid signatures. By signing your own domains with DNSSEC and assuming CAs do DNSSEC validation you can protect your own domains from malicious DV certificates. That's a nice feature. If you don't like DNSSEC, nobody is forcing you to sign your zones. I can still sign my zones even if you don't sign yours. The next step would be for CAs to honour DANE records.
- lucb1e 8y ago
  > CA can expect that its connection to your DNS server is reliable and not tampered Why? It goes over infrastructure that you nor they control. It might be worth illustrating what happens here, as it's not immediately clear from common DNS settings or common commands. First, the client asks their local DNS server, the one you get via DHCP or configure (for example 8.8.8.8 which is by definition already outside your network, but for argument's sake let's assume that they're smarter than that and they pick one inside their own network). Let's say this one doesn't have it in cache, so then it has to go out and ask the TLD (let's assume it has the TLD cached). The TLD, for example `.com`, will say "the name servers for your.example.com can be found at ns.your.example.com" and it gives the IP addresses for those. Now the local resolver at the CA has to go and ask there for your domain. In this final step, if nowhere else, it will have to leave any sort of trusted network and venture into whatever place the user's servers are at. This could be anywhere in the world, with all sorts of intermediate networks.
  - geocar 8y ago
    > Why? It goes over infrastructure that you nor they control. They're able to use many secret locations to perform the query. There is a theory that it is very unlikely an attacker can detect and get leverage over every network between every one of those secret locations for an indeterminate amount of time, without being discovered.
    - jessaustin 8y ago
      What you describe is a possible technique that CAs could use, so let's stipulate that some CA does this. We certainly can't conclude that all or even many CAs do this.
      - cormacrelf 8y ago
        I’m pretty sure AWS Certificate Manager does this.
  - vbezhenar 8y ago
    Attacking server infrastructure is order of magnitude harder than attacking user. Those who can do this attack, can just ask their CEO to issue them a certificate via subpoena.
deleted 8y ago
[deleted]
peterwwillis 8y ago
Most of the things that are "curious" about DNS I think comes from its lack of a version. DNS has no version, so it has no obvious way to extend itself by allowing for graceful upgrades. So you can't just change behavior and have clients support a particular version. Everything has to be backwards compatible with something written in 1984. The only serious attempt at extending DNS died because the specs and DNS admins allowed the extension mechanism to be optional. Now, most networks break the extension, and the DNS just limps along because nobody is willing to implement a sane upgrade path.
- tonyg 8y ago
  Query opcodes 3 and 6 through 15 are unassigned [1]. Middlebox brokenness aside [2], a completely new payload could be placed behind a header 0000 7800 0000 0000 0000 0000 Public DNS installations already have to deal with getting unsolicited random crap, so the risk of fatal confusion is low. [1] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-5 https://www.iana.org/assignments/dns-parameters/dns-paramete... [2] Middlebox brokenness is probably the biggest issue with extending or upgrading DNS, though, I suppose
  - peterwwillis 8y ago
    And the middlebox brokenness is due to a lack of versioning. Virtually all middlebox brokenness is a result of a lack of versioning and poor upgrade paths - usually from people demanding backwards compatibility above all else.
    - tonyg 8y ago
      I view it as more of a consequence of "fail closed" thinking than a lack of versioning. As we've seen recently with TLS [1], even protocols with explicit versioning suffer from middlebox brittleness. [1] https://news.ycombinator.com/item?id=17298747 https://news.ycombinator.com/item?id=17298747
throwaway201862 8y ago
There is, it's called a TLSA record: https://tools.ietf.org/html/rfc6698 https://tools.ietf.org/html/rfc6698
Promarged 8y ago
> put my own domain-specific CA Cert in DNS directly. Remember that this allows any of your government or people controlling the zone to transparently put the cert there too. (For potential problems see [0]). With the CA system (that I personally also don't like) at least the certs are logged in Certificate Transparency logs so you see any potential attacks. [0]: https://www.theguardian.com/technology/2010/oct/08/bitly-libya https://www.theguardian.com/technology/2010/oct/08/bitly-lib...
- Arnt 8y ago
  Can you elaborate? AFAICT, anyone who controls .com can add or replace a cert for ycombinator.com, but only visibly. If they do it, they show the change to the entire world at once, because .com is signed with dnssec. Right?
  - tialaramex 8y ago
    Your parent mentioned Certificate Transparency. Under CT all the public CAs log certificates they issue, and everybody can see the logs, programmatically (with cryptographic security) or via a log monitor like crt.sh So yes, bad guys operating a TLD can trick a CA into issuing for a domain under theirs, but the CT logs would preserve evidence of this cert existing, and the CA is required to keep records of why it was confident to issue. Monitors would know about the cert in 24 hours (usually much less)
  - tptacek 8y ago
    The idea behind the attack they're talking about is that the USG has de jure control over .COM's DNSSEC keys, and so they can in fact edit .COM transparently.
tialaramex 8y ago
DNS is actually the least sketchy component in the DV story. Until about a year ago the situation was that each CA could do anything they (without even peer review) thought seemed good. Then we got the Ten Blessed Methods, a specific list of ways to verify that your subscriber really controls the names they want a cert for. Most of the Blessed Methods involve DNS, but not all of them, some are relying on paper documents, some use WHOIS and out of band communications (e.g. Fax!). And of those which use DNS, many involve even less secure elements, email, plaintext HTTP, that sort of thing. So there's still work to do, but we're headed in the right direction.

vbezhenar 8y ago

CA can expect that its connection to your DNS server is reliable and not tampered. So their check is reliable. User can't expect that his DNS is reliable. So HTTPS must work with those conditions: when user's DNS server might be controlled by bad actor. DNS security is supposed to solve that, but it's not widely used AFAIK.

deleted 8y ago
[deleted]
CKN23-ARIN 8y ago
Why is it that the CA can expect no tampering? It seems to me that it would not be hard for certain classes of attackers to MitM a CA.
- miniflux 8y ago
  Can you elaborate this MITM attack? How would it work?
  - fulafel 8y ago
    Local network tampering (ARP etc) at registrar end, routing attacks such as BGP hijack, below-IP attacks in transit (eg MPLS hijack, malicious transit router, QUANTUM INSERT, other fiber tap approaches, ...) DNS implementation bugs in UDP spoofing countermeasures, local network tampering at domain holder end, social engineering or extortion against transit or stakeholder sysadmins, etc. It's a long list of possibilities.
    - Arnt 8y ago
      Right. Which ones of those leave the signatures on root zone, the .com zone and the cert unaffected and are transparent in any real sense of the word?
- viraptor 8y ago
  CAs should be able to afford to make the requests from multiple sources and compare the results. Alternatively they can use secondary challenge-response auth which depends on some credentials being deployed to your server. Mitm-ing it wouldn't give the attacker anything interesting in that case.
  - skissane 8y ago
    > CAs should be able to afford to make the requests from multiple sources and compare the results. Do they actually do that in practice? Are they required to do so? (How many sources and how far distinct?)
    - CKN23-ARIN 8y ago
      To test this, I just now acquired a Let's Encrypt cert using `certbot certonly` while tailing the logs. I received only a single request, from 64.78.149.164. The cert was issued. They did not appear to take a second measurement.
      - zaarn 8y ago
        On your DNS or on your webserver? Did you use a fresh domain or a domain that has been previously seen in DNS?
        CKN23-ARIN 8y ago
        On my webserver (http-01 challenge type). Fresh hostname. Fresh VM. Fresh certbot install.
        shawnz 8y ago
        That's not a DNS challenge.
        peterwwillis 8y ago
miniflux 8y ago
> User can't expect that his DNS is reliable. Yet both the user and DV certificate issuers rely on the same DNS that you consider unreliable. So you seem to dismiss DV certificates altogether but your comment seems to imply that you only want to dismiss certificates as DNS records. There's something very inconsistent about your comment.
- lathiat 8y ago
  That inconsistency is that users are generally on much less trustworthy networks and DNS right now is rarely authenticated (DNSSEC is not wide spread and even then most clients don’t authenticate it) While not perfect it’s generally quite true for the majority case.
  - phicoh 8y ago
    Actually, a large number of hosts are behind a DNSSEC validating resolver. And that's because the use of Google's public resolvers is extremely wide spread. I don't know if they document it somewhere, but it is essentially trivial for letsencrypt to use a DNSSEC validating resolver. So that means that if you care about DV security, you enable DNSSEC.
    - tptacek 8y ago
      DNSSEC doesn't protect the connection between a browser and Google's DNS server. Attackers can simply edit the responses generated by Google's DNS. Moreover, virtually nobody signs their domains with DNSSEC (why would they? It's all downside.) So CA's can't require DNSSEC, or depend on it being there. You can enable it, but it's pointless, because the attack against DV that DNSSEC is meant to prevent can be launched whether or not you enable it. DNSSEC has essentially no practical impact on DV.
      - phicoh 8y ago
        If we are talking about obtaining DV certificates, then why do you bring up the connection between a browser and Google DNS? The good thing about Google doing DNSSEC validation that on average zones can either be unsigned or need to have valid signatures. By signing your own domains with DNSSEC and assuming CAs do DNSSEC validation you can protect your own domains from malicious DV certificates. That's a nice feature. If you don't like DNSSEC, nobody is forcing you to sign your zones. I can still sign my zones even if you don't sign yours. The next step would be for CAs to honour DANE records.
lucb1e 8y ago
> CA can expect that its connection to your DNS server is reliable and not tampered Why? It goes over infrastructure that you nor they control. It might be worth illustrating what happens here, as it's not immediately clear from common DNS settings or common commands. First, the client asks their local DNS server, the one you get via DHCP or configure (for example 8.8.8.8 which is by definition already outside your network, but for argument's sake let's assume that they're smarter than that and they pick one inside their own network). Let's say this one doesn't have it in cache, so then it has to go out and ask the TLD (let's assume it has the TLD cached). The TLD, for example `.com`, will say "the name servers for your.example.com can be found at ns.your.example.com" and it gives the IP addresses for those. Now the local resolver at the CA has to go and ask there for your domain. In this final step, if nowhere else, it will have to leave any sort of trusted network and venture into whatever place the user's servers are at. This could be anywhere in the world, with all sorts of intermediate networks.
- geocar 8y ago
  > Why? It goes over infrastructure that you nor they control. They're able to use many secret locations to perform the query. There is a theory that it is very unlikely an attacker can detect and get leverage over every network between every one of those secret locations for an indeterminate amount of time, without being discovered.
  - jessaustin 8y ago
    What you describe is a possible technique that CAs could use, so let's stipulate that some CA does this. We certainly can't conclude that all or even many CAs do this.
    - cormacrelf 8y ago
      I’m pretty sure AWS Certificate Manager does this.
- vbezhenar 8y ago
  Attacking server infrastructure is order of magnitude harder than attacking user. Those who can do this attack, can just ask their CEO to issue them a certificate via subpoena.

deleted 8y ago

[deleted]

peterwwillis 8y ago

Most of the things that are "curious" about DNS I think comes from its lack of a version. DNS has no version, so it has no obvious way to extend itself by allowing for graceful upgrades. So you can't just change behavior and have clients support a particular version. Everything has to be backwards compatible with something written in 1984. The only serious attempt at extending DNS died because the specs and DNS admins allowed the extension mechanism to be optional. Now, most networks break the extension, and the DNS just limps along because nobody is willing to implement a sane upgrade path.

tonyg 8y ago
Query opcodes 3 and 6 through 15 are unassigned [1]. Middlebox brokenness aside [2], a completely new payload could be placed behind a header 0000 7800 0000 0000 0000 0000 Public DNS installations already have to deal with getting unsolicited random crap, so the risk of fatal confusion is low. [1] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-5 https://www.iana.org/assignments/dns-parameters/dns-paramete... [2] Middlebox brokenness is probably the biggest issue with extending or upgrading DNS, though, I suppose
- peterwwillis 8y ago
  And the middlebox brokenness is due to a lack of versioning. Virtually all middlebox brokenness is a result of a lack of versioning and poor upgrade paths - usually from people demanding backwards compatibility above all else.
  - tonyg 8y ago
    I view it as more of a consequence of "fail closed" thinking than a lack of versioning. As we've seen recently with TLS [1], even protocols with explicit versioning suffer from middlebox brittleness. [1] https://news.ycombinator.com/item?id=17298747 https://news.ycombinator.com/item?id=17298747

throwaway201862 8y ago

There is, it's called a TLSA record: https://tools.ietf.org/html/rfc6698 https://tools.ietf.org/html/rfc6698

Promarged 8y ago

> put my own domain-specific CA Cert in DNS directly. Remember that this allows any of your government or people controlling the zone to transparently put the cert there too. (For potential problems see [0]). With the CA system (that I personally also don't like) at least the certs are logged in Certificate Transparency logs so you see any potential attacks. [0]: https://www.theguardian.com/technology/2010/oct/08/bitly-libya https://www.theguardian.com/technology/2010/oct/08/bitly-lib...

Arnt 8y ago
Can you elaborate? AFAICT, anyone who controls .com can add or replace a cert for ycombinator.com, but only visibly. If they do it, they show the change to the entire world at once, because .com is signed with dnssec. Right?
- tialaramex 8y ago
  Your parent mentioned Certificate Transparency. Under CT all the public CAs log certificates they issue, and everybody can see the logs, programmatically (with cryptographic security) or via a log monitor like crt.sh So yes, bad guys operating a TLD can trick a CA into issuing for a domain under theirs, but the CT logs would preserve evidence of this cert existing, and the CA is required to keep records of why it was confident to issue. Monitors would know about the cert in 24 hours (usually much less)
- tptacek 8y ago
  The idea behind the attack they're talking about is that the USG has de jure control over .COM's DNSSEC keys, and so they can in fact edit .COM transparently.

tialaramex 8y ago

DNS is actually the least sketchy component in the DV story. Until about a year ago the situation was that each CA could do anything they (without even peer review) thought seemed good. Then we got the Ten Blessed Methods, a specific list of ways to verify that your subscriber really controls the names they want a cert for. Most of the Blessed Methods involve DNS, but not all of them, some are relying on paper documents, some use WHOIS and out of band communications (e.g. Fax!). And of those which use DNS, many involve even less secure elements, email, plaintext HTTP, that sort of thing. So there's still work to do, but we're headed in the right direction.