The purpose of this request is to discover if there is a "captive portal" in the way. A captive portal is when, after connecting to the WiFi, any web request you makes gets redirected to a login/ToS page. In order to continue, you must either login with a username/password (or sign up, then login), and/or access the Terms of Service.
The reason Apple does this is because you may be using an app other than the web browser. For example, the only thing you might be doing is syncing your e-mail. In such situations, you would never see the portal page, and your app will mysteriously fail to connect to the Internet.
Therefore, before your app has a chance to access the network, Apple does this for you. It sends out a request to the above URL. If the request gets redirected, then Apple knows there is a portal. It then launches a dialog box, containing Safari, to give you a chance to login.
The following is the sniffed version of the HTTP request:
GET /library/test/success.html HTTP/1.0 Host: www.apple.com User-Agent: CaptiveNetworkSupport/1.0 wispr Connection: close
One of the questions people had was whether this was a privacy issue. the answer is "largely no". It sends no personally identifiable information. In particular, it doesn't send any cookies. The request is made from the WiFi software, not Safari. Therefore, any cookies you have in Safari will not be sent via this request. I verified this myself, by accessing Apple.com via Safari and watching cookies being sent, but verifying this did not send cookies.
Another question is whether this is an attack vector. The answer is "probably yes". There is more to the functionality than a simple HTTP request. If you look up the keyword "wispr" from the User-Agent string, you'll find out why.
The idea is that smart WiFi portals will detect that this is a WISPr-supporting device, and send back a WISPr message in XML. This allows the iPhone to then login with cached credentials via another XML message. This means, for example, you might be able to grab somebody's credentials with a properly configured WiFi access-point.
I've seen the iPhone deal with such an intelligent WiFi access-point, but at the time, I did not have the presence of mind to sniff the exchange, so I'm not sure what happened.
Another odd bit of behavior was loging onto an "attwifi" access-point at Starbucks. As you might have heard, using the iPhone on their network is free. The way this works is that the iPhone sends out a request to "http://attwifi.apple.com/library/test/success.html: the same URL as before, but with the "attwifi" in front.
At my local Starbucks, all web surfing is free. But, Windows presents a captive logon page where you must accept the Terms of Service, but the iPhone doesn't. I assume the portal detects this URL, and automatically opens up the access-point without doing a redirection. I need to test witha Linux distro in order to figure out what's going on.
No personally identifiable information is sent, so there isn't much of a privacy breach.
There is more complexity to this feature than the simple HTTP request; there is probably a way to attack it.
You can probably configure your machine to emulate this request, and get free WiFi that is intended for iPhones.
UPDATE 2012-Sep-19: On the day of iPhone 5 release, this webpage went down, breaking everyone's WiFi.
> You can probably configure your machine to emulate this request, and get free WiFi that is intended for iPhones.
I'm extremely interested in this. At one of the clients that I visit, so many people have iPhones that ATT volunteered to install an attwifi network in the building. Yet, I'm still stuck with TMobile tethering to get to my internet access since the client doesn't allow any unapproved hosts joining their network.
I've spent some time working with this recently. don't rely on "wispr". that's configurable.
Probably also gives Apple a good handle on how many devices of what version and what operating system version are currently out there.
@Joel: It does? How? I don't see anything in that request that would indicated what version it's running.
You can see how the Mac decides which wispr URL to probe for by perusing /Library/Preferences/SystemConfiguration/CaptiveNetworkSupport/Settings.plist
Recently my ISP's cache server developed some issues and since then I'm not able to access www.apple.com on my net connection. This didn't pose much of an issue on my iDevices as store and other apple services continued to work fine. However, ever since iOS 6 my iDevices cannot keep connection to my WiFi active. After connecting these try to access this "wispr" url of Apple and keep failing.
Luckily I have alternate net connection for my VoIP line. I tried switching my main router with this connection and all my iDevices work fine. But if I switch back to my regular net connection, the same problem starts occurring. This never happened to under iOS 5.x, only with iOS 6.
So my question is, does apple/iDevices need to access this URL always or just once for saved WiFi connection?
Thank you for the sensible critique. Me & my neighbour were preparing to do some research about that. We got a good book on that matter from our local library and most books where not as influensive as your information. I am very glad to see such informat
I am not in favor of this new exam pattern.Its totally an injustice to the regional board aspirants.Its a well known fact that CBSE's marking system is comparatively easier than other regional boards.So,definitely CBSE candidates will score more in ISEET
This so called feature is a problem at Wi-Fi HotSpots, wherein the user receives username and password via sms after registering themselves at captive portal. Once you switch the App from Safari to Messages to view your username and password the Wi-Fi gets disconnected and you again have to connect to the Wi-Fi. The Safari opened captive portal should have been retained while switching to Messages.
UPDATED URLs for WISPr target with Apple iOS 7.
Updated URLs for WISPr on Apple iOS 7 - http://www.cadinc.com/why-your-apple-ios-7-device-wont-connect-to-the-wifi-network
Post a Comment