Hacker News Reader

Comment by 0x0 | Hacker News Reader

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.

View on HN

Basically: if apple.com is down, all the ios devices go down...

I just checked this - If I block apple.com on my router, wifi on my iPad becomes unusable when reconnected. When re-enabled, no problem.

Apple just fell quite a few points for me.

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 just went to the parental access control section on the router (a free router the ISP gave me) and set apple.com to block.

I guess if you're a large corporate and you don't want iPads/iPhones using your wifi, this is an absolutely great way to block them with zero effort!

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)

One would assume that inability to access the site would not be interpreted as a captive network, because that's not what captive networks look like.

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).

It has nothing to do with imposters.

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)

You're assuming all devices _have_ 3G. My iPad doesn't...

You are assuming all devices have 3G?

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.

internet connection != http://www.apple.com/library/test/success.html

When did "successful wifi connection" mean having access to this unstable apple.com url?

Since for 99.99999% of users being able to visit a web page means the internet is working.

Remember Apple never optimises for edge case.

I had no idea the entire internet became unreachable when a particular apple.com URL became inaccessible. Is there an RFC that covers this?

nope, but a better fallback would probably be: http://tools.ietf.org/html/rfc2549

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.

Reply on news.ycombinator.com