iOS7 Issues on iPhone, iPad and so on

Hi guys,
I received an information this morning, that Apple changed their way to detect "captive Portals". Captive portals is the technique called i.e. hotels are using to get login-credentials from their visitors. While the CaptivePortal is active, the iOs device recognizes, that there is no internet connection and brings some sort of tiny brower - sometimes login credentials.
All other access to the Wifi Network is restricted up to the point where iOS detects that it has internet, in the common tehnique, when the user+password was given to the hotel splash screen or in the iOS window (which can PopUp).
This technique is called CaptiveNetworkAssistent (CNA)

On PirateBox, we don't want this tiny browser and this login window for several reasons. To overcome this, we are faking the answer for the iOS device and it assumes there is internet.

In one point of view, we are using a security issue, because all App starts to try to send their data. In the other point of view, we can't overcome this to get a good user-experience.

With the release of iOS7, Apple changed the way from getting one particular file to asking several domains (not the piratebox-issue) and try to get -something-.

We have to find out what this something is and fake the request. Up to this point, you can only overcome the connection window if you run in some sort of timeout. Jason Griffey, the LibraryBox Project, is working on a small howto.

Because I don't have any Apple-Mobile-Device I can't test it for myself. So if you have any news about it, ideas or fixes- I would be glad to hear about it.

edit: Jason Griffey made a very good description on his kickstart-Update how it looks like

edit2: For PirateBox I released an updated version of the image files, that contains the fix: see forum thread


best regards
Matthias



Edited 2 time(s). Last edit at 09/28/2013 05:57PM by Matthias.

Yes this did happen, I noticed it today on my iPad. It is a real problem.

According to what I've seen, the iOS7 device seeks Success.html from as many as 200 Apple websites.

If it cannot connect to those sites, it shows the tiny pseudobrowser (Log In).

It is possible, at least sometimes, to tap Cancel and see an option 'Use Without Internet'. But this merely returns the user to Settings. It does not allow the user to immediately browse without Internet. To do that, the user will have to exit Settings and return to the Safari browser.

It is confusing and I think many users will just give up.

It has been stated that the User Agent (UA) sent by the device remains the same (CaptiveNetworkSupport). Apparently, some captive portal vendors are using this UA to bypass the problem. How to do that?

we need to find out which request or event triggers the offline button.

the success.html would be delivered on any requested domain, but it seems they changed the path and/or content.

maybe they hard coded some IP or DNS server in iOS configuration.

can you trace it with your iPad , a notebook and tcpdump what happens over WiFi? full packet trace would be useful for me. (don't publish the link to that file in the thread)

thanks for feedback!

Matthias

Quick Linkdump, which I can't read now (time)


[forum.mikrotik.com] MikroTik - Forums ; Ask for help

[supportforums.cisco.com] - Important Captive portal bypass changes needed for iOS 7

[supportforums.cisco.com]

More linkdump...this link is reporting that they only added two URLs to the check:

[www.cadincweb.com]

Although I've seen others that seem to indicate that they may be using more.

So far I have observed automatic connection attempts to these:

captive.apple.com
ibook.info
appleiphonecell.com
airport.us
thinkdifferent.us
itools.info

Hi everyone,
thank your for your patiance and work.
Most helpful was Jasons link, but it confuses me even more. Why?

As you can see, the domain is different now, but as far as we know, PirateBox resolves every domain down to 192.168.1.1 which hits the current running webserver.

Since 0.3 (?) we are delivering the requested success.html

see on [github.com]

So only this can't be the whole issue, because it should work.

(10 Minutes later)

Could it be, that they request ONLY the f*cking URL without path?

Can someone please test the following lines...??

Add those in
/opt/piratebox/conf/lighttpd/lighttpd.conf

$HTTP["useragent"] =~ "CaptiveNetworkSupport" {
        server.document-root =  "/opt/piratebox/www/library/test/"
        index-file.names        = ( "success.html" )
        dir-listing.activate    = "disable"
        server.error-handler-404 = "/success.html"
}

That should work for iOS7 and iOS6 devices.

edit: fixed copy & paste bug in document-root

Matthias



Edited 1 time(s). Last edit at 09/26/2013 07:44PM by Matthias.

Quote
Matthias
Add those in
/opt/piratebox/conf/lighttpd/lighttpd.conf

$HTTP["useragent"] =~ "CaptiveNetworkSupport" {
        server.document-root =  "/opt/piratebox/www/library/test/"
        index-file.names        = ( "success.html" )
        dir-listing.activate    = "disable"
        server.error-handler-404 = "/success.html"
}

Worked for me. ios7/iphone4. Thanks.

@lostlogan are you quite sure? You did not get a "Log In" screen ever, even after you cleared the Safari cache and cookies?

@zhenqi cleared cache and cookies just in case. Connected to it off and on for several minutes with no login screen. Redirect works just fine in safari and chrome.

Some URL examples- Notice they don't contain success.html, but they do return "Success".

www.thinkdifferent.us/zCirqCIQx3/apmdlBYUT7.html
www.itools.info/knCIewcX/JWMDGhwL/Lry9yOtU/4expJM1Q/MrmGQqKC.html
www.ibook.info/NtCKVXRB2Gef5kB/EWnDWQ8YmPTY26M/949GccKzGNVvuiC/eOhWjmMe64P5WZA.html
captive.apple.com/2vutrd7tNpu/Gw1lx9Qhg3W/eJacmFcFKDK/jCsOvXXgmSt/VHGrqk4fHD8.html

These were all used by the same iPad on the same day. Very weird. Does anyone know why Apple is trying to make this a moving target?

=Abe

@Abe - How did you capture those URLs?

@Matthias - I am trying to test HTTP user agent with PHP. So far no luck, CaptiveNetworkSupport is not reported as the user agent in iOS7:

Language: PHP
$hua = ($_SERVER[';HTTP_USER_AGENT';]);
 
if(false !== stripos($hua, ';CaptiveNetworkSupport';)){
echo "Has CNS.";
}
else {echo "NO CNS.";}

The $hua is reporting "Mozilla/5.0 (iPad ... etc. etc.)

Hi,
I would suggest using a RegexMatch, but as far as I understand that PHP code, this work too.

But I think you maybe misunderstood a few things about what is happing while logging into a wifi network with an iOS system.
During login to wifi network, the OperatingSystem is doing the wispr requests, and not by a browser. Because of this:

a) you won't the "see" the result of that request on your mobile device
b) You can't redo the request with a browser.

So your test-output won't come back to your iPad-"screen" and if you want too see a request result, you need to write the output of your PHP into the error-log or into a local file (take care of concurrent write access).

If you want to display something different for iOS USERs (not the captive portal requests), then you should figure out a different string which fits.

I wasn't aware of the random-urls done by iOS7, but I suggested, that might be the case - and I wanted to support future requests.
@zhenqi you can capture those requests, if you enable the accesslog in your lighttpd server.

regards Matthias

@zhenqui - I am running an internet filter for a school district that is in the middle of a 1 to 1 iPad deployment to students. On the filter, I have to allow the success.html page(s) without login or the iPads will just disconnect from the wifi, making it unusable.

Before the release of iOS7, simply allowing the iPads to hit apple.com (before requiring a login) was working just fine. After the release of iOS7, we started having issues connecting to wireless - EVEN ON iOS6 DEVICES that were working fine before. I suspect Apple updated an online list that is used for captive portal checking.

I was able to use our internet filter (iBoss) logs to capture the URLs that were being blocked- and those sites keep changing. At one point, I thought I had it covered by allowing access without login to 17.0.0.0/8 (Apple IP Range). That worked for a day, but then Apple starting using the www versions of the "Success" pages, which are on Akamai, which I can't allow without login.

The URLs I provided above return "Success" without all of the randomized stuff after the hostname. (Is apple trying to track wifi usage? Is the iPad MAC address encoded in those randomized URLs?)

All of the following produce "Success":

www.ibook.info
www.itools.info
www.airport.us
www.thinkdifferent.us
captive.apple.com
www.appleiphonecell.com
www.apple.com/library/test/success.html

If anyone can explain Apple's reasoning behind this craziness, I would love to hear it.

=Abe

Hi,
yes that is a really good question. Maybe they try to improve the robustness of the internet detection, but it makes it even more worse.
I think the only useful way is to make a deep package inspection to find out the user agent... but that is not the way to go.

I have currently no useful idea how to overcome this crappy thing :/

For PirateBox I released an updated version of the image files, that contains the fix: see forum thread

So far Matthias

The only option is to disable the auto login option in setting.

you need to bypass the domain , captive.apple.com from the pre authentication channel on your captive portal device and you are done!

I'm not a Pirate Box user, and I apologize for the intrusion. I'm just having issues and I hope someone will have mercy on me and try to help since this thread seems to be the definitive source for information regarding how iOS7 has changed the way Captive Portal detection has changed.

I'm using a Pi as a captive portal, running lighttpd as the webserver. My issue is that the splash page only comes up on OS X - not on iOS. How would I alter the code below to force the captive network assistant on iOS to always open the page in the mini-browser? Do I need to include a success.html (or maybe a failure.html, since I want it to fail and bring up the page) in my www directory?

Any help is very much appreciated!!

> $HTTP["useragent"] =~ "CaptiveNetworkSupport" {
> server.document-root =
> "/opt/piratebox/www/library/test/"
> index-file.names = ( "success.html"
> )
> dir-listing.activate = "disable"
> server.error-handler-404 =
> "/success.html"
> }

@jcorelitz:

I am also not using PirateBox. I am using a Raspberry Pi with lighttpd as an offline web server (not connected to the Internet). It serves web pages by Wi-Fi to connected client devices.

But in your case, if you do want the Log In screen to appear on iOS, you should not need the library/test directory or the special lighttpd configuration that is described in this message thread. Just configure lighttpd as normal.

For example, 404 errors should go to whatever your normal error page is. And you don't need to look for a particular user agent.

iOS will show the Log In screen if it can't connect to the Internet and hit the Apple sites. That is the normal behavior when connected to a captive portal.



Edited 1 time(s). Last edit at 11/03/2013 10:38PM by zhenqi.

zhenqi,

thanks so much for your reply. our setups sound very similar. i have lighttpd configured normally. the splash page comes up as expected on a mac, but i don't get anything on an iOS device. i'm wondering how the detection differs on the two systems and what makes it work on one but not the other. the page is a simple redirect to a local server:

<meta HTTP-EQUIV="REFRESH" content="0; url=http://computer.local:8084/document.htm">

any ideas?

Hi jcorelitz,

I have similar setup to urs and when i try to access the wifi from my iphone, I dont see the success page of CNA. I am still able to connect to internet and browse. The page comes up on the mac and i have the issue only on ipad/iphone with IOS7. Any ideas?

thanks
ramya

Hi zhenqi

this is in regards to the post where u said that u are seeing Mozilla/5.0 (iPad ... etc. etc.) as the user-agent. I am seeing the same as well. Did you figure out why? from what i have been reading, i should be seeing CaptiveNetworkSupport as the user agent.

thanks
ramya

I saw both. Here is an example, where the iOS tries to load the random path and file from captive.apple.com.

In the first attempt it sends the Captive Network Support user agent and in the second, it sends a conventional browser user agent.

[RequestWorker #1] 01.01.70 00:11:35 301 192.168.2.31 GET /tCgtUPGlI1X/nPEF69LXjzA/modf6rMkNjT.html HTTP/1.0 on vHost default (via captive.apple.com) - CaptiveNetworkSupport-277 wispr

[RequestWorker #2] 01.01.70 00:11:36 301 192.168.2.31 GET /tCgtUPGlI1X/nPEF69LXjzA/modf6rMkNjT.html HTTP/1.1 on vHost default (via captive.apple.com) - Mozilla/5.0 (iPad; CPU OS 7_0_2 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Mobile/11A501

Anyone have any updates on urls or hosts?

This is turning out to be a huge PITA.

drahst Wrote:
-------------------------------------------------------
> Anyone have any updates on urls or hosts?

The URLs are random and the hosts change. But "CaptiveNetworkSupport" is consistent. I have not had a problem with this since implementing Matthias' configuration in message 8910.

Add those in
/opt/piratebox/conf/lighttpd/lighttpd.conf

$HTTP["host"] =~ "^(appleiphonecell.com|captive.apple.com|www.itools.info|www.ibook.info|www.aiport.us|www.thinkdifferent.us|www.apple.com)" {
server.document-root = "/www/library/test/"
index-file.names = ( "success.html" )
dir-listing.activate = "disable"
server.error-handler-404 = "/success.html"
#accesslog.filename = "/var/log/lighttpd/apple-access.log"
#server.errorlog = "/var/log/lighttpd/apple-error.log"
url.rewrite = (
"^/(.*/)" => "/success.html",
)
}


Tested on iOS6 & iOS7