On 19/03/2014 9:56 p.m., Tom Tom wrote: > Hi > > Using latest squid 3.4.4 with ssl_bump. > > With ssl_bump enabled, I receive an error in cache.log (and the > browser too) while opening the page > 'https://www.pubservice.com/Subnew2page.aspx?PC=LJ': > > fwdNegotiateSSL: Error negotiating SSL connection on FD 67: > error:00000000:lib(0):func(0):reason(0) (5/-1/104) > > I have found two workarounds: > 1) Find out, which encryption the SSL-connection is using (curl -s -v > -I -k "https://www.pubservice.com/Subnew2page.aspx?PC=LJ";) and search > for "SSL connection using RC4-SHA". > 1a) Define 'sslproxy_cipher RC4-SHA' in squid.conf and reload squid > > 2) Deny ssl_bump for the site mentioned above. #1 is very unsafe. RC4 and SHA1 are both very broken algorithms. > > Question: > What encryption types does squid allow per default in sslproxy_cipher? Squid leaves the default up to the library. Check your OpenSSL library versions documentation. > Why do I need to extend the sslproxy_cipher-directive in some > circumstandes? Because there are broken/obsolete servers out there still. The default ciphers your Squid box SSL library provides do not always overlap with the ciphers requested by servers your clients are visiting. Since it is requiring RC4-SHA be enabled I expect the server has an extremely outdated SSL library with a small set of broken ciphers (possibly even just the one) and your Squid is using a newer library with the broken ciphers disabled by default. > Why is this site not working with ssl_bump enabled and > the default "sslproxy_cipher"? ssl-bump decrypts the traffic, Squid is required to re-encrypt it before sending to the server. That is where the above all comes in. fwdNegotiateSSL is an error when forwarding the traffic to the server. Amos
