On 8/04/2014 11:34 a.m., Dan Charlesworth wrote:
> 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.
>
FYI: for tracking just usage amounts it is not a huge problem. The
CONNECT are still logged along with the transferred data sizes. Just a
little bit later than the requests inside the tunnel would have been.
It is a big problem for AV scanning and site restrictions security
blocks. But then in those cases the pinning is being slightly helpful by
blocking the sites usage without wasting Squid's processing time.
Amos
> 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 wrote:
>
>> On Apr 6, 2014, at 11:58 PM, Dan Charlesworth 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
>
Received on Tue Apr 08 2014 - 00:06:03 MDT
This archive was generated by hypermail 2.2.0 : Tue Apr 08 2014 - 12:00:05 MDT