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?
<rant>
* Apple's bug reporting process seems to be:
1. I report a bug with lots of information regarding the OS version on
the device, how to replicate the problem, etc.
2. They sit on it for a few weeks before asking me to provide them with
lots of logs from the device itself, which generally I can't easily do
because I don't personally have the device.
3. I jump through the hoops and provide them with the information they
request.
4. They sit on the bug and never bother to respond or fix it.
So given that (3) involves me spending quite a bit of time getting hold
of a device and replicating the problem, even though I provided them
enough information to do this themselves, and it basically seems to be a
complete waste of my time since they then ignore the bug, I've largely
given up reporting them now... Which is a shame - I don't mind spending
time collecting debugging information if it's actually going to help get
the bug fixed, but with Apple this doesn't seem to happen.
</rant>
-- - Steve Hill Technical Director Opendium Limited http://www.opendium.com Direct contacts: Instant messager: xmpp:steve_at_opendium.com Email: steve_at_opendium.com Phone: sip:steve_at_opendium.com Sales / enquiries contacts: Email: sales_at_opendium.com Phone: +44-844-9791439 / sip:sales_at_opendium.com Support contacts: Email: support_at_opendium.com Phone: +44-844-4844916 / sip:support_at_opendium.comReceived on Tue Apr 29 2014 - 09:42:59 MDT
This archive was generated by hypermail 2.2.0 : Tue Apr 29 2014 - 12:00:07 MDT