4 ms·

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

by obilgic 14y ago

0x0 14y ago
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)
- obilgic 14y ago
  You are assuming all devices have 3G?
  - 0x0 14y ago
    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.
    - obilgic 14y ago
      internet connection != http://www.apple.com/library/test/success.html http://www.apple.com/library/test/success.html When did "successful wifi connection" mean having access to this unstable apple.com url?
      - taligent 14y ago
        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.
    - mikeash 14y ago
      I had no idea the entire internet became unreachable when a particular apple.com URL became inaccessible. Is there an RFC that covers this?
      - Blara 14y ago
        nope, but a better fallback would probably be: http://tools.ietf.org/html/rfc2549 http://tools.ietf.org/html/rfc2549
- christoph 14y ago
  You're assuming all devices _have_ 3G. My iPad doesn't...
eridius 14y ago
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.
- 0x0 14y ago
  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).
  - eridius 14y ago
    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.
  - drivebyacct2 14y ago
    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).
    - deleted 14y ago
      [deleted]
    - eridius 14y ago
      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.
christoph 14y ago
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.
- 0x0 14y ago
  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.
  - christoph 14y ago
    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!
    - vbmnbv 14y ago
      Do you have an option to redirect said URL? If so, this would make a great vector for attack on all Apple iOS devices. 1. Hijack router 2. Set up a rule 3. Watch and wait
- drivebyacct2 14y ago
  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)

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

by obilgic 14y ago

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

0x0 14y ago

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)

obilgic 14y ago
You are assuming all devices have 3G?
- 0x0 14y ago
  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.
  - obilgic 14y ago
    internet connection != http://www.apple.com/library/test/success.html http://www.apple.com/library/test/success.html When did "successful wifi connection" mean having access to this unstable apple.com url?
    - taligent 14y ago
      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.
  - mikeash 14y ago
    I had no idea the entire internet became unreachable when a particular apple.com URL became inaccessible. Is there an RFC that covers this?
    - Blara 14y ago
      nope, but a better fallback would probably be: http://tools.ietf.org/html/rfc2549 http://tools.ietf.org/html/rfc2549
christoph 14y ago
You're assuming all devices _have_ 3G. My iPad doesn't...

eridius 14y ago

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.

0x0 14y ago
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).
- eridius 14y ago
  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.
- drivebyacct2 14y ago
  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).
  - deleted 14y ago
    [deleted]
  - eridius 14y ago
    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.

christoph 14y ago

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.

0x0 14y ago
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.
- christoph 14y ago
  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!
  - vbmnbv 14y ago
    Do you have an option to redirect said URL? If so, this would make a great vector for attack on all Apple iOS devices. 1. Hijack router 2. Set up a rule 3. Watch and wait
drivebyacct2 14y ago
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)