What seems to have happened was that the people managing www.apple.com 404'ed the URL http://www.apple.com/library/test/success.html, which iOS loads automatically upon associating with a wifi AP. This causes iOS to believe the wifi is actually one of those public "captive" hotspots that redirects all HTTP before you authenticate/pay up, and fires up a modal web browser intending to let you log in.
About 10 minutes later, they seem to have restored the URL, and normal wifi access points are no longer incorrectly detected as captive.
What kind of blockage did you set up? A hijacking 404/403 HTTP response, or are you dropping IP packets to the www.apple.com IP addresses? If your router blocking is implemented on the HTTP level, then obviously you would see the same result as everyone just did when that URL returned 404.
I'd be more interested in learning how iOS reacts when TCP (HTTP) connections to that URL time out, or are treated as a closed port.
I love a good reason to be upset but I sympathize with this bug. It should be easy to get around the captive portal issue and they should have other contact domains besides apple.com (in fact, that's the most offensive part of this), but it's an admirable task. Imagine if you connect to the Wifi and it didn't do this... you'd have no idea why you're not receiving any of your data.
For what it's worth, recent copies of Android try to help you through the captive portal process as well, though I doubt they fail if android/google.com go down. (Though, Android has always had an indicator, they only become colored after Gapps makes a good connection to Google)
It's not an inability to access the site, it is explicitly receiving an invalid and unexpected response code, which indicates an impostor is returning responses instead of apple.com. (Except this time, they screwed up).
Exactly. If apple.com goes down, that doesn't look like a captive network. It's only if the site is up and responsive and returning the wrong result (which is what happened today) that incorrectly indicates the captive network.
A great many wifi networks are open to the public, but redirect all HTTP requests to a login page. Think airports, coffee shops, hotels, etc. This is called a "captive" network. The apple.com request here is a heuristic to detect the "captive" network, so it can show a web browser inline that shows you the redirected URL so you can log in. This is actually a really nice feature when you're on a captive network.
Right, as I mention in another comment, I'm well aware of this. However, it shouldn't be the end all be all and it should be more redundant anyway. It should use more domains. It should still allow the user to use the Wifi network if they want to. etc.
The devices aren't down, they just fall back to 3G.
If the page times out, I don't know what happens. But this time, the page explicitly responded with a 404, which it "should never do", so the device successfully detected a "MITM" and did the right thing. (Except in this case, apple.com webmasters screwed up)
No it's still broken (posting three hours after your comment) and fixing the 404 on apple link won't fix it.
My ISP requires me to login through a browser to give me access. I am sure majority are on always on connection but there might be a good number for this kind of setup too. What about airport token logins? Didn't expected this in an Apple device.
When a main frame HTTPS load is taking a while, we preemptively open a background request for http://www.gstatic.com/generate_204, and check the response code. We do the same when displaying SSL warnings and ERR_SSL_PROTOCOL_ERROR pages. The URL points to a service that returns HTTP 204 (“No Content”) responses, and the domain does not set any cookies or save any logs. If we’re not behind a captive portal, and connected to the Internet, we should get the 204 response code. If we’re behind a captive portal, we should either get the logon page or a redirect to one. If we get an error or a non-HTTP response, we’re either not behind a captive portal, or can’t find the logon page if we are. For the purposes of captive portal discovery, we treat all HTTP status codes except 2xx, 3xx, and 511 as errors. This works regardless of whether the captive portal works by intercepting DNS or HTTP traffic.
We also preemptively run captive portal checks when displaying SSL certificate error pages, since these are often caused by captive portals as well. There is no timeout in this case.
> Apple has sold 46.5 million iPod touch units in the US between the device's introduction in 2007 and the second quarter of 2012. (That's in addition to the nearly 86 million iPhones and 34 million iPads sold during that time.)
iPod Touches alone are 28% of total iOS sales. If wifi-only iPads make up 60% of iPad sales (and I think they're probably higher), then that's 40%. Consider also that the turnover rate on phones is probably higher than the more focused devices.
Ok, yes, I was a little cavalier in my phrasing, and didn't communicate what I meant (which was roughly "iOS devices with a cellular radio"). iPhones and iPads with cellular radios are typically multi-homed. Edit: And "typically" does not mean "exclusively."
Is it possible that someone at Apple was a little stupid one day and said to themselves, "Oh, an iPad is just like an iPhone, so I'll just use the same routing config script for both. And since I'm such an efficient employee, I'll go ahead and commit this obviously-trivial change without further tests"?
I had a similar, but separate issue - after upgrading to iOS 6, my wifi was disabled and wouldn't turn back on. Tried messing with settings, airplane mode, resetting network settings and restoring, but nothing worked. Doesn't look like I'm the only one either: https://discussions.apple.com/message/19620439#19620439
Fortunately the Apple Store replaced it. Free too.
What exactly stops an impersonator (or the operator of a captive network) from capturing/reproducing the content of http://www.apple.com/library/test/success.html and serving that to the iOS device? I could understand if it were over SSL, but it looks like this doesn't really do anything to stop a MITM attack.
Apple would do a lot of good if it didn't have
these kludges for "captive portals", maybe people
would stop using them then. They're just connection
hijacking, a horrible idea for a million reasons and break most HTTP applications.
No, the way AP's etc work is on request of any url it verifies that they have logged in or done what ever. Since the iphone is requesting that URL it can detect if there is an AP and then prompt the login stuff. Really it's not that big of a deal lol.