Updated iOS 6 devices don't connect to WIFI | Hacker News Reader

Updated iOS 6 devices don't connect to WIFI

forums.macrumors.com

74 pointsobilgic57 comments

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.

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.

Chromium's design doc for handling captive portals (for comparison):

https://docs.google.com/document/d/1k-gP2sswzYNvryu9NcgN7q5X...

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.

http://www.apple.com/library/test/success.html

This is the url all iOS devices request as soon as they are connected to wifi. And It is currently down.

Edit: It is back now. And this is the response:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
    <HTML>
    <HEAD>
	    <TITLE>Success</TITLE>
    </HEAD>
    <BODY>
    Success
    </BODY>
    </HTML>

It is like a self-DDOS now.

It just came back up. Phew.

Yeah, I guess the problem was that everyone in the US started the update process nearly at the same time.

1990's styled all uppercase HTML tags.

Why HTML 3.2, I wonder?

Probably because the guy who was forced to code it knew the whole idea was stupid.

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.

In fact, if you control that URL, then you are operating a captive network, which is precisely what accessing that URL is meant to detect.

What if the URL gets successfully DDOS'd?

Because your botnet will generate more traffic than every iOS device in the world connecting to a wifi network?

Every iOS device connects at the same time?

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.

It's not a problem with iOS 6. I've been running the GM for a week with no problems. This issue just appeared in the last couple of hours.

Agreed. I've been running one of the last dev releases for weeks and have had 0 problems.

Original Issue Forum Post - Time: 05:56 PM

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?

This is how does it work http://www.digitaltrends.com/mobile/apple-devices-call-home-...

As I said, I understand the reasoning.

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?

An iOS device is typically multi-homed. Think about what routing options the typical iPhone has and how it likely picks a default route.

I'd be willing to bet more than 40% of iOS devices are not multi-homed - iPod Touches and wifi-only iPads.

From http://arstechnica.com/apple/2012/08/apple-lifts-curtain-on-... :

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

Well, gotta admit that I always liked my iPhone detecting an AP requiring some kind of user confirmation or something like that.

It's a lame way to do it though.

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.

Yep I ran into the same issue and now looks like the page is up so its fine. So if it is a success its good if not redirects?

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.

Anyone else having trouble connecting to corporate networks with a self-signed certificate?

i updated, didn't have any trouble

Reply on news.ycombinator.com