[squid-users] Skype bypass using ssl_bump peek

[Alex Rousskov]

On 12/12/2014 02:31 AM, Yu-Hsuan Liao wrote:

> I'm trying to using Squid 3.5's new feature peek-and-splice to bypass
> Skype connection
> I'm a little confused about ssl_bump steps,
> the wiki says that
> 
> peek Receive client (step SslBump1) or server (step SslBump2)
> certificate while preserving the possibility of splicing the
> connection.


> My question is: does ssl_bump make decision to bump or splice connection
> when Squid gets the ServerHello message?

Squid makes the final decision to bump (or splice) the connection when
the first ssl_bump bump (or ssl_bump splice) rule matches. Whether that
final rule matches during step1, step2, or step3 depends on how you
write your ssl_bump configuration (and on traffic).


The peek/stare actions are for receiving information from client and
server. Due to how SSL is designed, these actions usually have side
effects as detailed on the wiki page: peeking usually implies eventual
splicing and staring usually implies eventual bumping. Thus, you have to
be careful how you get the information you need.


> cos I found that Skype voice connection is first
> 
> 1. client send Clien tHello
> 2. server send Server Hello
> 
> then began the skype data payload transmit(non-SSL format, not the
> rest SSL handshake)
> 
> so that I still got the "Error negotiating SSL connection on FD"
> message in cache.log
> 
> Does peek-and-splice function cover above situation, or I just
> misunderstand the usage of ssl_bump peek?

If Skype client and server Hello information is standard (supported by
OpenSSL), then splicing connection should work at step1 or step2. For
example, the following configurations should work:

  ssl_bump splice isSkype
  ...

or

  ssl_bump peek all
  ssl_bump splice isSkype
  ...

where "isSkype" is your custom ACL that matches Skype traffic. It is
difficult to write such an ACL, as discussed below.


If those Hello exchanges are not supported by OpenSSL, then you must
splice at step1 without peeking:

  ssl_bump splice isSkype
  ...



> acl skype_list dstdomain "skype_list"
> ssl_bump peek skype_list
> ssl_bump stare all

This configuration will most likely not work because you are staring
(which usually implies eventual bumping) at step2. You cannot bump a
non-SSL connection. Moreover, I would be concerned about dstdomain
matching at step1 where Squid has access to CONNECT (forward proxy) or
TCP-level (intercepting proxy) information only and may be forced to do
a reverse DNS lookup.


The proper way to handle all this complexity is via automatic
non-HTTP/non-SSL traffic bypass rather than hand-written rules that try
to identify such traffic on a case-by-case basis. Unfortunately, the
corresponding Squid feature got stuck in Squid Project review for a few
months now. We have not given up on it though.


HTH,

Alex.