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

[Vieri]

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.

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.


> 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.

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

> So throwing blame at anyone when it "fails" without a bug being clearly

> in evidence is the wrong thing to do. It is usually a sign that
> everybody is actually doing "The Right Thing".

Correct me if I'm wrong but I sense friction here. It was not my intention of "blaming" anyone. That's a harsh word, in my opinion. I love Squid. As with many huge projects, there are bound to be bugs or lacking features. I never said it WAS the case here anyway. I'm just trying to help and pinpoint the root cause of an issue I'm seeing. I guess I'm frustrated because I still have WinXP&IE8 clients lying around and I'm sure that's the sole source of problems. 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). 


Thanks,

Vieri