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.
I'm not buying that as an excuse for why the implementation REFUSES to let you on the WiFi.
Besides the fact that it's terribly fragile (as seen here), but if it's really an anti-imposter measure, it's a pretty awful one. (Okay, we'll just MITM every non-apple.com URL).
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)
In any case, if the wifi AP responds with "impossible" results, the wifi access point is for all purposes "unusable", and you wouldn't be able to get on the internet anyways.
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.
Wait, you're saying if I can control that URL I can prevent all iOS devices in the world from connecting to the Internet ? That sounds seriously dangerous. Or am I mis-understanding?
If you can control that URL, you can probably control ANY URL, and thus you can already prevent any (not just iOS) devices from connecting to the internet _via your wifi ap_. No surprises there.
iOS falls back to 3G when the page doesn't respond as expected.
There's a large enough proportion of them connecting to wifi networks at a given time and a very large number of devices. Plus it's a very small static page.
First Negative Forum Post - Response Time: 06:00 PM (same day) : "I think this is the worst iOS release to date.
And Steve would've never allowed this."
Due of the Internet archive, these forum posts may well be our greatest legacy.
I've just had the same problem. I can't understand how that page being inaccessible completely kills wifi...??!!? How does that make any technical sense whatsoever?
I understand the reasoning, but for it to totally wipe out Wifi?
I just don't understand how it completely destroys wifi when inaccessible. Windows 7 does a similar thing, but when the page is inaccessible, it doesn't completely kill the internet connection.
Basically, if Apples servers dissapear... Am I to believe that wifi becomes a useless feature on my iDevice, or am I missing a piece of the puzzle?
> 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."
My iPad has one route to the internet and it's wifi. If apple.com is inaccessible (i.e. I block the domain on a router) is should not render the entire internet inaccessible.
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"?
This seems a fairly dangerous injection vector for malicious wifi APs. I assume that the browser is opening to the same URL and capturing that and redirecting to a malicious site should be trivial.
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.
The purpose isn't to stop a MITM attack, it's to pop up a captive portal browser when you may be trying to use an app that isn't a web browser (Mail, Shazam, etc) and that would just not work.
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.
About 10 minutes later, they seem to have restored the URL, and normal wifi access points are no longer incorrectly detected as captive.