5 ms·

Still doesn't solve the first-request problem. When can we start using DNSSEC to help prevent DNS hijacking in the first place?

by byuu 7y ago

shawnz 7y ago
The preload option is supposed to solve the first-request problem
- SahAssar 7y ago
  It's not feasible to use preload on a wide scale. Do you think that every secure site should have to be included in the source of your browser to have security?
Thorrez 7y ago
Even without DNS hijacking, a MITM (such as a router) could still intercept your password.
- artursapek 7y ago
  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.
tptacek 7y ago
Probably never. DNSSEC has been in the works for over 20 years, and has practically no real-world deployment.
teddyh 7y ago
Technically DANE could be used for this today, but you’d have to get the web browser vendors aboard in order to implement it, and I’m afraid that it might go over about as well as support for SRV records.
vbezhenar 7y ago
For me deploying DNSSEC was as easy as clicking a button in Cloudflare DNS panel. Though I don't understand how DNSSEC is helping with HSTS? Is there some DNS record which is supposed to force browser to use HTTPS?

Still doesn't solve the first-request problem. When can we start using DNSSEC to help prevent DNS hijacking in the first place?

by byuu 7y ago

Still doesn't solve the first-request problem. When can we start using DNSSEC to help prevent DNS hijacking in the first place?

shawnz 7y ago

The preload option is supposed to solve the first-request problem

SahAssar 7y ago
It's not feasible to use preload on a wide scale. Do you think that every secure site should have to be included in the source of your browser to have security?

Thorrez 7y ago

Even without DNS hijacking, a MITM (such as a router) could still intercept your password.

artursapek 7y ago
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.

tptacek 7y ago

Probably never. DNSSEC has been in the works for over 20 years, and has practically no real-world deployment.

teddyh 7y ago

Technically DANE could be used for this today, but you’d have to get the web browser vendors aboard in order to implement it, and I’m afraid that it might go over about as well as support for SRV records.

vbezhenar 7y ago

For me deploying DNSSEC was as easy as clicking a button in Cloudflare DNS panel. Though I don't understand how DNSSEC is helping with HSTS? Is there some DNS record which is supposed to force browser to use HTTPS?