Re: [squid-users] Broken Apple devices - repeated 407s

On 29/04/2014 9:42 p.m., Steve Hill wrote:
>
> Apple devices seem to be pretty broken when it comes to handling
> authenticated proxies. However, sometimes I see behaviour that is so
> broken that it could almost be considered a DoS attack: Devices that
> make a request, get a 407 back from the proxy and immediately make the
> same request again, still with no authentication credentials - the proxy
> returns a 407, of course, and the client requests again... repeatedly,
> with no kind of a back-off timer, going on for hours on end. For example:
>
> 28/Apr/2014:07:45:36.194 0 10.203.1.18 TCP_DENIED/407 4660 CONNECT
> p02-ubiquity.icloud.com:443 - HIER_NONE/- text/html "ubd/289
> CFNetwork/673.4 Darwin/13.1.0 (x86_64) (Macmini5%2C1)"
> 28/Apr/2014:07:45:36.205 0 10.203.1.18 TCP_DENIED/407 4660 CONNECT
> p02-ubiquity.icloud.com:443 - HIER_NONE/- text/html "ubd/289
> CFNetwork/673.4 Darwin/13.1.0 (x86_64) (Macmini5%2C1)"
> 28/Apr/2014:07:45:36.215 0 10.203.1.18 TCP_DENIED/407 4660 CONNECT
> p02-ubiquity.icloud.com:443 - HIER_NONE/- text/html "ubd/289
> CFNetwork/673.4 Darwin/13.1.0 (x86_64) (Macmini5%2C1)"
>
> (continues like that with about 100ms between requests).
>
> And other similar requests:
>
> 28/Apr/2014:07:45:28.793 0 10.203.1.18 TCP_DENIED/407 4649 CONNECT
> keyvalueservice.icloud.com:443 - HIER_NONE/- text/html
> "SyncedDefaults/91.30 (Mac OS X 10.9.2 (13C1021))"
> 28/Apr/2014:07:45:58.358 0 10.203.1.18 TCP_DENIED/407 4630 CONNECT
> p02-caldav.icloud.com:443 - HIER_NONE/- text/html "Mac_OS_X/10.9.2
> (13C1021) CalendarAgent/176"
> 28/Apr/2014:07:45:59.114 0 10.203.1.18 TCP_DENIED/407 4612 CONNECT
> p02-bookmarks.icloud.com:443 - HIER_NONE/- text/html "CoreDAV/229.6
> (13C1021)"
>
> etc... It happens from both OS X and iOS devices every so often
> (presumably flattens the iphone battery pretty quickly!)
>
> Clearly this is a bug in Apple's software (which I have reported, but
> they seem uninterested in fixing it*), but I'm wondering if anyone else
> has observed this behaviour and come up with any good ideas to mitigate
> it on the proxy side?

A Greylist external ACL helper might be the perfect thing you need for this.

The idea is to add a significant delay into that cycle. The helper can
either add several seconds in a fixed amount or track how often the
particular client has been tested and ramp up the delay each time it
repeats (penalizing misbehaving clients over working ones). Used in the
reply access controls it can check for the 407 status and hold back the
reply delivery indefinitely.

The config is something like this:

 acl icloud dstdomain .icloud.com
 acl authResponse http_status 407

 external_acl_type delay ttl=0 negative_ttl=0 cache=0 %SRC /helper/path
 acl delay external delay

 http_reply_access deny CONNECT icloud authResponse delay

The extra ACLs are there to prevent the delay helper being used on other
traffic which is working fine.

Amos
Received on Tue Apr 29 2014 - 12:50:34 MDT