Criminals are hacking into public Wi-Fi devices—at hotels, conference centers, and so on—around the world and changing their DNS settings. The goal is to redirect users to fake login pages and steal their credentials.
Andrew Olpin • August 17, 2026 9:32 AM
Yes, the DNS would direct them to the wrong server, and the attacker could HTTPS encrypt the traffic. The trouble is that no reputable cert issuer will issue some rando a cert for “google.com,” so it’s very likely the certificate won’t be trusted by the browser.
My guess is the attackers will go for HTTP and hope the user doesn’t notice.
Privacy • August 17, 2026 11:22 AM
DNS translates every user request such as for google.com to an IP address.
A hacker in control of DNS can redirect a request to anyplace they choose, not only Microsoft 365.
The router used in public WiFi may not be configured securely or may have a vuln.
That’s why a travel router is a must when using public WiFi.
A travel router sits between a user PC and public WiFi (or hotel WiFi), providing NAT and DNS.
The PC user needs to set encrypted DNS in their browser and router, to avoid revealing which sites they request.
DNSSEC gives the PC user assurance the site they connect to is the genuine site, instead of a site a hacker controls.
A travel router running OpenWRT firmware is a good bet. OpenWRT is open-source.
GL-iNet is a company I have no connection to except being a user of their routers.
My routers run OpenWRT and I use an anti-malware encrypted DNS service that performs DNSSEC.
Hacking is rampant these days, for stealing information, stealing money, setting up a botnet, etc. Good cybersecurity has become an absolute necessity.
rando • August 17, 2026 11:27 AM
@Andrew Olpin,
“My guess is the attackers will go for HTTP and hope the user doesn’t notice.”
Yup, exactly that. All browsers should completely eliminate the HTTP option(completely remove the option)… plus, man, this .js crap is just about everywhere. Like some self-destruct feature when it comes to security and privacy.
mark • August 17, 2026 12:51 PM
Wonderful. So if I want to check my email while I’m, say, at Worldcon in LA, what should I do – edit my android hosts file to use 8.8.8.8 to get DNS? Aim my browser at the IP address of my hosting provider?
Not Really Anonymous • August 17, 2026 1:34 PM
You don’t need to use public resolvers to do DNS lookups. Your device can do lookups starting at the root (which will get cached, so it won’t need that for every request) and work it’s way down.
lurker • August 17, 2026 1:42 PM
@Andrew Olpin
“My guess is the attackers will go for HTTP and hope the user doesn’t notice.”
Uhuh. When my local library dropped WPA2 for an “open” system, three of the five browsers on my laptop complained that www[dot]schneier[dot]com was insecure, and somebody might be spoofing it. I have to keep a copy of the highly recommended Firefox just so i can register with their proxy, then the TLS seems to work OK. (I know, telling you’re being MITMed isn’t that simple)
@mark
It’s tough when you’re forced to use webmail because the (say Worldcon) proxy has blocked the IMAP ports. And pdnsd is great to have for those weekends away.
RedLight • August 17, 2026 6:54 PM
Uhhh. Wait a sec…
Seems like there’s an awful lot of HTTPS-capable websites out there. It can’t be that hard to get a security cert. It doesn’t have to be foo.com’s security cert. Any sercurity cert will do!
Problem is, my web browswer can’t tell whether I’m talking directly to foo.com’s IP address or to the 1.2.3.4 ip address. It only knows the destination has a security cert and can connect over HTTPS.
That’s a problem. Suddenly Firefox’s secure-DNS seems like a godsend!
Mr D • August 17, 2026 8:35 PM
@RedLight it absolutely matters that it’s a security cert for the correct site – the cert is tied to the DNS name of the site. This is a non-trivial attack if limited to https only – and a bunch of security measures in browsers make forcing http much harder than it was.
The number of phone apps that don’t validate certs properly probably gives easier attacks than the browser, though getting a fake cert has been done a few times
Carl Fink • August 17, 2026 10:09 PM
@mark, have you considered a proxy service? With a proxy enabled, all your traffic would presumably be encrypted and sent via a proxy server, so this attack would be bypassed. FWIW, Proton has a free tier.
beautiful • August 17, 2026 11:23 PM
It’s a beautiful day in this neighborhood,
A beautiful day for a neighbor,
Would you be mine?
Could you be mine?It’s a neighborly day in this beautywood,
A neighborly day for a beauty,
Would you be mine?
Could you be mine?I have always wanted to have a neighbor just like you,
I’ve always wanted to live in a neighborhood with you.So let’s make the most of this beautiful day,
Since we’re together, we might as well say,
Would you be mine?
Could you be mine?
Won’t you be my neighbor?Won’t you please,
Won’t you please,
Please won’t you be my neighbor?
Privacy • August 17, 2026 11:52 PM
I recall an experiment I did years ago.
My wife and I each with a PC, using the same WiFi router.
I changed some settings of my PC to match her PC’s settings.
If I recall correctly I got her PC’s settings from WiFi monitoring software and the routing table in the router.
After changing the settings of my PC the router could not distinguish my PC from her PC, I saw on my screen whatever was on her screen.
I found it a trivial exercise and a reason to never use public WiFi (or hotel WiFi) without connecting through a travel router.
Anonymous • August 18, 2026 12:04 AM
One thing about, “Encrypted DNS” or, “DNS over HTTPS” which Mozilla Firefox has customization’s for, what nobody on the web talks about, what about the OCSP port 80 check?
It’s like a dog chasing it’s tail, how do you encrypt the OCSP port, even Tor uses it but I don’t see unencrypted port 80 like I do with clear-net.
Strange.
Anonymous • August 18, 2026 12:04 AM
One thing about, “Encrypted DNS” or, “DNS over HTTPS” which Mozilla Firefox has customization’s for, what nobody on the web talks about, what about the OCSP port 80 check?
It’s like a dog chasing it’s tail, how do you encrypt the OCSP port, even Tor uses it but I don’t see unencrypted port 80 like I do with clear-net.
Strange.
i haven’t read ALL the comments yet but 2 things:
1) you can preresolve specific domains if all you need is an ip. the routes will be diff but who cares. https will protect the traffic especially if there’s a predistributed certificate involved.
which brings me to #2) JAVASCRIPT wouldn’t be as big of an issue if we had signed modules or checksummed modules, considering how many sites overlap in their js i can’t see why we don’t have standardisation signed or measured modules and predistribution.
no time today apologies.
GregW • August 18, 2026 9:08 AM
Re:OCSP checks, it’s a chicken and the egg thing, to check that an SSL connection and cert can be trusted, OCSP will check over port 80 with the certificate authority (CA) that it hasn’t been revoked. Even if that check could go over 443, how would you know that TLS cert used at the CA for OCSP itself revoked?
It’s not fun trying to convince your local cybersecurity compliance/review committee that they should override your CISO’s “no port 80” mandate because “that’s how the Internet/TLS/revocation works”.
If I recall correctly, the industry somewhat mitigates this in practice via browser side revocation lists (which won’t work for database or other TLS client connections) and or OCSP stapling.
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Carl Fink • August 17, 2026 8:10 AM
Would that be compatible with https? Would the fake login page not have the wrong cert, if it even had SSL enabled? Or is the user meant not to notice a redirect from att.net to att.someotherdomain.net or something?