[squid-users] FW: squid tproxy ssl-bump and Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

[Amos Jeffries]

On 6/10/2016 8:46 p.m., Vieri wrote:
> Hi,
> 
> 
> 
> ----- Original Message -----
>> From: Amos Jeffries <squid3 at treenet.co.nz>
>>> Is it correct to assume at this point that the current openssl
>>> build on this system is "OK" as far as supporting "Win XP TLS 1.0
>>> ciphers to access at least google.com"?
>> 
>> Yes. The build is capable of it. That is one of 3 conditions that
>> must
> 
>> be met for it to work.> The other two being:
>> 
>> * whether it is enabled in the library config. - OpenSSL library
>> has its own conf file somewhere. - it is possible that curl and
>> other tools whose primary design purpose
> 
>> is communication (not testing) override the library normal defaults
>> for> their own use, or re-try certain things after failures. That
>> needs to be
> 
>> eliminated to be sure.> * that the squid.conf settings combine with
>> those library settings to
> 
>> cause it to be (or stay) enabled.[...] So far we can assume that it
>> is either a Squid bug relaying the
> 
>> available cipher list between the two remote endpoints. Or that the
>> set of ciphers available to Squid does not include the DES-CBC3-SHA
>> one.[...]
> 
>> The fact that the library can be
> 
>> configured independent of any application using it throws a rather
>> big
> 
>> spanner into the expected behaviour logics.
> [...]
>> So far your tests are showing that it is about a 50/50 chance of
>> being a bug in Squid versus a Squid/OpenSSL misconfiguration
>> somewhere.
> 
> 
> I don't know what a library configuration file is. OpenSSL has a CONF
> library/functions to read its own .cnf files. An application such as
> Squid can use these functions to read a conf file, or not.

Unless I'm totally confused there is a system-wide conf file that the
library can/does load on its own before all that.

> 
> I'm assuming that at compile time, both the openssl library and squid
> were built with most features. Is there a way to list available
> openssl ciphers from squid (like a squid command line tool)? As if
> Squid were to call an openssl library function to "list available
> ciphers",or something.

Unfortunately not. Squid (mostly) passes the squid.conf strings directly
to the library parser so that list the library produced should be what
Squid is _able_ to use. The detail to be careful of is whether
squid.conf contains any such strings that change the library defaults.

> 
>> To test that last detail you probably need to setup a normal
>> https_port with SSL and see if you can connect to it with TLSv1.0
>> and only that cipher in curl. That will eliminate any possible
>> server details polluting the test result.
> 
> What is a "normal https_port with SSL"? eg. https_port 3132
> cert=/etc/ssl/squid/proxyserver.pem I would appreciate a full conf
> example so there are no squid misconfigurations that would make the
> test results even more confusing.

I mean an https_port that is not doing ssl-bump or intercept.

 https_port 3129 ssl \
   cert=/etc/ssl/squid/cert.pem \
   key=/etc/ssl/squid/key.pam

(unless you have cert + key in the same .pem, then key= is not needed)

> 
> BTW, does sslproxy_cipher default to ALL if undefined in squid.conf?
> 

No.

If undefined in squid.conf the library default ciphers are used. In
recent years that has been a bit volatile and changes with library
version, so I cant be more specific.

"ALL" enables a lot of ciphers and TLS/SSL features that were known to
be unsafe when the library was released. So are not included in the
default available set.


>. Squid
> "debug_options" is already very verbose but maybe it would help in
> this case to add extra information as to how Squid is calling openssl
> (and maybe seeing if it's possible to get the cipher list).
> 

Good idea. Thanks.

Amos