4 ms·

Isn't DNSSEC supposed to prevent you from connecting to the wrong origin, presumably avoiding an unencrypted connection? A router can't intercept anything on an

Isn't DNSSEC supposed to prevent you from connecting to the wrong origin, presumably avoiding an unencrypted connection? A router can't intercept anything on an encrypted connection.

Thorrez 7y ago
DNSSEC ensures a hostname resolves to the right IP address. But when you make a TCP connection to that IP address, a MITM can listen in on (and modify) that TCP connection. Another problem is I believe DNSSEC is only validated by the recursive resolver. So if the end user is using an external recursive resolver (e.g. 8.8.8.8) then the data between the user and the recursive resolver can still be spoofed by a MITM, and also the recursive resolver itself could behave maliciously.
- teddyh 7y ago
  > > A router can't intercept anything on an encrypted connection. > MITM can listen in on (and modify) that TCP connection. Not if the connection is encrypted, as was stipulated. > Another problem is I believe DNSSEC is only validated by the recursive resolver. True, you need a trusted connection to the resolver you use (which you also have to trust). Therefore, you can either use DoT or DoH to some resolver which you have to trust, or run your own local resolver on the local machine.
  - deleted 7y ago
    [deleted]
  - Thorrez 7y ago
    >Not if the connection is encrypted, as was stipulated. Hmm, yes, there does appear to be some confusion. I misread artursapek and missed the "encrypted connection" part. Assuming "encrypted connection" refers to the connection to the website, then my question is what is telling the connection to be encrypted? The article is about current non-encrypted connections. So something needs to be done to convert those http:// http:// connections into https:// https:// connections, and I don't think DNSSEC does that.
    - teddyh 7y ago
      > So something needs to be done to convert those http:// http:// connections into https:// https:// connections, and I don't think DNSSEC does that. HSTS is already being used for this, although it uses a TOFU-like model where the very first connection is vulnerable to MITM downgrade. DANE (which uses DNSSEC) does not have this problem, and could be used for this, but it’s the browser vendors who would have to be convinced to implement it, and I don’t have high hopes.
      - tptacek 7y ago
        DANE does in practice have this problem; see the chain-extension fiasco. A lot of these things look like they work until you actually try to get a browser to do them.
        teddyh 7y ago
        I can’t seem to find what you are referring to. Could you specify what the problem is?
        tptacek 7y ago
        From memory, but you can just look it up: DANE is untenable in browsers because (1) it's much too slow and (2) a lot of networks won't pass DANE lookups; if your HTTPS connection relies on DNSSEC/DANE "just working", the web breaks for those people. So instead, you staple DANE records to the TLS handshake with an extension. But that's incoherent: the purpose of DANE is to establish a root of trust for TLS connections, but the extensions carried in a TLS handshake depend on a root of trust. In practice, if you can get an X.509 certificate issued, you can strip stapled DANE records. So there's no point to stapling DANE records. Solution: dynamic pinning and continuity over multiple connections.
        teddyh 7y ago
        > DANE is untenable in browsers because Neither of those things make sense to me: > (1) it's much too slow Browsers already do A/AAAA DNS lookups, which presumably does not present any huge latency issue. If latency would be a problem, DNS servers could send the additional DANE records in the “additional” section, just like they do now with an A or AAAA query leading to a CNAME record; this would completely eliminate any additional latency with DANE. > and (2) a lot of networks won't pass DANE lookups I don’t think so; if that were the case, DANE would not be rolled out as widely as it is for SMTP.
- xorcist 7y ago
  DNSSSEC can distribute an actual certificate pin (DANE), making the web PKI semi-obsolete, distribute a CA pin (CAA), or any other PKI data should the clients support it. I think most people agree that the domain is the trust point nowadays (as most certificates are domain validated; there is a whole industry pushing organization name validation with EV, but it has never worked well in the real world), so it makes sense to anchor the http certificate to the domain one. DANE hasn't really taken off much outside mail traffic (where it is optional but to some extent forced when present). The jury is still out on CAA. As for the rest, one can only hope for new initiatives. The open web PKI only works for the big actors.
  - Thorrez 7y ago
    Does DNSSEC upgrade http:// http:// to https:// https:// ? If not, then it doesn't solve the specific problem Troy and I were talking about (namely MITMs snooping on http:// http:// traffic). What's the primary attack that DANE attempts to protect against? CAs issuing certs to entities they shouldn't? Troy doesn't seem to be worried about those attacks.
    - xorcist 7y ago
      There are several kinds of MITM. DNSSEC makes rebinding, poisoning and DNS interception for capturing and modifying traffic neutered. Being a protocol it is however ineffective against other attacks such as unauthorized domain transfers. What artursapek describes is probably that, while you are of course correct that no improved encryption could possibly improve on the fact that web browsers still default to unencrypted communications. So the problems are mostly complementary, but rebinding and poisoning offers an attacker more ways of intercepting cleartext traffic unless mitigated.
  - tptacek 7y ago
    The major mail providers are busy killing off DNSSEC for SMTP as well; see SMTP-STS, which has as an explicit goal defeating downgrade attacks without resorting to DNSSEC.

Isn't DNSSEC supposed to prevent you from connecting to the wrong origin, presumably avoiding an unencrypted connection? A router can't intercept anything on an encrypted connection.

Thorrez 7y ago

DNSSEC ensures a hostname resolves to the right IP address. But when you make a TCP connection to that IP address, a MITM can listen in on (and modify) that TCP connection. Another problem is I believe DNSSEC is only validated by the recursive resolver. So if the end user is using an external recursive resolver (e.g. 8.8.8.8) then the data between the user and the recursive resolver can still be spoofed by a MITM, and also the recursive resolver itself could behave maliciously.

teddyh 7y ago
> > A router can't intercept anything on an encrypted connection. > MITM can listen in on (and modify) that TCP connection. Not if the connection is encrypted, as was stipulated. > Another problem is I believe DNSSEC is only validated by the recursive resolver. True, you need a trusted connection to the resolver you use (which you also have to trust). Therefore, you can either use DoT or DoH to some resolver which you have to trust, or run your own local resolver on the local machine.
- deleted 7y ago
  [deleted]
- Thorrez 7y ago
  >Not if the connection is encrypted, as was stipulated. Hmm, yes, there does appear to be some confusion. I misread artursapek and missed the "encrypted connection" part. Assuming "encrypted connection" refers to the connection to the website, then my question is what is telling the connection to be encrypted? The article is about current non-encrypted connections. So something needs to be done to convert those http:// http:// connections into https:// https:// connections, and I don't think DNSSEC does that.
  - teddyh 7y ago
    > So something needs to be done to convert those http:// http:// connections into https:// https:// connections, and I don't think DNSSEC does that. HSTS is already being used for this, although it uses a TOFU-like model where the very first connection is vulnerable to MITM downgrade. DANE (which uses DNSSEC) does not have this problem, and could be used for this, but it’s the browser vendors who would have to be convinced to implement it, and I don’t have high hopes.
    - tptacek 7y ago
      DANE does in practice have this problem; see the chain-extension fiasco. A lot of these things look like they work until you actually try to get a browser to do them.
      - teddyh 7y ago
        I can’t seem to find what you are referring to. Could you specify what the problem is?
        tptacek 7y ago
        From memory, but you can just look it up: DANE is untenable in browsers because (1) it's much too slow and (2) a lot of networks won't pass DANE lookups; if your HTTPS connection relies on DNSSEC/DANE "just working", the web breaks for those people. So instead, you staple DANE records to the TLS handshake with an extension. But that's incoherent: the purpose of DANE is to establish a root of trust for TLS connections, but the extensions carried in a TLS handshake depend on a root of trust. In practice, if you can get an X.509 certificate issued, you can strip stapled DANE records. So there's no point to stapling DANE records. Solution: dynamic pinning and continuity over multiple connections.
        teddyh 7y ago
        > DANE is untenable in browsers because Neither of those things make sense to me: > (1) it's much too slow Browsers already do A/AAAA DNS lookups, which presumably does not present any huge latency issue. If latency would be a problem, DNS servers could send the additional DANE records in the “additional” section, just like they do now with an A or AAAA query leading to a CNAME record; this would completely eliminate any additional latency with DANE. > and (2) a lot of networks won't pass DANE lookups I don’t think so; if that were the case, DANE would not be rolled out as widely as it is for SMTP.
xorcist 7y ago
DNSSSEC can distribute an actual certificate pin (DANE), making the web PKI semi-obsolete, distribute a CA pin (CAA), or any other PKI data should the clients support it. I think most people agree that the domain is the trust point nowadays (as most certificates are domain validated; there is a whole industry pushing organization name validation with EV, but it has never worked well in the real world), so it makes sense to anchor the http certificate to the domain one. DANE hasn't really taken off much outside mail traffic (where it is optional but to some extent forced when present). The jury is still out on CAA. As for the rest, one can only hope for new initiatives. The open web PKI only works for the big actors.
- Thorrez 7y ago
  Does DNSSEC upgrade http:// http:// to https:// https:// ? If not, then it doesn't solve the specific problem Troy and I were talking about (namely MITMs snooping on http:// http:// traffic). What's the primary attack that DANE attempts to protect against? CAs issuing certs to entities they shouldn't? Troy doesn't seem to be worried about those attacks.
  - xorcist 7y ago
    There are several kinds of MITM. DNSSEC makes rebinding, poisoning and DNS interception for capturing and modifying traffic neutered. Being a protocol it is however ineffective against other attacks such as unauthorized domain transfers. What artursapek describes is probably that, while you are of course correct that no improved encryption could possibly improve on the fact that web browsers still default to unencrypted communications. So the problems are mostly complementary, but rebinding and poisoning offers an attacker more ways of intercepting cleartext traffic unless mitigated.
- tptacek 7y ago
  The major mail providers are busy killing off DNSSEC for SMTP as well; see SMTP-STS, which has as an explicit goal defeating downgrade attacks without resorting to DNSSEC.