13 ms·

Just require HTTPS already.

by adrr 6y ago

godman_8 6y ago
HTTPS doesn’t protect against DNS or SNI interception
- adrr 6y ago
  If there’s no valid cert for the domain, you can’t 301/302 redirect over https connection. SNI just lets the middleman peak at the host name, it doesn’t allow you to redirect. DNS interception allows the attackers to change IP but https still needs a valid cert for the host.
  - kenniskrag 6y ago
    With HSTS and preload it should mitigate the vulnerability.
    - adrr 6y ago
      Issues with HSTS is that it is opt in. It should be an opt out with a list of legacy sites that ships with the browsers similar to how hsts preloading works.
      - Polylactic_acid 6y ago
        The option browser vendors are going with seems to be to make http show a full page warning about being insecure. No need to change HSTS now.
  - stordoff 6y ago
    Incidentally, this affects how my ISP implements its domain blocks. Non-HTTPS sites are 307 redirected to https://assets.virginmedia.com/site-blocked.html https://assets.virginmedia.com/site-blocked.html, whereas connections to HTTPS sites are just halted (IIRC, it sends a TCP reset, but it's a while since I looked into it).
    - amiga-workbench 6y ago
      That reminds me, I turned this off the other day and it still hasn't taken effect yet. https://my.virginmedia.com/advancederrorsearch/ https://my.virginmedia.com/advancederrorsearch/ Its a good thing DoH is now in the stable version of RouterOS, I've just switched it on.
      - JdeBP 6y ago
        You don't need DoH to avoid that. Just set up and use your own resolving proxy DNS servers and don't use the Virgin Media ones at 194.168.4.100 and 194.168.8.100 either directly or indirectly. (This means not forwarding to those servers, and not letting your DHCP client, in any of your machines, configure your system to use them when it gets a lease.) Here is the difference between using Virgin Media's resolving proxy DNS servers and using your own: % # http://jdebp.uk./Softwares/djbwares/guide/commands/dnsqrx.xml % % dnsqrx a z398nvfsd0098u3qwtltnk. 194.168.4.100 1 z398nvfsd0098u3qwtltnk: 56 bytes, 1+1+0+0 records, response, noerror query: 1 z398nvfsd0098u3qwtltnk answer: z398nvfsd0098u3qwtltnk 0 A 92.242.132.24 % % % dnsqr a z398nvfsd0098u3qwtltnk. 1 z398nvfsd0098u3qwtltnk: 40 bytes, 1+0+0+0 records, response, authoritative, nxdomain query: 1 z398nvfsd0098u3qwtltnk % That last query didn't even escape the machine in my case. I run a private root content DNS server on every machine if possible. The query here got answered by a tinydns instance listening on 127.53.0.1: % tail -n 1 /var/log/sv/tinydns/current | tai64nlocal 2020-08-26 09:37:44.305619726 7f000001:cfd9:f163 + 0001 z398nvfsd0098u3qwtltnk % No-one gets to complain about (minuscule) extra load on the root content DNS server except me. It's my server on my machine. (-:
        amiga-workbench 6y ago
        I've just realised my mistake, I needed to turn "use-peer-dns" off. I did have my router setup to cache DNS requests to google and updated the DHCP config so everything would use my router for resolution, but virgin's DNS servers were still being pulled through as a "dynamic server" according to the RouterOS panel. I thought Virgin was fiddling with my DNS requests even though I was sending them to a different provider.
- floatingatoll 6y ago
  Incorrect. Requiring HTTPS would absolutely protect against hijacking of top-level domains that aren't registered, as no SSL/TLS issuer that's trusted by browsers will issue certificates covering those domains. A first step towards that eventual outcome would be to default to https:// https:// for anything typed by a user that doesn't start explicitly with http:// http:// so that they are protected from NXDOMAINs in that regard. I hope that the various browsers implement at least that first step.
- cortesoft 6y ago
  ESNI does
Ericson2314 6y ago
You mean DNSSEC
- adrr 6y ago
  DNSSEC isn’t coming anytime soon. AWS and azure don’t even support it yet. More likely this will be resolved by DoH than DNSSEC. Isn’t chrome suppose to adopt it this fall and Firefox already has it with the default being cloudflare as the resolver.
  - tptacek 6y ago
    "Yet". It's been almost 25 years.
  - jeroenhd 6y ago
    DNSSEC is coming though. Cloudflare supports it and half the internet runs on Cloudflare. Amazon and Azure are still lagging behind, but those aren't going to ignore DNSSEC forever. DoH solves nothing in this context unless we centralise DNS resolution to Google or Cloudflare. The Windows method submits the DNS requests to the same server as your regular DNS server by default, so the protocol doesn't give you any advantage there. Chrome does the same thing; if it detects that your name server does DoH, it'll switch to that, but it won't switch DNS servers. Perhaps this does solve the problem for the few people with custom DNS servers getting their queries intercepted, but the vast majority of people (everyone not using Firefox inside the US) won't notice any difference. DNSSEC will solve this problem by making the certification chain break for domains that haven't been signed by their TLD, but only if we start enforcing it (like we are enforcing HTTPS for certain features already). DNS over HTTPS will just encrypt the bad NXDOMAIN DNS query when it comes from the same malicious server, only protecting against traffic interception when using different DNS servers; the two protocols serve different purposes.
    - tptacek 6y ago
      Cloudflare sells DNSSEC services. They've supported DNSSEC for years, and adoption of DNSSEC in the US --- outside of people who get it by default with Cloudflare --- hasn't budged. DoH breaks ISP DNS interception immediately, and for all zones, not just the rare DNSSEC-signed ones, by moving DNS resolution off-net to a more trusted provider. The irony is, breaking NXDOMAIN interception is in fact a core use case of DNSSEC, and the protocol simply won't work for it, because the ocean needs to boil before every vector of the attack is closed. DoH went from the whiteboard to deployment in a tiny fraction of the time, and actually closes this hole decisively.

Just require HTTPS already.

by adrr 6y ago

Just require HTTPS already.

godman_8 6y ago

HTTPS doesn’t protect against DNS or SNI interception

adrr 6y ago
If there’s no valid cert for the domain, you can’t 301/302 redirect over https connection. SNI just lets the middleman peak at the host name, it doesn’t allow you to redirect. DNS interception allows the attackers to change IP but https still needs a valid cert for the host.
- kenniskrag 6y ago
  With HSTS and preload it should mitigate the vulnerability.
  - adrr 6y ago
    Issues with HSTS is that it is opt in. It should be an opt out with a list of legacy sites that ships with the browsers similar to how hsts preloading works.
    - Polylactic_acid 6y ago
      The option browser vendors are going with seems to be to make http show a full page warning about being insecure. No need to change HSTS now.
- stordoff 6y ago
  Incidentally, this affects how my ISP implements its domain blocks. Non-HTTPS sites are 307 redirected to https://assets.virginmedia.com/site-blocked.html https://assets.virginmedia.com/site-blocked.html, whereas connections to HTTPS sites are just halted (IIRC, it sends a TCP reset, but it's a while since I looked into it).
  - amiga-workbench 6y ago
    That reminds me, I turned this off the other day and it still hasn't taken effect yet. https://my.virginmedia.com/advancederrorsearch/ https://my.virginmedia.com/advancederrorsearch/ Its a good thing DoH is now in the stable version of RouterOS, I've just switched it on.
    - JdeBP 6y ago
      You don't need DoH to avoid that. Just set up and use your own resolving proxy DNS servers and don't use the Virgin Media ones at 194.168.4.100 and 194.168.8.100 either directly or indirectly. (This means not forwarding to those servers, and not letting your DHCP client, in any of your machines, configure your system to use them when it gets a lease.) Here is the difference between using Virgin Media's resolving proxy DNS servers and using your own: % # http://jdebp.uk./Softwares/djbwares/guide/commands/dnsqrx.xml % % dnsqrx a z398nvfsd0098u3qwtltnk. 194.168.4.100 1 z398nvfsd0098u3qwtltnk: 56 bytes, 1+1+0+0 records, response, noerror query: 1 z398nvfsd0098u3qwtltnk answer: z398nvfsd0098u3qwtltnk 0 A 92.242.132.24 % % % dnsqr a z398nvfsd0098u3qwtltnk. 1 z398nvfsd0098u3qwtltnk: 40 bytes, 1+0+0+0 records, response, authoritative, nxdomain query: 1 z398nvfsd0098u3qwtltnk % That last query didn't even escape the machine in my case. I run a private root content DNS server on every machine if possible. The query here got answered by a tinydns instance listening on 127.53.0.1: % tail -n 1 /var/log/sv/tinydns/current | tai64nlocal 2020-08-26 09:37:44.305619726 7f000001:cfd9:f163 + 0001 z398nvfsd0098u3qwtltnk % No-one gets to complain about (minuscule) extra load on the root content DNS server except me. It's my server on my machine. (-:
      - amiga-workbench 6y ago
        I've just realised my mistake, I needed to turn "use-peer-dns" off. I did have my router setup to cache DNS requests to google and updated the DHCP config so everything would use my router for resolution, but virgin's DNS servers were still being pulled through as a "dynamic server" according to the RouterOS panel. I thought Virgin was fiddling with my DNS requests even though I was sending them to a different provider.
floatingatoll 6y ago
Incorrect. Requiring HTTPS would absolutely protect against hijacking of top-level domains that aren't registered, as no SSL/TLS issuer that's trusted by browsers will issue certificates covering those domains. A first step towards that eventual outcome would be to default to https:// https:// for anything typed by a user that doesn't start explicitly with http:// http:// so that they are protected from NXDOMAINs in that regard. I hope that the various browsers implement at least that first step.
cortesoft 6y ago
ESNI does

Ericson2314 6y ago

You mean DNSSEC

adrr 6y ago
DNSSEC isn’t coming anytime soon. AWS and azure don’t even support it yet. More likely this will be resolved by DoH than DNSSEC. Isn’t chrome suppose to adopt it this fall and Firefox already has it with the default being cloudflare as the resolver.
- tptacek 6y ago
  "Yet". It's been almost 25 years.
- jeroenhd 6y ago
  DNSSEC is coming though. Cloudflare supports it and half the internet runs on Cloudflare. Amazon and Azure are still lagging behind, but those aren't going to ignore DNSSEC forever. DoH solves nothing in this context unless we centralise DNS resolution to Google or Cloudflare. The Windows method submits the DNS requests to the same server as your regular DNS server by default, so the protocol doesn't give you any advantage there. Chrome does the same thing; if it detects that your name server does DoH, it'll switch to that, but it won't switch DNS servers. Perhaps this does solve the problem for the few people with custom DNS servers getting their queries intercepted, but the vast majority of people (everyone not using Firefox inside the US) won't notice any difference. DNSSEC will solve this problem by making the certification chain break for domains that haven't been signed by their TLD, but only if we start enforcing it (like we are enforcing HTTPS for certain features already). DNS over HTTPS will just encrypt the bad NXDOMAIN DNS query when it comes from the same malicious server, only protecting against traffic interception when using different DNS servers; the two protocols serve different purposes.
  - tptacek 6y ago
    Cloudflare sells DNSSEC services. They've supported DNSSEC for years, and adoption of DNSSEC in the US --- outside of people who get it by default with Cloudflare --- hasn't budged. DoH breaks ISP DNS interception immediately, and for all zones, not just the rare DNSSEC-signed ones, by moving DNS resolution off-net to a more trusted provider. The irony is, breaking NXDOMAIN interception is in fact a core use case of DNSSEC, and the protocol simply won't work for it, because the ocean needs to boil before every vector of the attack is closed. DoH went from the whiteboard to deployment in a tiny fraction of the time, and actually closes this hole decisively.