[squid-users] Skype+intercept+ssl_bump

[Alex Rousskov]

On 07/18/2016 05:03 PM, Alex Rousskov wrote:
> On 07/18/2016 01:27 AM, Amos Jeffries wrote:
>> On 15/07/2016 10:38 p.m., Evgeniy Kononov wrote:
>>> With this setup I have problem with group chats, calls and attachments in messages.
> 
>> The problem is with identifying it in fairly reliable way from all the
>> other traffic. That is where we are currently all stuck.
> 
> I cannot offer a comprehensive solution for all Skype problems, but I
> can share an in-progress triage that we are doing for one particular
> problem related to Skype group chats. According to some of the logs I
> have seen, group chat uses MSNP(?) messages instead of HTTP. Squid fails
> to parse MSNP, as expected:
> 
>> RequestParser.cc(340) parse: Parse buf={length=68, data='CNT 1 CON 185
>>
>> <connect><ver>2</ver><agent><os>Windows</os><osVer>'}
>> RequestParser.cc(228) parseHttpVersionField: invalid request-line: not HTTP
> 
> 
> AFAICT, Squid then hits an on_unsupported_protocol bug: When deciding
> whether to tunnel an intercepted unsupported protocol, Squid never
> tunnels traffic on connections that have seen more than one HTTP request
> already. The intent behind that check is noble (if a connection started
> with a valid HTTP request, then it is probably an HTTP connection), but
> the actual result is unfortunate:
> 
> 1. Intercepted connections start with one or two fake SslBump CONNECT
> requests that are counted as "seen HTTP requests".
> 
> 2. The invalid HTTP request that we just failed to parse is also counted
> as a "seen HTTP request".
> 
> In the particular case I have seen, once Squid bumps the Skype
> connection and receives a non-HTTP MSNP request, the "seen requests"
> counter probably reaches 2, and the on_unsupported_protocol option is
> not checked.
> 
> 
> I am trying to come up with a use case that would justify the current
> request counting check. Would switching to a blind tunnel in the middle
> of an intercepted connection expose Squid (or its users) to any
> _additional_ risks compared to switching to a blind tunnel only when the
> bumped connection starts with an invalid HTTP request?


Update: The question still stands, but we now know more about what
happens if the on_unsupported_protocol bug (in code and/or
documentation, depending on how you look at it) discussed above is
fixed: Squid then starts tunneling traffic as it is told by the
on_unsupported_protocol directive, but forgets to use the existing
encrypted connection to the server and opens/uses a new Squid-to-server
unencrypted connection instead.

Thus, the patch I posted previously does not solve the known Skype
groups/MSNP problem -- it only exposes the next (and bigger!) obstacle
on the way to that solution.

We are working on supporting/fixing tunneling of bumped connections, but
feedback regarding request counting check question above is still welcomed.


Thank you,

Alex.