[squid-users] Skype+intercept+ssl_bump

[Alex Rousskov]

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? If not, it is
trivial to remove the check as the attached patch illustrates.


Thank you,

Alex.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: IP-12900-tunnel-at-any-time-t1.patch
Type: text/x-diff
Size: 2837 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160718/91feb142/attachment.patch>