151–160 of 221 posts
Wait, so Chrome leaks the first word of my searches to my ISP? That doesn’t sound like something I want to happen
How do you mean? So if I type ihavecancer, it tries to resolve to ihavecancer.com or something?
For me, the kicker: if I'm reading it correctly, over 40% of DNS traffic to the root server they examined is just diagnostic probes from Google Chrome being used to spot malicious DNS servers.
We got hit by this issue in March when our remotr users increased 5+ times and the DNS traffic going through our VPNs was causing a headache to our DNS servers. We pinpointed this to tis Chrome functionality, which includes also other chromium based browers like new Edge, and we had to deploy a relevant GPO to disable this functionality. Some background, I'm talking about ~200+k remote users. Also while in the office…
Earlier quoted context omitted.
how would they maintain the root servers and correct issues without shell access or tcpdump? Make blind guesses and restart the server until the problem goes away (it won't)? No matter how high-profile the environment, eventually, the rubber will hit the road and some human will be in a privileged position to be able to fix a problem. That is true for every single service out there. Yes. Including Gmail. Including AW…
Why is a server with a problem still part of the root zone? And no, this is absolutely not the case for serious operators. Access to production systems is highly regulated.
Earlier quoted context omitted.
No, they couldn't. The whole purpose of these probe requests is to assess whether the DNS server used by a particular client is acting normally (responding with NXDOMAIN if a domain does not exist), so these must bde sent to the DNS server of the client, which effectively means that unless this DNS server performs the hijacking that is to be detected, they will inevitably end up on a root DNS server, because no serve…
Instead of http://asdoguhwrouyh , they could probe something like http://asdoguhwrouyh.google or anything else in a zone owned by them, so the uncachable traffic would hit only their authoritative name servers and not the root servers.
Wait, so Chrome leaks the first word of my searches to my ISP? That doesn’t sound like something I want to happen
I'm always baffled why chrome can't have a separate search/address bar, which avoids this issue entirely.
* Type/paste a URL
* Type/paste a search
* Search my browser history (usually to jump to a previous URL)
* Use search engine keywords to do direct searches on some applications I use regularly (eg, "jira P-123" does a search in JIRA directly, which happens to jump to that ticket directly)
Browsers that separate those two drive me a bit crazy, because of the extra thinking required before typing.
(I don't really like this whole "using the first search term as DNS lookup" but that's separate from the UX of single vs separate inputs.)
Earlier quoted context omitted.
This comment, and another one mentioning DNSSEC has been downvoted. Please explain why you hate DNSSEC instead of downvoting things you disagree with.
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…
DNSSEC has not seen widespread adoption because of complexity in implementing and maintaining DNSSEC and concern over weaknesses in the encryption chosen. The protocol has been around a long time now and the encryption involved is not modern. Some DNS providers are making DNSSEC easier by handling keysigning and rotation with no user involvement. Just check the box that you want it activated.
DANE is the storage and retrieval of certificates via DNS. DANE depends upon DNSSEC to sign the certificate records to determine that haven't been spoofed.
There is no great conspiracy theory needed regarding why DANE has not been implemented in browsers. The browser makers have been pretty open about why they have chosen not to support it. For example code has been written for Chrome but Google has said they haven't shipped it because they don't want to support the 1024-bit RSA required as part of the DNSSEC standard.
Earlier quoted context omitted.
I'm always baffled why chrome can't have a separate search/address bar, which avoids this issue entirely.
They design for an audience that, on average, cannot distinguish betweeen the address bar of the browser and the search bar on the Google homepage.
My grandmother doesn't know the difference between an "address bar" or "search bar". Recently she got an email from her insurance company telling her to go to their website www.whateverinsurance.com and click "sign in" and then click "my account" and update her credit card info. The email had the url but it wasn't a link for some stupid reason. She goes to her browser and types in "www .whateverinsurance..com" because her eyesight isn't very good anymore and presses enter. Then instead of giving her an error saying the website doesn't exist and she should re-try entering it, it goes to a Google search page! She clicks "sign in" but her password doesn't work because she's on Google instead of her insurance website. So I get a call and have to figure out why her "insurance isn't working".
When I finally get her to her insurance website, she mistypes her password and presses "log in", and nothing happens. Windows is configured with 175% magnification, which means that the "invalid password" div that appears isn't visible on her screen unless she scrolls to the top of the page!
She originally tried calling her insurance company and updating her credit card number by phone, but she couldn't enter her credit card number fast enough and it timed out and told her to go to the website instead. WHY DON'T THEY TEST THIS STUFF???!?
Sorry, I went on a tangent there. I get irrationally upset by this kind of stuff.
It would be interesting to have an estimate of the energy consumed (globally) by this Chrome/Chromium feature...
Couldn'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…
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 as the first one, we have a fake redirect. Don't do anything. Otherwise, show the "local domain" hint.
What if an ISP uses multiple IPs in the fake redirect, and alternates over those IPs in each successive response?