[squid-users] Squid 4.1 Error negotiating SSL connection

[Amos Jeffries]

On 04/07/18 12:06, Julian Perconti wrote:
> Hi all,
> 
>  
> 
> I have installed squid 4.1 on debian 9 with openssl 1.1.0f on
> transparent mode.
> 
>  
> 
> I need to know how to track this error: (debbuging options is almost
> impossible i mean examine the FD, etc.)
> 

The SSL-Bump activity is fairly complex at times and involves many
different layers and components. So an ALL,9 or ALL,7 debug log may be
necessary to trace the actions.

>  
> 
> kid1| Error negotiating SSL connection on FD 19:
> error:00000001:lib(0):func(0):reason(1) (1/-1)
> 
> 


Those annoyingly opaque error messages are produced by your OpenSSL library.

Other programs showing that same string apparently are negotiating
protocol version for the messaging layer or handshake format which are
incompatible with the choice of ciphers. eg SSLv2 message syntax with
TLS ciphers, or SSLv3 message syntax with  TLS/1.2-only ciphers.

Since you have done the cipher test, it may be the SSLv2 issue or some
TLS extension being attempted.


If cache.log is too obscure a packet trace with wireshark may be less
so. The clear-text part of TLS at the start should have better hints
about the issue, whatever it is.


 
> 
> There are a lot of them in cache.log when mobile devices uses
> (unsuccefully) apps like instagram/Pinterest/Facebook/twitter, etc.
> 
>  
> 
> Neither is a “cipher-out” problem because I just tried:
> tls_outgoing_options cipher=ALL (only for testing)
> 

This test is mistaken.

"cipher=ALL" and "options=ALL" actually mean to actively *enable* lots
of things OpenSSL would normally disable. This still counts as
restriction, because only things compatible with the most obsolete or
broken cipher/option can be negotiated.

A correct test would be to _remove_ the cipher=* option entirely from
your config and see what changes.

With no manual restrictions the issues are then limited to natural
differences in OpenSSL version between client and Squid.


> 
> From any PC those sites works well. So there is not a certificate
> missing problem.
> 

When SSL-Bump is done crypto issues are the union of configured
capabilities at client (PC), proxy (Squid), server - plus the 3
particular crypto libraries on each of those uses. So 6 possible points
of failure, all affecting each other.

I find it is often a LOT easier (and more successful) to look at the TLS
handshake itself and see what is actually happening. Then figure out
from there what needs tuning to work around it.


> 
> Here a copy of most relevant config:
> 
>  
> 
> =================CFG==================
> 
>  
> 
> http_port 3128
> 
> http_port 3129 intercept
> 
> https_port 3130 intercept ssl-bump \
> 
>   cert=/etc/squid/ssl_cert/squid4ssl.pem \
> 
>   key=/etc/squid/ssl_cert/squid4ssl.pem \
> 
>   generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> 
>  
> 
> sslcrtd_program /lib/squid/security_file_certgen -s /var/lib/ssl_db -M 4MB
> 
>  
> 
> tls_outgoing_options cafile=/etc/ssl/certs/ca-certificates.crt
> 
> tls_outgoing_options cafile=/etc/squid/ssl_cert/cabundle.pem
> 
> tls_outgoing_options options=NO_SSLv3
> 

This NO_SSLv3 may be part of issue. AFAIK when SSLv3 compatibility is no
longer required the latest OpenSSL is able to move to pure TLS message
syntax which has a few usually very minor differences which TLS/1.3 uses.

The services you mention are the ones IME most likely to be adopting
TLS/1.3 already when clients like your Squid accept it. Which is where
PC vs Squid library differences can lead to drastically different
visible outcomes.


> tls_outgoing_options
> cipher=ALL:!SSLv2:!ADH:!DSS:!MD5:!EXP:!DES:!PSK:!SRP:!RC4:!IDEA:!SEED:!aNULL:!eNULL
> 


HTH
Amos