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

Hi Jay and others, If I am not mistaken based on your redirection description (transparent proxy) in order to get to the ACLs you described squid *first needs to SSL bump* the traffic to apply ACLs - so those ACLs will never exclude traffic from being SSL Bumped... One solution that comes to mind is to *not forward* traffic to those IPs you have in ACL (numeric_IPs) from your router to squid box. Of course you would need to keep up-to-date with the IP address changes and probably too much traffic will bypass proxy - but at least your Skype will start working... Raf ________________________________________ From: Jay Jimenez <jay_at_integralvox.com> Sent: Thursday, May 8, 2014 5:49 AM To: squid-users_at_squid-cache.org Subject: 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 - 07:48:45 MDT