Re: [squid-users] Skype SSL is incompatible with OpenSSL

Hi Marcus and Pawel,

Thank you very much for all the help. There is only 1 conclusion here.
We cannot ssl bump Skype and therefore must be excluded.

 I can't find any solution to exclude Skype on my squid.conf file. I
have tried to exclude ^skype browser and/or exclude .microsoft.com,
.live.com and numeric IP addresses but no luck. Squid is always ssl
bumping Skype traffic.

This doesn't work for me...

acl numeric_IPs dstdom_regex
^(([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)|(\[([0-9af]+)?:([0-9af:]+)?:([0-9af]+)?\])):443
acl Skype_UA browser ^skype
acl broken dstdomain .skype.com .microsoft.com .live.com

ssl_bump none numeric_IPs
ssl_bump none Skype_UA
ssl_bump none broken
ssl_bump server-first all

---------------------------

As a workaround, I just ssl bump numerous https websites only that are
not allowed in the company like .facebook.com, .twitter.com,
.linkedin.com, etc.

acl sslsites dstdomain .facebook.com .twitter.com .linkedin.com
ssl_bump server-first sslsites

We don't have any video conferencing alternative than skype that's
why it's allowed in the company.

Regards,
Jay

On Thu, May 8, 2014 at 5:27 AM, Marcus Kool <marcus.kool_at_urlfilterdb.com> wrote:
>
>
> On 05/07/2014 10:55 AM, Pawel Mojski wrote:
>>
>> W dniu 2014-05-07 15:40, Marcus Kool pisze:
>>
>> [...]
>>>>
>>>> certificate chain:
>>>> Certificate chain
>>>> 0 s:/CN=*.gateway.messenger.live.com
>>>> i:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=MSIT Machine Auth CA 2
>>>> 1 s:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=MSIT Machine Auth CA 2
>>>> i:/CN=Microsoft Internet Authority
>>>> 2 s:/CN=Microsoft Internet Authority
>>>> i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
>>>
>>>
>>> There is a misunderstanding here.
>>> Skype does not use SSL, it only uses port 443 which is commonly used
>>> by SSL,
>>> but skype knows that there is a proxy and uses the CONNECT method to
>>> get a tunnel from Squid.
>>> Squid (without SSL-bump) than simply "tunnels" (i.e. passes everything
>>> from the client to the server and back).
>>> But _with_ ssl-bump Squid assumes that the CONNECT is for a SSL
>>> connection and this assumption is wrong.
>>
>>
>> Sorry, but you are wrong. Skype *IS* using ssl like you can see on
>> example above.
>> That example was made on openssl -connect
>> ip.from.sniffing.my.own.skype:443 and as you can see, it's a proper SSL
>> connection.
>> But, no one of us have any idea what is the native protocol, all what we
>> can figure out it is SSL connection. This is some kind of protocol over
>> SSL.
>
>
> Skype starts connecting to a node so a Skype node is a critical component.
> Lets look at a Skype node at 157.55.235.144 :
> openssl s_client -connect 157.55.235.144:443
> CONNECTED(00000003)
> 139691491997512:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
> protocol:s23_clnt.c:766:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 7 bytes and written 263 bytes
>
> There is no SSL. So at least part of Skype uses port 443 for non-SSL
> traffic.
> This observation matches the error messages in the original post:
>
> 2014/05/02 18:18:11 kid1| clientNegotiateSSL: Error negotiating SSL
> connection on FD 166: error:1408F10B:SSL
> so also Squid cannot negotiate an SSL connection because the server uses an
> other protocol.
>
> The design of Squid ssl-bump assumes that a CONNECT to a server always has
> an SSL-based communication channel
> and therefore any software that uses non-SSL traffic on port 443 fails to
> work with ssl-bump.
>
> Marcus
>
>
>
Received on Thu May 08 2014 - 03:49:35 MDT