So with 4.5 we are still waiting for openssl to advance into TLS 1.3, right? Can the thread writer add a list of these domains which can help others? Thanks, Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: eliezer@xxxxxxxxxxxx -----Original Message----- From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Amos Jeffries Sent: Wednesday, July 4, 2018 07:21 To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Squid 4.1 Error negotiating SSL connection 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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
