Hi jay, If I am not mistaken dstdom_regex is matched against the *contents* of HTTP/HTTPS request - it means if first needs to be bumped. So it will never work in your case... You need to know not ssl bump traffic before looking into its contents - the only acl that domes to mind is "dst" - i.e. ip address of the remote server. So something like ssl_bump deny your_skype_ip_acl. But I may be mistaken, hopefully some one on the list will correct me if so. Raf ________________________________________ From: Jay Jimenez <jay@xxxxxxxxxxxxxxx> Sent: Thursday, May 8, 2014 10:21 AM To: squid-users@xxxxxxxxxxxxxxx Subject: Re: Skype SSL is incompatible with OpenSSL Hi Raf, As stated on my previous emal, I tried dstdom_regex to match all numeric IP addresses and it didn't help 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 Jay On Thu, May 8, 2014 at 3:48 PM, Rafael Akchurin <rafael.akchurin@xxxxxxxxxxxx> wrote: > 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@xxxxxxxxxxxxxxx> > Sent: Thursday, May 8, 2014 5:49 AM > To: squid-users@xxxxxxxxxxxxxxx > Subject: Re: 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@xxxxxxxxxxxxxxx> 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 >> >> >>
