[squid-users] SQUID_ERR_SSL_HANDSHAKE

[Amos Jeffries]

On 29/06/19 10:34 pm, Walter H. wrote:
> On 29.06.2019 10:17, Amos Jeffries wrote:
>> On 29/06/19 3:03 am, Walter H. wrote:
>>> sslproxy_cipher
>>> EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA:EECDH:EDH+AESGCM:EDH:ECDH+AESGCM:ECDH+AES:ECDH:AES:HIGH:MEDIUM:!SSLv2:+SSLv3:!3DES:!RC4:!MD5:!IDEA:!SEED:!aNULL:!eNULL:!LOW:!EXP:!DSS:!PSK:!RSA:!SRP
>>>
>>> sslproxy_options NO_SSLv2 NO_SSLv3 TLSv1 TLSv1_1 TLSv1_2
>>>
>> I do not see the tls-dh setting necessary for the elliptic curves to
>> work in your displayed config.
> do you mean the dhparams= at the http_port here?

Sorry, I got that wrong. There is no params for Squid->server
connections. The flags on sslproxy_options you found for the next part
below were what you need.

> 
> http_port 3128 ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=16MB cert=/etc/squid/cert/squidCA.pem
> options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> dhparams=/etc/squid/cert/dhparam.pem
> 
>>   So that would make the above cipher
>> directive essentially disable everything except SSLv3 with MEDIUM/HIGH
>> level non-RSA ciphers.
> even with this:
> 
> sslproxy_options NO_SSLv2,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> and the sslproxy_cipher commented out,
> 
> this site doesn't work;
> 
> sslcrtvalidator_program cache=8192 ttl=240
> /usr/lib64/squid/ssl_crtvalid/main.sh
> sslcrtvalidator_children 12 startup=5 idle=1 concurrency=1
> 
> this validator isn't called at all with the site  https://www.3bg.at
> e.g. with  https://wiki.squid-cache.org   this validator-script is
> caled, and
> there is the following traced
> 
> 0 cert_validate 5324 host=wiki.squid-cache.org
> proto_version=TLSv1.2
> cipher=ECDHE-RSA-AES256-GCM-SHA384
> ...
> 

That is a good sign. That exact combo is in the set supported by the
breaking server so it is unlikely your Squid or its OpenSSL is
contributing to this particular problem.


> 
>>
>> The value of sslproxy_options directive is colon (:) or comma (,)
>> delimited. When multiple values like the above are configured only the
>> first in the list is used. Which forces only TLS/1.2
> I changed this to
> 
> sslproxy_options NO_SSLv2,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 
>> It is not clear what OpenSSL will do when those conflicting options are
>> handed to it. But it looks like it is down-grading to SSLv3 as L.P.H.
>> said then breaking when something else arrives back.
> quite strange only a few sites don't work, https://www.3bg.at is an
> example of such;
> many others work as expected;
> 

That is a bit odd. Though looking at the SSL Labs report for this
www.3bg.at site their restricting to only TLS/1.2 and there are many
clients for which the encryption handshake does not work.

<https://www.ssllabs.com/ssltest/analyze.html?d=www.3bg.at> look to the
list of failures under "Handshake Simulation" and the whole list of "Not
simulated clients" for comparison with UA of any of your clients having
trouble connecting there.


Squid SSL-Bump is limited to negotiating use of TLS versions and
features which are supported by both itself and the client when offering
things to the server. So the problem of some clients agents not
supporting TLS/1.2 or the ciphers the server wants to use can make the
site fail even if your Squid outbound settings support them.


PS. At the technical level that exact error from OpenSSL means that some
data arrived from the server at a time when only TLS alert messages were
supposed to be happening.  I suspect it could be a sign that the
Internet between your proxy and that server is being MITM'd by an agent
that corrupts the protocol for some reason. eg someone elses proxy
rejecting the connection but getting its error response syntax wrong.


Amos