Hacker News new | ask | show | jobs
by godman_8 2126 days ago
HTTPS doesn’t protect against DNS or SNI interception
3 comments

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.
Incidentally, this affects how my ISP implements its domain blocks. Non-HTTPS sites are 307 redirected to 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).
That reminds me, I turned this off the other day and it still hasn't taken effect yet. https://my.virginmedia.com/advancederrorsearch/

Its a good thing DoH is now in the stable version of RouterOS, I've just switched it on.

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. (-:
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.

With HSTS and preload it should mitigate the vulnerability.
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.
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.
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:// for anything typed by a user that doesn't start explicitly with http:// so that they are protected from NXDOMAINs in that regard.

I hope that the various browsers implement at least that first step.

ESNI does