Thanks, Guy. I’m almost tempted to just ssl_bump none for 23.0.0.0/12, but I’m sure that would lead to all sorts of annoyances for clients who are tracking users download usage etc. I’d appreciate if you could share your list of IP addresses, might be useful for us. Dan On 7 Apr 2014, at 11:23 pm, Guy Helmer <ghelmer@xxxxxxxxxxxxxxxxxxx> wrote: > On Apr 6, 2014, at 11:58 PM, Dan Charlesworth <dan@xxxxxxxxxxx> wrote: > >> This somewhat vague error comes up with relative frequency from iOS apps when browsing via our Squid 3.4.4 intercepting proxy which is performing server-first SSL Bumping. >> >> The requests in question don’t make it as far as the access log, but with debug_options 28,3 26,3, the dst IP can be identified and allowed through with ssl_bump none. >> >> The device trusts Squid's CA, but apparently that’s not enough for the Twitter iOS app and certain Akamai requests that App Store updates use. >> >> Can anyone suggest how one might debug this further? Or just an idea of why the client might be closing the SSL connection in certain cases? >> >> Thanks! >> >> > > I suspect that the Twitter app is using certificate pinning to prevent man-in-the-middle decryption: https://dev.twitter.com/docs/security/using-ssl > > IIRC, I have had some difficulty tracking down or obtaining intermediate certs that Akamai uses. I ended up whitelisting many Akamai IP addresses from SSL interception on my test network. > > Guy
