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
