[squid-users] SSL errors with Squid 3.5.27

[Amos Jeffries]

On 09/06/18 11:15, Julian Perconti wrote:
> Hello community, I am new to the list and, I hope everyone is well.
> 
> I have running a squid server on debian 7.
> 
> My squid version is 3.5.27 manually compiled with LibreSSL 2.6.0 due to
> problems with Dropbox. After compiling squid with LibreSSL, the error
> "unknown cipher returned" has disappeared and dropbox worked correctly.
> 
> Everything works quite well, except that in /var/log/squid/cache.log there
> are 5 types of problems (at least):
> 
> [1] 2018/06/08 17:14:05 kid1| Error negotiating SSL connection on FD 7:
> error:14037418:SSL routines:ACCEPT_SR_KEY_EXCH:tlsv1 alert unknown ca (1/0)
> [2] 2018/06/08 17:14:39 kid1| Error negotiating SSL on FD 11:
> error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed
> (1/-1/0)
> [3] 2018/06/08 18:35:43 kid1| Error negotiating SSL connection on FD 10:
> (104) Connection reset by peer
> [4] 2018/06/08 18:56:52 kid1| Error negotiating SSL on FD 13:
> error:00000000:lib(0):func(0):reason(0) (5/-1/104)
> [5] 2018/06/08 19:20:06 kid1| Error negotiating SSL connection on FD 9:
> error:06FFF064:digital envelope routines:CRYPTO_internal:bad decrypt (1/-1)

This one may need you to check the ciphers you are allowing. Or be a
sign of a bug in the library.

Trying to connect to the server manually with a CLI tool that can debug
the verify procedure would be the best way forward. You may want to look
at the handshake the client is sending to Squid and Squid to the server
for what to test with.


> 
> However I think (I'm not sure but ...), that the most serious is the number
> [2]:
> SSL negotiating error on FD 11: error: 14007086: SSL routines:
> CONNECT_CR_CERT:certificate verify failed (1/-1/0)
> 
> The problem I have it with WhatsApp from mobile devices ... the application
> tries to connect to the network indefinitely without success, and the error
> that appears (at that moment) is [2]: (...) certificate verify failed
> (1/-1/0)
> 

For 3.5.27 you need to find out what their CA is and decide whether its
worth adding to sslproxy_foreign_intermediate_certs (for intermediates),
OR to sslproxy_cafile or the system root CAs if it's self-signed.

If its an intermediate you might have better behaviour with Squid-4. But
be aware that LibreSSL is not tested by any of us dev, so technically
"not supported" even if it usually works.


> 
> https_port 3130 intercept ssl-bump \
>   cert=/etc/squid/ssl_cert/squidCA.pem \
>   key=/etc/squid/ssl_cert/squidCA.pem \
>   generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> tls-dh=/etc/squid/ssl_cert/dhparam.pem

These DH parameters are for old DH not for ECDHE (missing curve name).
So this may be restricting what your Squid can do to match up the client
and server crypto requirements.


> 
> Any kind of suggestion is welcome; both if there is something wrong in the
> configuration written above, or better yet if someone knows the cause and
> solution of this problem.

Most of these are probably just the side effects of an untrusted CA.
This is normal for TLS/SSL.


Amos