[squid-users] debug skype ssl_bump numeric ips to be spliced

[Amos Jeffries]

On 15/10/2015 1:00 a.m., Marko Cupać wrote:
> Hi,
> 
> I read this interesting thread:
> http://squid-web-proxy-cache.1019090.n4.nabble.com/Skype-SSL-is-incompatible-with-OpenSSL-td4665803.html
> 
> And from what I read, I'd assume those entries in cache.log ...
> 
> 2015/10/14 13:44:51 kid1| Error negotiating SSL on FD 144: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (1/-1/0)
> 2015/10/14 13:45:17 kid1| Error negotiating SSL on FD 118: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (1/-1/0)
> 2015/10/14 13:45:17 kid1| Error negotiating SSL connection on FD 114: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate (1/0)
> 
> ... are caused by skype clients, or other clients that use port 443 for
> non-ssl traffic.

... or they are servers using invalid certificates

.. or they are servers using TLS extensions your library does not
understand how to deal with,

... or they are servers with revoked certificates

... or they are servers using a TSL certificate version your library has
been told not to accept

All those lines imply is a certificate verify problem inside the SSL
library.

Also note that the FD numbers are different, meaning each line is a
completely different TCP connection. The only thing they have in common
is that they are errors.


> 
> My ssl_bump setup is as follows:
> 
> acl splice_ips dst "/usr/local/etc/squid/splice_ips"
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump splice splice_ips
> ssl_bump bump all
> 
> Is there a way to increase verbosity of cache.log in a way that I get
> more information about this? I guess I am mostly interested in remote
> IP addresses so I can add them to splice_ips ACL.

You could use "debug_options 17,3". It produces a line that may be
prefixed "FwdState::connectDone" on successful server TCP connection
setup just prior to TLS initiation.

Or you could try out Squid-4. Which has automatic bypass for non-HTTPS
traffic and will resolve the confusion over whether it was actually
non-HTTPS or just a broken certificate.


Your logic is based on a flawed assumption though. Squid is a proxy.
Which means its very purpose is to select the best server from a whole
set to provide an answer for the bumped request.

Failure to perform TLS to connect to one server for a domain does not
means all IPs for that domain are bad. Squid will simply try other
alternative IPs or servers until one succeeds or there are no more
usable destinations.

Amos