I can't get past the `size_t i` rather than `int i` in the first loop. Why. I suppose it is some type of defensive programming.
Bit flip changes an int to a large negative value. Now you're stuck doing a signed comparison for a while.
Chromium's Impact on Root DNS Traffic
181–190 of 221 posts
Re: Chromium's Impact on Root DNS Traffic
#182Couldn't the traffic be somewhat reduced by changing the time and order of operations? Currently, Chrome does the following: (1) on each network change, send three DNS requests with random hostnames. (1a) If at least two of the queries resolve to the same IP, store the IP as the "fake redirect address". (2) on a user search, query the first search term as DNS. (2a) If the query result is NXDOMAIN or matches the fake…
> (1a) If at least two of the queries resolve to the same IP, store the IP as the "fake redirect address". From reading the source, it actually does a HTTP HEAD chasing redirects, and records the origin of the final page, and uses that as the redirect address. So even if two hostnames yield different IPs, if they end up redirecting to same hostname, it will be detected > (2a) if the two queries resolve to the same IP…
> What if an ISP uses multiple IPs in the fake redirect, and alternates over those IPs in each successive response?
Good point. I was wondering how they'd deal with that in the actual implementation.
I think you got the answer though: They match HTTP origins instead of IP addresses - so I imagine, you could do the same in step 2: Do a HTTP HEAD query to the search word and two additional ones to random hostnames, following redirects. If the final origins are the same, there is fakery going on.
A problem with this could be unexpected HEAD requests to actual internal hosts: There is no guarantee an internal host that was never meant to receive HEAD requests would react gracefully or in any way predictable to one.
I'm not sure how they solve this currently. Maybe this could at least be mitigated by only sending the HEAD request to the search word host if there is reasonable suspicion requests are being redirected - e.g. only if the two random hosts resolved and were both redirected to the same origin.
Finally, you could cut all of this short by also connecting to (search word):443 and trying to initiate a TLS session handshake. If the host answers, you know it's probably a genuine internal host that talks HTTPS and you don't need to do any additional probes. (And you can also abort the handshake and don't ever need to send an actual HTTP request to the host)
Re: Chromium's Impact on Root DNS Traffic
#183Wait, so Chrome leaks the first word of my searches to my ISP? That doesn’t sound like something I want to happen
Not exactly. Chrome doesn't know if you're trying to enter a domain name, hence URL, or are trying to enter a search term. The Omnibar supports both. So Chrome tries to resolve the string you entered and if it gets back an NXDOMAIN it can assume that it's a search term. The problem is that some ISPs have configured their DNS resolvers to lie and not return NXDOMAIN. Instead redirecting you to some website for marketi…
DNSSEC can only distinguish valid from invalid NXDOMAINs on signed zones. A tiny, tiny minority of zones in .COM, .NET, .ORG, and .IO are signed. Installing your own local DNSSEC resolver to "fix" the Chrome URL bar would be a tremendous misallocation of effort.
If your ISP forges NXDOMAIN responses, the correct response is to DOH to a provider that doesn't do that. That's a simple networking config change, for which there is UI in every mainstream operating system. The DNSSEC part of this conversation is just silly.
Re: Chromium's Impact on Root DNS Traffic
#184Earlier quoted context omitted.
They could just use DNSSEC...
DNSSEC has to be supported by your ISP’s DNS server, which they won’t if they’re trying to intercept your queries.
They're suggesting you install your own local DNS server --- nothing prevents you from doing that, and just talking straight to the roots instead of through your ISP's DNS server.
The real problem is not your ISP, but rather the fact that the most important sites on the Internet have rejected DNSSEC and aren't signed. DNSSEC can't do anything for you with hostnames in zones that haven't been signed by their operators, and, to a first approximation, every zone managed by a serious security team (with a tiny number of exceptions like Cloud Flare, who sells DNSSEC services) has declined to do so.
Re: Chromium's Impact on Root DNS Traffic
#185The worst thing is, this will not even detect a well written NXDOMAIN interceptor that only hijacks requests to valid top level domains. It's about time for DNSSEC to be available on all TLDs and for browsers to nag if it is broken.
As I wrote above: DNSSEC can't do anything about unsigned zones, and the overwhelming majority of zones in both the North American Internet and in popular domain lists like the Moz 500 are unsigned, and will remain unsigned, despite almost a decade of pleading from DNSSEC advocates to recant.
What's crazy about this is that there's a trivial solution to forged NXDOMAIN responses that people can adopt immediately: just DoH to a provider that doesn't forge NXDOMAIN responses (none of the major providers do).
I sometimes wonder whether the vehemence of the anti-DoH advocacy is rooted in concern that it will cause DNSSEC to lose yet another potential motivating use case.
Re: Chromium's Impact on Root DNS Traffic
#186Earlier quoted context omitted.
Browser vendors seem to have shelved all work on DNSSEC for reasons they haven't publically stated. It had such promises to be able to reduce trust in CA's by pinning HTTPS certificates to DNS responses, so was exactly what browsers would have wanted, yet still all work stopped around 2015 or so. To me, it's as if DNSSEC has some critical and unfixable security vulnerability, and people who make these decisions decid…
I don't understand why browser vendors should be involved My browser should ask my OS to resolve DNS It's my OS's responsibility to do that - maybe sending a request to a remote server, maybe running it's own resolved, maybe using DoT, DoH, DNSSec or not What business should it be of browser vendors?
This weird idea of the delineation of responsibilities between the OS and applications has never actually been how things worked. For a very long time, the OS resolver libraries couldn't even reliably do asynchronous resolution, and applications like your browser provided their own. I think the notion that the OS "owns" DNS comes from the fact that people used to get their DNS servers from DHCP, and the OS's libraries automatically knew what servers DHCP had been configured. It's not like some kind of law of system design.
Re: Chromium's Impact on Root DNS Traffic
#187It seems like they could rotate these much less frequently to let caches work. It seems that these are random to avoid DNS servers hardcoding a response for them. However they could be pseudo random based on the current day, month or release so that it would be hard enough to intercept them (unless the DNS server was really committed to doing this, but there are other ways to achieve this) while still allowing a lot…
> It seems that these are random to avoid DNS servers hardcoding a response for them. However they could be pseudo random based on [the current date and browser release] That would still allow ISPs to compute the limited number of domains for which NXDOMAIN would need to be sent at any given point in time. (Whether they'd do it is another story. The random pattern currently used by Chrome looks like it may still be e…
As I said, if they make specific effort they will succeed. The current scheme can be broken by returning a number of different IPs instead of one or two. I think my proposal has a nice balance between making ISPs put in non-trivial effort and not putting a lot of load on the root servers.
Re: Chromium's Impact on Root DNS Traffic
#188Verisign has nobody but themselves to blame, for "inventing" this with its SiteFinder fiasco in 2003.
Right! Around 2010, when this feature was implemented in Chrome, hijacking was a business model that was discussed in regular meetings. I recall one hijacker trying to sell themselves to the company that was 'complaining' about the hijacks.
"Buy us out and we'll stop, and you can use the tech on your customers?!?"
One of the boldest business proposals I've been party to. After a few deep breaths and some laughter, the offer was not taken. But that wasn't a one-off event. Spent a lot of time in early 2010's directly trying to protect customers from this stuff. Still do, but it's getting much harder with TLS-everywhere, HSTS, DOH, and many other things. Not impossible though, we can never let up on the pressure to keep the ROI too low for hijacking. The various network operators and ISPs that let these companies put racks in their data-centers to inspect user traffic should be >.
Re: Chromium's Impact on Root DNS Traffic
#189Earlier quoted context omitted.
DNSSEC has to be supported by your ISP’s DNS server, which they won’t if they’re trying to intercept your queries.
They're suggesting you install your own local DNS server --- nothing prevents you from doing that, and just talking straight to the roots instead of through your ISP's DNS server. The real problem is not your ISP, but rather the fact that the most important sites on the Internet have rejected DNSSEC and aren't signed. DNSSEC can't do anything for you with hostnames in zones that haven't been signed by their operators…
Do any ISPs intercept upstream requests when running your own recursive resolver? If not, DNSSEC isn’t relevant here and you should be fine just fine with “only” running your own without requiring DNSSEC.
Re: Chromium's Impact on Root DNS Traffic
#190Earlier quoted context omitted.
They're suggesting you install your own local DNS server --- nothing prevents you from doing that, and just talking straight to the roots instead of through your ISP's DNS server. The real problem is not your ISP, but rather the fact that the most important sites on the Internet have rejected DNSSEC and aren't signed. DNSSEC can't do anything for you with hostnames in zones that haven't been signed by their operators…
Do any ISPs intercept upstream requests when running your own recursive resolver? If not, DNSSEC isn’t relevant here and you should be fine just fine with “only” running your own without requiring DNSSEC.
They could. I doubt they do.