Recently, when I tried to access http://slashdot.org/ in Firefox, I would see my browser title bar flash briefly to “AT&T GUI”, and then I would get redirected to: http://slashdot.org/cgi-bin/redirect.ha which returns slashdot’s custom error 404 page! What is going on? (Read on for answer…)
- Did slashdot mess up their mod_rewrite config?
(Nope, works fine in a different browser…) - Did my HTTPS everywhere extension go crazy?
(Nope, still broken when disabled…) - Are my HTTP requests being MITM-ed?
(Yes, probably by the NSA, but they wouldn’t make this kind of mistake…) - Is my computer p0wned?
(I use GNU/Linux, so probably not…)
A keyword search will show you that others are also affected by this, except that the base domain (slashdot.org) is usually different… One thing that all the links I viewed have in common: none of them seem to know what’s happening.
Some background:
Recently, I used my laptop with a public WIFI access point. The router behind these access points usually performs a MITM redirection on your HTTP traffic to send you to a captive web portal which you’ll need to use before being authorized to route out to the public internet.
After connecting to the wireless SSID, whichever site you visit next will get replaced with the portal. This typically can’t be an HTTPS url, because they aren’t easily MITM-ed without causing a certificate error.
On my Firefox new tab page, the only non-HTTPS site that I visit is http://slashdot.org/ and as a result, I’ll click this link when I know I’m expecting a portal… (Seriously slashdot, wtf!)
What’s happening?
When I visited http://slashdot.org/ on public WIFI, the captive portal web page got permanently cached in my browser, and now every time I attempt to visit slashdot, I actually get the cached, MITM-ed, portal version.
How to fix this?
Actually it’s very simple: just clear your browser cache. You don’t need to delete your cookies or your history. Choose the “Clear Now” button in Firefox. Example:
Whose fault is this?
- The AT&T portal programmers for allowing a portal page to be cached.
- Any website that doesn’t require HTTPS (and lets themselves get MITM-ed).
- Firefox for not protecting against this (other browsers are affected too!)
- Public WIFI services for using captive portals (just free the internet already!)
Is there any good news?
It’s easily fixed, and there didn’t seem to be any malicious code in the cached web portal redirector. It turned out to only include a META refresh. Phew :)
Hope this provides an authoritative answer for everyone who is experiencing this problem!
Happy hacking!
James
The Technical Blog of James 
In Fedora 21, GNOME Shell will automatically detect captive portals upon connecting to wifi and popup a dedicated window to walk through their login page. This nicely avoids the problem you are describing, because none of your existing web browser tabs get redirected to the captive portal. Probably my favourite improvement from Fedora 21 / GNOME Shell.
This sounds like a wicked feature… What logic is used to detect them? Maybe a second step could be to script getting through them, and then automatically starting a VPN connection or SSH tunnel!
The detection feature is built into Network Manager – you can set a ‘[connectivity]’ section with a URL, an expected response and an interval. Whenever Network Manager has an active connection, it will periodically access that URL and if it doesn’t get the expected response it will set the connectivity status on that connection to “limited”.
GNOME shell just watches the connectivity status reported by Network Manager and launches some sort of mini browser to handle the captive portal, when connectivity is limited.