[squid-users] Squid 4.1 Error negotiating SSL connection

[Julian Perconti]

>>>>  El ‎miércoles‎, ‎4‎ de ‎julio‎ de ‎2018‎ ‎01‎:‎21‎:‎12‎ ‎-03, Amos Jeffries <squid3 at treenet.co.nz> escribió: 
>>>>  
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 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 at lists.squid-cache.org
>>>> http://lists.squid-cache.org/listinfo/squid-users



Hi Amos,

The temporary workaround I found was add the domains that causes those errors to the splice domains list. 

So, in cache.log now I only can see "TCP_TUNNEL" and (almost all) the Apps on mobile phones work fine. 

Thank You.