iOS Global HTTP Proxy Authentication Error.

Hi MacMan,

We ran into the same exact problem with a proxy server getting over run. I set up a squid box with authentication and ran into the same problem you stated.

Icreated a whitelist of sites that I didn't require authentication for. To find these sites I just tailed the squid access log and looked for DENIED messages while testing one machine. It is by no means perfect but it appears to be working.

The sites that I needed to allow seemed to be mainly things that such as google-analytics, and ad domains.

With this in place I tried to tighten up security by putting in a browser acl to only allow specific user agents, and downloaded a list of country ip addresses. I only allow connections from the countries I want and our internal networks.

I would love to hear how other people have worked around these sort of problems. We are currently evaluating content filters that provide proxy servers with authentiation specifically for iPads. I can write up my set up if that would help.

I should have time to write up and send my config this evening.

Here are the relevant parts of my squid config and some examples of what are in the acl files. I downloaded the ip list from ipdeny.com. As it was, the end of line character wasn’t correct and I had to correct that before squid would read it correctly. I just copied and pasted it into a new file to correct it.

I don’t know if this is the best way to approach this, and I am sure there are some problems with it currently. I am continuing to tweak it as things come up. With all allowed domains the number of authentication pop ups I received were drastically reduced. Looking it over I already see that rearranging the allow and deny rules would be of benefit for me.

I am also using fail2ban on this server with the squid configuration file from http://www.fail2ban.org/wiki/index.php/Fail2ban:Community_Portal#Squid_filter. This does eventually block someone who gets enough TCP_DENIED 407 messages. I also had modified it to include 403 messages with some success. The amount of blocks we receive from blocking ads I would get devices locked out unintentionally but increasing the number of attempts seems to have resolved this.

squid.conf

## ACL for blocked files originally just .exe

acl blockedfiles urlpath_regex "/etc/squid/blocked.files.acl"

## ACL for blockedomains

acl blockeddomain dstdomain "/etc/squid/blocked.domains.acl"

## ACL for allowedomains

acl alloweddomain dstdomain "/etc/squid/allowed.domains.acl"

## ACL for allowed user agents

acl allowedbrowser browser "/etc/squid/allowed.browser.acl"

##Acl for Users requiring proxy authenticiation

acl password proxy_auth REQUIRED

## United States External Allowed

acl external src "/etc/squid/us.zone"

## Internal Networks

acl internal src "/etc/squid/local.zone"

##Allow access from the admwired network defined above without authentication

http_access allow internal

##Block the following based on acl defined above

http_access allow alloweddomain

http_access deny blockedfiles

http_access deny blockeddomain

http_access deny !allowedbrowser

##Allow access from all networks but require authentication

http_access deny !password

http_access allow external password

#And finally deny all other access to this proxy

http_access deny all

allowed.browser.acl

^.*iPad.*$

blocked.files.acl

\.[Ee][Xx][Ee]$

us.zone

103.246.248.0/24

113.29.0.0/17

163.60.0.0/16

192.103.43.0/24

202.72.96.0/20

203.144.48.0/20

203.187.128.0/19

3.0.0.0/8

4.0.0.0/8

6.0.0.0/8

7.0.0.0/8

8.0.0.0/8

9.0.0.0/8

11.0.0.0/8

12.0.0.0/8

13.0.0.0/8

etc…..

allowed.domains.acl

.apple.com

.mzstatic.com

.appextras.com

.google.com

.facebook.com

.gstatic.com

.amazonaws.com

.bloxcms.com

.lyveapps.com

.doubleclick.net

.googleusercontent.com

.2mdn.net

.admob.com

.mopub.com

.googletagservices.com

.quantserve.com

.exelator.com

.facebook.net

.google-analytics.com

.googleadservices.com

.scorecardresearch.com

.qwapi.com

.appspot.com

.mobclix.com

.crashlytics.com

.mm.bing.net

.verisign.com

plus some more for specific ipad apps that I had to allow

We are having the exact same issue. We are deploying iPhones and iPads using Airwatch and configuring the Global HTTP Proxy setting with authentication. We have a Barracuda web filter setup and block unauthenticated traffic. It appears that iOS is not passing the credentials in anything other than Safari. We were taking the same approach as above but it is getting ridiculous. Apple needs to fix their authentication implementation.

If somebody has a fix or workaround for these issues, please help. We need to be able to track our users for legal and compliance reasons, and if they are not authenticating obviously it's pretty hard to know who is who.

BenK944,

Are you passing out the authentication with the global proxy settings or are you just requiring it? I have not been passing it out with the global proxy settings. When using the device I can be prompted for authentication over and over again until I allow a specific domain without authentication. I experience the problem with no authentication being passed in Safari as well on occassion. You can just click on cancel for the authentication prompt and continue on, but it is definately an annoyance.

I agree that this needs to be resolved. Adding the global proxy option gave us a chance to filter our devices when they are outside of our network. Its too bad that there seem to be so many problems with trying to use it.

Robert600,

We are passing out the authentication credentials with each device, and we are blocking unauthenticated requests on the proxy itself. At first it seemed to work OK, but then we noticed whenever we went to an HTTPS site, we got the prompt for authentication. It didn't matter what was entered, it didn't work. So, Barracuda allows proxy authentication exemption using a regular expression or IP address. We exempted all https as well as Apple's IP range and our own. This seemed to resolve the issue at the time. We just now started testing app rollout and the problem came back. For example, we just loaded out the Weather Channel app and it appears to be constantly trying to get updates. When it attempts to update, the user gets the authentication prompt.

Obviously, I can go and make another exception, but where does it end?!

One thing we did notice is if the user is browsing with Safari, the iPhone authenticates fine with the Barracuda and at that point the other apps work as well. The reason is that the Barracuda creates a "browsing session" if you will, that appears to be tied to the IP address of the device, so it doesn't have to reauthenticate every single request. The problem is if the browser hasn't been used in a few hours (at night for example), that session times out. The app begins requesting data at some random hour in the night and when the user wakes up they have authentication prompts waiting for them.

Global HTTP proxy appears to be not so Global. Basically the only thing I can see that it authenticates is HTTP traffic in Safari. App traffic and HTTPS traffic appear to not get any credentials sent with the request.

At this point, I'm not sure what we are going to do.

I just stumbled on this thread. I've been using Global HTTP proxy for about the last year to filter web traffic from my kids iPhones through a Dansguardian content filter and have experienced the same issues described here. My initial solution was also the same as what has been described here: add individual ACL rules to allow access to specific domains for which the iPhone fails to provide authentication data. It's a tireless process, and of course, as the list grows, so too does the list of sites that anyone can access through my proxy. Eventually I stopped adding rules and just let my kids deal with cancelling the constant prompts. It results in intermittent failures in some apps, but in a lot of cases, web content still loads (minus whatever content prompted for the password).

I recently moved my proxy server to the cloud, and in the process of reconfiguring, I also upgraded to Apple Configurator 1.4 and iOS 7. I was very dissapointed to find this is still an issue after the upgrade. However, I did manage to find an alternate solution to this problem that works much better in my case. Thought I'd share that here.

I removed all of the domain-specific ACL rules, and instead added the following line to my Squid config file:

authenticate_ip_shortcircuit_ttl 8 hours

This statement effectively tells squid that once a user has succesfully authenticated from a specfic IP address, allow access from that same IP address for the next 8 hours without re-authentiating. With this change, there's a possiblity the iPhone will prompt for a password once every 8 hours or when the phones IP address changes, but the constant authentication dialogs tied to specific urls are gone.

From a security stand-point, if Sprint gives my kids phone a new IP address and another Sprint user gets assigned the original IP address, in theory that user could access the proxy until the end of the current 8 hour period...which is effectively a non-issue, as that random user would likely have no knowledge of (or likely any desire to access) the proxy. The proxy remains secure from general, unauthorized access. I realize this solution may not be ideal in a school or business environment, especially if IP lease times are short, but thought I'd share it anyway. The real solution, of course, would be for Apple to just fix the problem.

This directive " authenticate_ip_shortcircuit_ttl 8 hours " is outdated for squid 3