Squid 4.1 Error negotiating SSL connection

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Squid 4.1 Error negotiating SSL connection

Julian Perconti

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.)

 

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

 

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)

 

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

 

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

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

 

acl step1 at_step SslBump1

acl step2 at_step SslBump2

acl step3 at_step SslBump3

 

acl noBumpSites ssl::server_name_regex -i "/etc/squid/url.nobump"

 

ssl_bump peek step1 all            

ssl_bump peek step2 noBumpSites    

ssl_bump splice step3 noBumpSites  

ssl_bump stare step2               

ssl_bump bump step3            

 

# cache ram

cache_mem 1024 MB

=================CFG==================

 

And so on..

 

Any suggestiong on the config above? Or a workaround the problem mentioned?

 

Thank you all!


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 4.1 Error negotiating SSL connection

Amos Jeffries
Administrator
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 4.1 Error negotiating SSL connection

Julian Perconti
>>>>  El ‎miércoles‎, ‎4‎ de ‎julio‎ de ‎2018‎ ‎01‎:‎21‎:‎12‎ ‎-03, Amos Jeffries <[hidden email]> 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
>>>> [hidden email]
>>>> 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.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 4.1 Error negotiating SSL connection

Eliezer Croitoru
In reply to this post by Amos Jeffries
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: [hidden email]


-----Original Message-----
From: squid-users <[hidden email]> On Behalf Of Amos Jeffries
Sent: Wednesday, July 4, 2018 07:21
To: [hidden email]
Subject: Re: [squid-users] 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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users