[squid-users] Squid 6.6 kick abandoning connections

[Jonathan Lee]

Hello fellow Squid Users 

I am using Bump with certificates installed on devices does anyone know what 
this error is...

kick abandoning conn43723 local=192.168.1.1:3128 remote=192.168.1.5:52129 FD 
178 flags=1

Does anyone know how to fix my last weird error I have with Squid 6.6 

This is my last weird error I am trying to pinpoint…

I really appreciate the new error codes that I can see the older versions did 
not have any information it was blank for 
issues like this…

thanks 




___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Jonathan Lee]

FIXED 

I think it wanted a new certificate generated mine became to weak I needed one 
that ECDSA with prime256v sha256 and not RSA anymore that solved my errors


The error is gone when this cert is used :) 

> On Jul 5, 2024, at 14:33, Jonathan Lee  wrote:
> 
> However even with it marked as no 
> 
> 05.07.2024 14:30:46   ERROR: failure while accepting a TLS connection on 
> conn4633 local=192.168.1.1:3128 remote=192.168.1.5:49721 FD 30 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 
> 
> 
> continues
> 
> I am going to take a break please if anyone know how to resolve this or wants 
> me to try something else let me know. I was originally looking for the 
> certificate when this error occurs however the error comes from the TLS_v1.3 
> as seen in the pcap files below. 
> 
> 
> Thanks again everyone  
> 
>> On Jul 4, 2024, at 16:02, Jonathan Lee  wrote:
>> 
> I do not recommend changing your configuration at this time. I recommend 
> rereading my earlier recommendation and following that instead: "As the 
> next step in triage, I recommend determining what that CA is in these 
> cases (e.g., by capturing raw TLS packets and matching them with 
> connection information from A000417 error messages in cache.log or 
> %err_detail in access.log)."
>> 
>> 
>> Ok I went back to 5.8 and ran the following command after I removed the 
>> changes I used does this help this is ran on the firewall side itself. 
>> 
>>  openssl s_client -connect foxnews.com:443 
>> 
>> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert 
>> Global Root CA
>> verify return:1
>> depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>> verify return:1
>> depth=0 C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN 
>> = wildcard.foxnews.com
>> verify return:1
>> CONNECTED(0004)
>> ---
>> Certificate chain
>>  0 s:C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN = 
>> wildcard.foxnews.com
>>i:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>>  1 s:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>>i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
>> Root CA
>> 
>> -END CERTIFICATE-
>> subject=C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN 
>> = wildcard.foxnews.com
>> 
>> issuer=C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>> 
>> ---
>> No client certificate CA names sent
>> Peer signing digest: SHA256
>> Peer signature type: ECDSA
>> Server Temp Key: X25519, 253 bits
>> ---
>> SSL handshake has read 4198 bytes and written 393 bytes
>> Verification: OK
>> ---
>> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
>> Server public key is 256 bit
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> No ALPN negotiated
>> Early data was not sent
>> Verify return code: 0 (ok)
>> ---
>> DONE
>> 
>> Does that help I am not going to pretend I understand TLS options I do 
>> understand how the SSL ciphers work and certificates but all the different 
>> options and kinds are what is confusing me. I did not seem to have this 
>> error before.
>> 
>> 
>> Should I regenerate a new certificate for the new version of Squid and 
>> redeploy them all to hosts again? I used this method in the past and it 
>> worked for a long time after I imported it. I am wondering if this is 
>> outdated now
>> 
>> openssl req -x509 -new -nodes -key myProxykey.key -sha256 -days 365 -out 
>> myProxyca.pem
>> 
>> 
>>> On Jul 4, 2024, at 15:13, Jonathan Lee  wrote:
>>> 
>>> Sorry 
>>> 
>>> tls_outgoing_options 
>>> cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>>> tls_outgoing_options options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
>>> 
>>> Would I add this here?
>>> 
 On Jul 4, 2024, at 15:12, Jonathan Lee  wrote:
 
 I know before I could use 
 
 tls_outgoing_options 
 cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
 
 However with the update I am seeing 
 
 ERROR: Unsupported TLS option SINGLE_ECDH_USE
 
 I found researching in lists-squid-cache.org 
  that someone solved this with appending 
 TLS13-AES-256-CGM-SHA384 to the ciphers. 
 
 I am thinking this is my issue also.
 
 I see that error over and over when I run "squid -k parse”
 
 Do I append this to the options cipher list?
 
 Jonathan Lee
 
> On Jul 4, 2024, at 14:45, Alex Rousskov 
>  wrote:
> 
> On 2024-07-04 15:37, Jonathan Lee wrote:
> 
>> in Squid.conf I have nothing with that detective.
> 
> Sounds good; sslproxy_cert_sign default should work OK in most cases. I 
> mentioned 

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Jonathan Lee]

However even with it marked as no 

05.07.2024 14:30:46 ERROR: failure while accepting a TLS connection on 
conn4633 local=192.168.1.1:3128 remote=192.168.1.5:49721 FD 30 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1



continues

I am going to take a break please if anyone know how to resolve this or wants 
me to try something else let me know. I was originally looking for the 
certificate when this error occurs however the error comes from the TLS_v1.3 as 
seen in the pcap files below. 


Thanks again everyone  

> On Jul 4, 2024, at 16:02, Jonathan Lee  wrote:
> 
 I do not recommend changing your configuration at this time. I recommend 
 rereading my earlier recommendation and following that instead: "As the 
 next step in triage, I recommend determining what that CA is in these 
 cases (e.g., by capturing raw TLS packets and matching them with 
 connection information from A000417 error messages in cache.log or 
 %err_detail in access.log)."
> 
> 
> Ok I went back to 5.8 and ran the following command after I removed the 
> changes I used does this help this is ran on the firewall side itself. 
> 
>  openssl s_client -connect foxnews.com:443 
> 
> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
> Root CA
> verify return:1
> depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
> verify return:1
> depth=0 C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN 
> = wildcard.foxnews.com
> verify return:1
> CONNECTED(0004)
> ---
> Certificate chain
>  0 s:C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN = 
> wildcard.foxnews.com
>i:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>  1 s:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
> Root CA
> 
> -END CERTIFICATE-
> subject=C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN 
> = wildcard.foxnews.com
> 
> issuer=C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
> 
> ---
> No client certificate CA names sent
> Peer signing digest: SHA256
> Peer signature type: ECDSA
> Server Temp Key: X25519, 253 bits
> ---
> SSL handshake has read 4198 bytes and written 393 bytes
> Verification: OK
> ---
> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
> Server public key is 256 bit
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> Verify return code: 0 (ok)
> ---
> DONE
> 
> Does that help I am not going to pretend I understand TLS options I do 
> understand how the SSL ciphers work and certificates but all the different 
> options and kinds are what is confusing me. I did not seem to have this error 
> before.
> 
> 
> Should I regenerate a new certificate for the new version of Squid and 
> redeploy them all to hosts again? I used this method in the past and it 
> worked for a long time after I imported it. I am wondering if this is 
> outdated now
> 
> openssl req -x509 -new -nodes -key myProxykey.key -sha256 -days 365 -out 
> myProxyca.pem
> 
> 
>> On Jul 4, 2024, at 15:13, Jonathan Lee  wrote:
>> 
>> Sorry 
>> 
>> tls_outgoing_options 
>> cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>> tls_outgoing_options options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
>> 
>> Would I add this here?
>> 
>>> On Jul 4, 2024, at 15:12, Jonathan Lee  wrote:
>>> 
>>> I know before I could use 
>>> 
>>> tls_outgoing_options 
>>> cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>>> 
>>> However with the update I am seeing 
>>> 
>>> ERROR: Unsupported TLS option SINGLE_ECDH_USE
>>> 
>>> I found researching in lists-squid-cache.org 
>>>  that someone solved this with appending 
>>> TLS13-AES-256-CGM-SHA384 to the ciphers. 
>>> 
>>> I am thinking this is my issue also.
>>> 
>>> I see that error over and over when I run "squid -k parse”
>>> 
>>> Do I append this to the options cipher list?
>>> 
>>> Jonathan Lee
>>> 
 On Jul 4, 2024, at 14:45, Alex Rousskov  
 wrote:
 
 On 2024-07-04 15:37, Jonathan Lee wrote:
 
> in Squid.conf I have nothing with that detective.
 
 Sounds good; sslproxy_cert_sign default should work OK in most cases. I 
 mentioned signUntrusted algorithm so that you can discover (from the 
 corresponding sslproxy_cert_sign documentation) which CA/certificate Squid 
 uses in which SslBump use case. Triage is often easier if folks share the 
 same working theory, and my current working theory suggests that we are 
 looking at a (default) signUntrusted use case.
 
 The solution here probably does _not_ involve changing 

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Jonathan Lee]

tls_outgoing_options options=NO_SSLv3,NO_TLSv1_3
NO_TLSv1_3 is the directive if you need to disable this I have found for all 
other users with this problem 

> On Jul 5, 2024, at 14:21, Jonathan Lee  wrote:
> 
> output of versions 
> 
> Shell Output - openssl ciphers -s -v ECDHE
> TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any  Au=any   Enc=AESGCM(256)   
>  Mac=AEAD
> TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any  Au=any   
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any  Au=any   Enc=AESGCM(128)   
>  Mac=AEAD
> ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256)   
>  Mac=AEAD
> ECDHE-RSA-AES256-GCM-SHA384TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(256)   
>  Mac=AEAD
> ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2 Kx=ECDH Au=ECDSA 
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> ECDHE-RSA-CHACHA20-POLY1305TLSv1.2 Kx=ECDH Au=RSA   
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> ECDHE-ECDSA-AES256-CCM8TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(256)  
>  Mac=AEAD
> ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256)   
>  Mac=AEAD
> ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128)   
>  Mac=AEAD
> ECDHE-RSA-AES128-GCM-SHA256TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(128)   
>  Mac=AEAD
> ECDHE-ECDSA-AES128-CCM8TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(128)  
>  Mac=AEAD
> ECDHE-ECDSA-AES128-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128)   
>  Mac=AEAD
> ECDHE-ECDSA-AES256-SHA384  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)  
>  Mac=SHA384
> ECDHE-RSA-AES256-SHA384TLSv1.2 Kx=ECDH Au=RSA   Enc=AES(256)  
>  Mac=SHA384
> ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=Camellia(256) 
>  Mac=SHA384
> ECDHE-RSA-CAMELLIA256-SHA384   TLSv1.2 Kx=ECDH Au=RSA   Enc=Camellia(256) 
>  Mac=SHA384
> ECDHE-ECDSA-AES128-SHA256  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)  
>  Mac=SHA256
> ECDHE-RSA-AES128-SHA256TLSv1.2 Kx=ECDH Au=RSA   Enc=AES(128)  
>  Mac=SHA256
> ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=Camellia(128) 
>  Mac=SHA256
> ECDHE-RSA-CAMELLIA128-SHA256   TLSv1.2 Kx=ECDH Au=RSA   Enc=Camellia(128) 
>  Mac=SHA256
> ECDHE-ECDSA-AES256-SHA TLSv1   Kx=ECDH Au=ECDSA Enc=AES(256)  
>  Mac=SHA1
> ECDHE-RSA-AES256-SHA   TLSv1   Kx=ECDH Au=RSA   Enc=AES(256)  
>  Mac=SHA1
> ECDHE-ECDSA-AES128-SHA TLSv1   Kx=ECDH Au=ECDSA Enc=AES(128)  
>  Mac=SHA1
> ECDHE-RSA-AES128-SHA   TLSv1   Kx=ECDH Au=RSA   Enc=AES(128)  
>  Mac=SHA1
> So it does support TLSv1.3 Could it be because my certificate authority is 
> type RSA? Disabling TLSv1.3 would fix it again that doesn’t help me in the 
> future 
> 
> openssl req -x509 -new -nodes -key myProxykey.key -sha256 -days 365 -out 
> myProxyca.pem
> 
> 
> 
>> On Jul 5, 2024, at 13:54, Jonathan Lee  wrote:
>> 
>> I have also tested in 5.8 and 6.6 both show the same condition, 6.6 shows 
>> errors for it however. I have also imported my certificates into wireshark. 
>> 
>> Just to confirm this is the firewall 192.168.1.1 port 3128 is squid going to 
>> iMac that is attempting TSL1.3 I have nosslv3 set also. The firewall is 
>> where I grabbed the pcap from 
>> Sent from my iPhone
>> 
>>> On Jul 5, 2024, at 11:52, Jonathan Lee  wrote:
>>> 
>>> If it’s encrypted at TLS1.3 it should still work with the approved 
>>> certificate authority as it is imported to my devices I own. I just enable 
>>> TLS1.3 right?
>>> 
 On Jul 5, 2024, at 11:28,  
  wrote:
 
 The only one I got a certificate from was the non iMac
 
 The iMac keeps sending change cipher requests and wants TLS1.3 over and 
 over as soon as a TLS1.2 pops up it works
 
 That one has the certificate however that system the Toshiba does not have 
 any issues with this error. I highly suspect that I need to enable TLS1.3 
 would you agree?
 
 -Original Message-
 From: Alex Rousskov 
 Sent: Friday, July 5, 2024 11:02 AM
 To: squid-users 
 Cc: Jonathan Lee 
 Subject: Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6
 
 On 2024-07-05 12:02, Jonathan Lee wrote:
 
>> Alex: I recommend determining what that CA is in these cases (e.g., by 
>> capturing raw TLS packets and matching them with connection information 
>> from A000417 error messages in cache.log or %err_detail in access.log).
 
 
> I have Wireshark running do I just look for information with
> ssl.handshake.type == 1
 
> Or is there a wireshark particular filter you would like ran to help with 
> isolation?
 
 
 Please use Wireshark to determine the name of CA that 

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Jonathan Lee]

output of versions 

Shell Output - openssl ciphers -s -v ECDHE
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any  Au=any   Enc=AESGCM(256) 
   Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any  Au=any   
Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any  Au=any   Enc=AESGCM(128) 
   Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) 
   Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(256) 
   Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2 Kx=ECDH Au=ECDSA 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305TLSv1.2 Kx=ECDH Au=RSA   
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM8TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(256)
   Mac=AEAD
ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256) 
   Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) 
   Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(128) 
   Mac=AEAD
ECDHE-ECDSA-AES128-CCM8TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(128)
   Mac=AEAD
ECDHE-ECDSA-AES128-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128) 
   Mac=AEAD
ECDHE-ECDSA-AES256-SHA384  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)
   Mac=SHA384
ECDHE-RSA-AES256-SHA384TLSv1.2 Kx=ECDH Au=RSA   Enc=AES(256)
   Mac=SHA384
ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=Camellia(256)   
   Mac=SHA384
ECDHE-RSA-CAMELLIA256-SHA384   TLSv1.2 Kx=ECDH Au=RSA   Enc=Camellia(256)   
   Mac=SHA384
ECDHE-ECDSA-AES128-SHA256  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)
   Mac=SHA256
ECDHE-RSA-AES128-SHA256TLSv1.2 Kx=ECDH Au=RSA   Enc=AES(128)
   Mac=SHA256
ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=Camellia(128)   
   Mac=SHA256
ECDHE-RSA-CAMELLIA128-SHA256   TLSv1.2 Kx=ECDH Au=RSA   Enc=Camellia(128)   
   Mac=SHA256
ECDHE-ECDSA-AES256-SHA TLSv1   Kx=ECDH Au=ECDSA Enc=AES(256)
   Mac=SHA1
ECDHE-RSA-AES256-SHA   TLSv1   Kx=ECDH Au=RSA   Enc=AES(256)
   Mac=SHA1
ECDHE-ECDSA-AES128-SHA TLSv1   Kx=ECDH Au=ECDSA Enc=AES(128)
   Mac=SHA1
ECDHE-RSA-AES128-SHA   TLSv1   Kx=ECDH Au=RSA   Enc=AES(128)
   Mac=SHA1
So it does support TLSv1.3 Could it be because my certificate authority is type 
RSA? Disabling TLSv1.3 would fix it again that doesn’t help me in the future 

openssl req -x509 -new -nodes -key myProxykey.key -sha256 -days 365 -out 
myProxyca.pem



> On Jul 5, 2024, at 13:54, Jonathan Lee  wrote:
> 
> I have also tested in 5.8 and 6.6 both show the same condition, 6.6 shows 
> errors for it however. I have also imported my certificates into wireshark. 
> 
> Just to confirm this is the firewall 192.168.1.1 port 3128 is squid going to 
> iMac that is attempting TSL1.3 I have nosslv3 set also. The firewall is where 
> I grabbed the pcap from 
> Sent from my iPhone
> 
>> On Jul 5, 2024, at 11:52, Jonathan Lee  wrote:
>> 
>> If it’s encrypted at TLS1.3 it should still work with the approved 
>> certificate authority as it is imported to my devices I own. I just enable 
>> TLS1.3 right?
>> 
>>> On Jul 5, 2024, at 11:28,  
>>>  wrote:
>>> 
>>> The only one I got a certificate from was the non iMac
>>> 
>>> The iMac keeps sending change cipher requests and wants TLS1.3 over and 
>>> over as soon as a TLS1.2 pops up it works
>>> 
>>> That one has the certificate however that system the Toshiba does not have 
>>> any issues with this error. I highly suspect that I need to enable TLS1.3 
>>> would you agree?
>>> 
>>> -Original Message-
>>> From: Alex Rousskov 
>>> Sent: Friday, July 5, 2024 11:02 AM
>>> To: squid-users 
>>> Cc: Jonathan Lee 
>>> Subject: Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6
>>> 
>>> On 2024-07-05 12:02, Jonathan Lee wrote:
>>> 
> Alex: I recommend determining what that CA is in these cases (e.g., by 
> capturing raw TLS packets and matching them with connection information 
> from A000417 error messages in cache.log or %err_detail in access.log).
>>> 
>>> 
 I have Wireshark running do I just look for information with
 ssl.handshake.type == 1
>>> 
 Or is there a wireshark particular filter you would like ran to help with 
 isolation?
>>> 
>>> 
>>> Please use Wireshark to determine the name of CA that issued the 
>>> certificate that Squid sent to the client in the failing test case. If you 
>>> are not sure, feel free to share issuer and subject fields of all 
>>> certificates that Squid sent to the client in that test case (there may be 
>>> two of each if Squid sent two certificates). Or even share a pointer to the 
>>> entire (compressed) raw test case packet capture in pcap 

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Jonathan Lee]

I have also tested in 5.8 and 6.6 both show the same condition, 6.6 shows 
errors for it however. I have also imported my certificates into wireshark. 

Just to confirm this is the firewall 192.168.1.1 port 3128 is squid going to 
iMac that is attempting TSL1.3 I have nosslv3 set also. The firewall is where I 
grabbed the pcap from 
Sent from my iPhone

> On Jul 5, 2024, at 11:52, Jonathan Lee  wrote:
> 
> If it’s encrypted at TLS1.3 it should still work with the approved 
> certificate authority as it is imported to my devices I own. I just enable 
> TLS1.3 right?
> 
>> On Jul 5, 2024, at 11:28,  
>>  wrote:
>> 
>> The only one I got a certificate from was the non iMac
>> 
>> The iMac keeps sending change cipher requests and wants TLS1.3 over and over 
>> as soon as a TLS1.2 pops up it works
>> 
>> That one has the certificate however that system the Toshiba does not have 
>> any issues with this error. I highly suspect that I need to enable TLS1.3 
>> would you agree?
>> 
>> -Original Message-
>> From: Alex Rousskov 
>> Sent: Friday, July 5, 2024 11:02 AM
>> To: squid-users 
>> Cc: Jonathan Lee 
>> Subject: Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6
>> 
>> On 2024-07-05 12:02, Jonathan Lee wrote:
>> 
 Alex: I recommend determining what that CA is in these cases (e.g., by 
 capturing raw TLS packets and matching them with connection information 
 from A000417 error messages in cache.log or %err_detail in access.log).
>> 
>> 
>>> I have Wireshark running do I just look for information with
>>> ssl.handshake.type == 1
>> 
>>> Or is there a wireshark particular filter you would like ran to help with 
>>> isolation?
>> 
>> 
>> Please use Wireshark to determine the name of CA that issued the certificate 
>> that Squid sent to the client in the failing test case. If you are not sure, 
>> feel free to share issuer and subject fields of all certificates that Squid 
>> sent to the client in that test case (there may be two of each if Squid sent 
>> two certificates). Or even share a pointer to the entire (compressed) raw 
>> test case packet capture in pcap format!
>> 
>> These certificates are a part of standard TLS handshake, and Wireshark 
>> usually displays their fields when one studies TLS handshake bytes using 
>> Wireshark UI.
>> 
>> I do not know what filter would work best, but there should be just a 
>> handful of TLS handshake packets to examine for the test case, so no filter 
>> should be necessary.
>> 
>> 
>> HTH,
>> 
>> Alex.
>> 
>> 
>> 
 On Jul 5, 2024, at 08:23, Jonathan Lee  wrote:
 
 Thanks for the email and support with this. I will get wireshark
 running on the client and get the info required. Yes the information
 prior is from the firewall side outside of the proxy testing from the
 demilitarized zone area. I wanted to test this first to rule that out
 as it’s coming in from that first and hits the proxy next Sent from
 my iPhone
 
> On Jul 5, 2024, at 06:33, Alex Rousskov 
>  wrote:
> 
> On 2024-07-04 19:12, Jonathan Lee wrote:
>> You also stated .. " my current working theory suggests that we are 
>> looking at a (default) signUntrusted use case.”
>> I noticed for Squid documents that default is now set to off ..
> 
> The http_port option you are looking at now is not the directive I was 
> talking about earlier.
> 
>> http_port
>> tls-default-ca[=off]
>>  Whether to use the system Trusted CAs. Default is OFF.
>> Would enabling this resolve the problem in Squid 6.6 for error.
> 
> 
> No, the above poorly documented http_port option is for validating 
> _client_ certificates. It has been off since Squid v4 AFAICT. Your 
> clients are not sending client certificates to Squid.
> 
> According to the working theory, the problem we are solving is related to 
> server certificates. http_port tls-default-ca option does not affect 
> server certificate validation. Server certificate validation should use 
> default CAs by default.
> 
> Outside of SslBump, server certificate validation is controlled by 
> tls_outgoing_options default-ca option. That option defaults to "on". I 
> am not sure whether SslBump honors that directive/option though. There 
> are known related bugs in that area. However, we are jumping ahead of 
> ourselves. We should confirm the working theory first.
> 
>> The squid.conf.documented lists it incorrectly
> 
> Squid has many directives and a directive may have many options. One 
> should not use an directive option name instead of a directive name. One 
> should not use an option from one directive with another directive. Squid 
> naming is often inconsistent; be careful.
> 
> * http_port is a directive. tls-default-ca is an option for that 
> directive. It is used for client certificate validation. It defaults to 
> "off" (because 

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Jonathan Lee]

If it’s encrypted at TLS1.3 it should still work with the approved certificate 
authority as it is imported to my devices I own. I just enable TLS1.3 right?

> On Jul 5, 2024, at 11:28,  
>  wrote:
> 
> The only one I got a certificate from was the non iMac
> 
> The iMac keeps sending change cipher requests and wants TLS1.3 over and over 
> as soon as a TLS1.2 pops up it works 
> 
> That one has the certificate however that system the Toshiba does not have 
> any issues with this error. I highly suspect that I need to enable TLS1.3 
> would you agree?
> 
> -Original Message-
> From: Alex Rousskov  
> Sent: Friday, July 5, 2024 11:02 AM
> To: squid-users 
> Cc: Jonathan Lee 
> Subject: Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6
> 
> On 2024-07-05 12:02, Jonathan Lee wrote:
> 
>>> Alex: I recommend determining what that CA is in these cases (e.g., by 
>>> capturing raw TLS packets and matching them with connection information 
>>> from A000417 error messages in cache.log or %err_detail in access.log).
> 
> 
>> I have Wireshark running do I just look for information with 
>> ssl.handshake.type == 1
> 
>> Or is there a wireshark particular filter you would like ran to help with 
>> isolation?
> 
> 
> Please use Wireshark to determine the name of CA that issued the certificate 
> that Squid sent to the client in the failing test case. If you are not sure, 
> feel free to share issuer and subject fields of all certificates that Squid 
> sent to the client in that test case (there may be two of each if Squid sent 
> two certificates). Or even share a pointer to the entire (compressed) raw 
> test case packet capture in pcap format!
> 
> These certificates are a part of standard TLS handshake, and Wireshark 
> usually displays their fields when one studies TLS handshake bytes using 
> Wireshark UI.
> 
> I do not know what filter would work best, but there should be just a handful 
> of TLS handshake packets to examine for the test case, so no filter should be 
> necessary.
> 
> 
> HTH,
> 
> Alex.
> 
> 
> 
>>> On Jul 5, 2024, at 08:23, Jonathan Lee  wrote:
>>> 
>>> Thanks for the email and support with this. I will get wireshark 
>>> running on the client and get the info required. Yes the information 
>>> prior is from the firewall side outside of the proxy testing from the 
>>> demilitarized zone area. I wanted to test this first to rule that out 
>>> as it’s coming in from that first and hits the proxy next Sent from 
>>> my iPhone
>>> 
 On Jul 5, 2024, at 06:33, Alex Rousskov  
 wrote:
 
 On 2024-07-04 19:12, Jonathan Lee wrote:
> You also stated .. " my current working theory suggests that we are 
> looking at a (default) signUntrusted use case.”
> I noticed for Squid documents that default is now set to off ..
 
 The http_port option you are looking at now is not the directive I was 
 talking about earlier.
 
> http_port
> tls-default-ca[=off]
>   Whether to use the system Trusted CAs. Default is OFF.
> Would enabling this resolve the problem in Squid 6.6 for error.
 
 
 No, the above poorly documented http_port option is for validating 
 _client_ certificates. It has been off since Squid v4 AFAICT. Your clients 
 are not sending client certificates to Squid.
 
 According to the working theory, the problem we are solving is related to 
 server certificates. http_port tls-default-ca option does not affect 
 server certificate validation. Server certificate validation should use 
 default CAs by default.
 
 Outside of SslBump, server certificate validation is controlled by 
 tls_outgoing_options default-ca option. That option defaults to "on". I am 
 not sure whether SslBump honors that directive/option though. There are 
 known related bugs in that area. However, we are jumping ahead of 
 ourselves. We should confirm the working theory first.
 
> The squid.conf.documented lists it incorrectly
 
 Squid has many directives and a directive may have many options. One 
 should not use an directive option name instead of a directive name. One 
 should not use an option from one directive with another directive. Squid 
 naming is often inconsistent; be careful.
 
 * http_port is a directive. tls-default-ca is an option for that 
 directive. It is used for client certificate validation. It defaults to 
 "off" (because client certificates are rarely signed by well-known (a.k.a. 
 "default") CAs preinstalled in many deployment environments).
 
 * tls_outgoing_options is a directive. default-ca is an option for that 
 directive. It is used for server certificate validation outside of SslBump 
 contexts (at least!). It defaults to "on" (because server certificates are 
 usually signed by well-known (a.k.a. "default") CAs preinstalled in many 
 deployment environments).
 
 AFAICT, the 

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[jonathanlee571]

The only one I got a certificate from was the non iMac

The iMac keeps sending change cipher requests and wants TLS1.3 over and over as 
soon as a TLS1.2 pops up it works 

That one has the certificate however that system the Toshiba does not have any 
issues with this error. I highly suspect that I need to enable TLS1.3 would you 
agree?

-Original Message-
From: Alex Rousskov  
Sent: Friday, July 5, 2024 11:02 AM
To: squid-users 
Cc: Jonathan Lee 
Subject: Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

On 2024-07-05 12:02, Jonathan Lee wrote:

> > Alex: I recommend determining what that CA is in these cases (e.g., by 
> > capturing raw TLS packets and matching them with connection information 
> > from A000417 error messages in cache.log or %err_detail in access.log).


> I have Wireshark running do I just look for information with 
> ssl.handshake.type == 1

> Or is there a wireshark particular filter you would like ran to help with 
> isolation?


Please use Wireshark to determine the name of CA that issued the certificate 
that Squid sent to the client in the failing test case. If you are not sure, 
feel free to share issuer and subject fields of all certificates that Squid 
sent to the client in that test case (there may be two of each if Squid sent 
two certificates). Or even share a pointer to the entire (compressed) raw test 
case packet capture in pcap format!

These certificates are a part of standard TLS handshake, and Wireshark usually 
displays their fields when one studies TLS handshake bytes using Wireshark UI.

I do not know what filter would work best, but there should be just a handful 
of TLS handshake packets to examine for the test case, so no filter should be 
necessary.


HTH,

Alex.



>> On Jul 5, 2024, at 08:23, Jonathan Lee  wrote:
>>
>> Thanks for the email and support with this. I will get wireshark 
>> running on the client and get the info required. Yes the information 
>> prior is from the firewall side outside of the proxy testing from the 
>> demilitarized zone area. I wanted to test this first to rule that out 
>> as it’s coming in from that first and hits the proxy next Sent from 
>> my iPhone
>>
>>> On Jul 5, 2024, at 06:33, Alex Rousskov  
>>> wrote:
>>>
>>> On 2024-07-04 19:12, Jonathan Lee wrote:
 You also stated .. " my current working theory suggests that we are 
 looking at a (default) signUntrusted use case.”
 I noticed for Squid documents that default is now set to off ..
>>>
>>> The http_port option you are looking at now is not the directive I was 
>>> talking about earlier.
>>>
 http_port
 tls-default-ca[=off]
Whether to use the system Trusted CAs. Default is OFF.
 Would enabling this resolve the problem in Squid 6.6 for error.
>>>
>>>
>>> No, the above poorly documented http_port option is for validating _client_ 
>>> certificates. It has been off since Squid v4 AFAICT. Your clients are not 
>>> sending client certificates to Squid.
>>>
>>> According to the working theory, the problem we are solving is related to 
>>> server certificates. http_port tls-default-ca option does not affect server 
>>> certificate validation. Server certificate validation should use default 
>>> CAs by default.
>>>
>>> Outside of SslBump, server certificate validation is controlled by 
>>> tls_outgoing_options default-ca option. That option defaults to "on". I am 
>>> not sure whether SslBump honors that directive/option though. There are 
>>> known related bugs in that area. However, we are jumping ahead of 
>>> ourselves. We should confirm the working theory first.
>>>
 The squid.conf.documented lists it incorrectly
>>>
>>> Squid has many directives and a directive may have many options. One should 
>>> not use an directive option name instead of a directive name. One should 
>>> not use an option from one directive with another directive. Squid naming 
>>> is often inconsistent; be careful.
>>>
>>> * http_port is a directive. tls-default-ca is an option for that directive. 
>>> It is used for client certificate validation. It defaults to "off" (because 
>>> client certificates are rarely signed by well-known (a.k.a. "default") CAs 
>>> preinstalled in many deployment environments).
>>>
>>> * tls_outgoing_options is a directive. default-ca is an option for that 
>>> directive. It is used for server certificate validation outside of SslBump 
>>> contexts (at least!). It defaults to "on" (because server certificates are 
>>> usually signed by well-known (a.k.a. "default") CAs preinstalled in many 
>>> deployment environments).
>>>
>>> AFAICT, the documentation in question is not wrong (but is insufficient).
>>>
>>> Again, I do not recommend changing any Squid configuration 
>>> directives/options at this triage state.
>>>
>>> Alex.
>>>

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Alex Rousskov]

On 2024-07-05 12:02, Jonathan Lee wrote:


> Alex: I recommend determining what that CA is in these cases (e.g., by 
capturing raw TLS packets and matching them with connection information from 
A000417 error messages in cache.log or %err_detail in access.log).




I have Wireshark running do I just look for information with ssl.handshake.type 
== 1



Or is there a wireshark particular filter you would like ran to help with 
isolation?



Please use Wireshark to determine the name of CA that issued the 
certificate that Squid sent to the client in the failing test case. If 
you are not sure, feel free to share issuer and subject fields of all 
certificates that Squid sent to the client in that test case (there may 
be two of each if Squid sent two certificates). Or even share a pointer 
to the entire (compressed) raw test case packet capture in pcap format!


These certificates are a part of standard TLS handshake, and Wireshark 
usually displays their fields when one studies TLS handshake bytes using 
Wireshark UI.


I do not know what filter would work best, but there should be just a 
handful of TLS handshake packets to examine for the test case, so no 
filter should be necessary.



HTH,

Alex.




On Jul 5, 2024, at 08:23, Jonathan Lee  wrote:

Thanks for the email and support with this. I will get wireshark running on the 
client and get the info required. Yes the information prior is from the 
firewall side outside of the proxy testing from the demilitarized zone area. I 
wanted to test this first to rule that out as it’s coming in from that first 
and hits the proxy next
Sent from my iPhone


On Jul 5, 2024, at 06:33, Alex Rousskov  
wrote:

On 2024-07-04 19:12, Jonathan Lee wrote:

You also stated .. " my current working theory suggests that we are looking at 
a (default) signUntrusted use case.”
I noticed for Squid documents that default is now set to off ..


The http_port option you are looking at now is not the directive I was talking 
about earlier.


http_port
tls-default-ca[=off]
   Whether to use the system Trusted CAs. Default is OFF.
Would enabling this resolve the problem in Squid 6.6 for error.



No, the above poorly documented http_port option is for validating _client_ 
certificates. It has been off since Squid v4 AFAICT. Your clients are not 
sending client certificates to Squid.

According to the working theory, the problem we are solving is related to 
server certificates. http_port tls-default-ca option does not affect server 
certificate validation. Server certificate validation should use default CAs by 
default.

Outside of SslBump, server certificate validation is controlled by tls_outgoing_options 
default-ca option. That option defaults to "on". I am not sure whether SslBump 
honors that directive/option though. There are known related bugs in that area. However, 
we are jumping ahead of ourselves. We should confirm the working theory first.


The squid.conf.documented lists it incorrectly


Squid has many directives and a directive may have many options. One should not 
use an directive option name instead of a directive name. One should not use an 
option from one directive with another directive. Squid naming is often 
inconsistent; be careful.

* http_port is a directive. tls-default-ca is an option for that directive. It is used for client 
certificate validation. It defaults to "off" (because client certificates are rarely 
signed by well-known (a.k.a. "default") CAs preinstalled in many deployment environments).

* tls_outgoing_options is a directive. default-ca is an option for that directive. It is used for 
server certificate validation outside of SslBump contexts (at least!). It defaults to 
"on" (because server certificates are usually signed by well-known (a.k.a. 
"default") CAs preinstalled in many deployment environments).

AFAICT, the documentation in question is not wrong (but is insufficient).

Again, I do not recommend changing any Squid configuration directives/options 
at this triage state.

Alex.



___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ERROR: Unsupported TLS option SINGLE_ECDH_USE

[Alex Rousskov]

On 2024-07-05 11:35, Jonathan Lee wrote:


tls_outgoing_options options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE

ERROR: Unsupported TLS option SINGLE_ECDH_USE


Your OpenSSL version defines SSL_OP_SINGLE_ECDH_USE name but otherwise 
ignores SSL_OP_SINGLE_ECDH_USE. OpenSSL behavior that was triggered by 
using this option in old OpenSSL releases is now default behavior, so 
using this option is no longer needed to trigger single-DH key use[1].


Adding SINGLE_ECDH_USE to your configuration achieves/changes nothing 
(with modern OpenSSL versions) as far as traffic on the wire is 
concerned. AFAICT, you should not use that option in squid.conf.


HTH,

Alex.

[1]: 
https://wiki.openssl.org/index.php/List_of_SSL_OP_Flags#SSL_OP_SINGLE_DH_USE


___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Jonathan Lee]

Side note: I have just found while analyzing Wireshark packets that this 
A000417 error only occurs with use of the iMac and the Safari browser, this 
does not occur on Windows 10 with the Edge browser. 

> On Jul 5, 2024, at 09:02, Jonathan Lee  wrote:
> 
> per 
> 
> As the next step in triage, I recommend determining what that CA is in these 
> cases (e.g., by capturing raw TLS packets and matching them with connection 
> information from A000417 error messages in cache.log or %err_detail in 
> access.log).
> 
> 
> I have Wireshark running do I just look for information with 
> ssl.handshake.type == 1
> 
> Or is there a wireshark particular filter you would like ran to help with 
> isolation?
> 
> 
> 
>> On Jul 5, 2024, at 08:23, Jonathan Lee  wrote:
>> 
>> Thanks for the email and support with this. I will get wireshark running on 
>> the client and get the info required. Yes the information prior is from the 
>> firewall side outside of the proxy testing from the demilitarized zone area. 
>> I wanted to test this first to rule that out as it’s coming in from that 
>> first and hits the proxy next
>> Sent from my iPhone
>> 
>>> On Jul 5, 2024, at 06:33, Alex Rousskov  
>>> wrote:
>>> 
>>> On 2024-07-04 19:12, Jonathan Lee wrote:
 You also stated .. " my current working theory suggests that we are 
 looking at a (default) signUntrusted use case.”
 I noticed for Squid documents that default is now set to off ..
>>> 
>>> The http_port option you are looking at now is not the directive I was 
>>> talking about earlier.
>>> 
 http_port
 tls-default-ca[=off]
  Whether to use the system Trusted CAs. Default is OFF.
 Would enabling this resolve the problem in Squid 6.6 for error.
>>> 
>>> 
>>> No, the above poorly documented http_port option is for validating _client_ 
>>> certificates. It has been off since Squid v4 AFAICT. Your clients are not 
>>> sending client certificates to Squid.
>>> 
>>> According to the working theory, the problem we are solving is related to 
>>> server certificates. http_port tls-default-ca option does not affect server 
>>> certificate validation. Server certificate validation should use default 
>>> CAs by default.
>>> 
>>> Outside of SslBump, server certificate validation is controlled by 
>>> tls_outgoing_options default-ca option. That option defaults to "on". I am 
>>> not sure whether SslBump honors that directive/option though. There are 
>>> known related bugs in that area. However, we are jumping ahead of 
>>> ourselves. We should confirm the working theory first.
>>> 
 The squid.conf.documented lists it incorrectly
>>> 
>>> Squid has many directives and a directive may have many options. One should 
>>> not use an directive option name instead of a directive name. One should 
>>> not use an option from one directive with another directive. Squid naming 
>>> is often inconsistent; be careful.
>>> 
>>> * http_port is a directive. tls-default-ca is an option for that directive. 
>>> It is used for client certificate validation. It defaults to "off" (because 
>>> client certificates are rarely signed by well-known (a.k.a. "default") CAs 
>>> preinstalled in many deployment environments).
>>> 
>>> * tls_outgoing_options is a directive. default-ca is an option for that 
>>> directive. It is used for server certificate validation outside of SslBump 
>>> contexts (at least!). It defaults to "on" (because server certificates are 
>>> usually signed by well-known (a.k.a. "default") CAs preinstalled in many 
>>> deployment environments).
>>> 
>>> AFAICT, the documentation in question is not wrong (but is insufficient).
>>> 
>>> Again, I do not recommend changing any Squid configuration 
>>> directives/options at this triage state.
>>> 
>>> Alex.
>>> 
> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ERROR: Unsupported TLS option SINGLE_ECDH_USE

[Jonathan Lee]

Does anyone know how to activate the TLS1.3 ciphers?

Per lists.squid-cache.org 

Ref:
https://lists.squid-cache.org/pipermail/squid-users/2018-February/017640.html
https://openssl.org/blog/blog/2017/05/04/tlsv1.3/

And CVE-2016-0701

"Yes. Due to CVE-2016-0701 the SSL_OP_SINGLE_DH_USE option was deprecated”

It is depreciated and the new pfSense package still shows it as a default 
option, however how does one append 

ppending
> "TLS13-AES-256-GCM-SHA384" to the ciphers.
> 
> But the log shows the use of "ECDHE-ECDSA-AES256-GCM-SHA384”


> On Jul 5, 2024, at 09:11, Jonathan Lee  wrote:
> 
> Wireshark shows Cipher Suite: TLS_AES_128_GCM_SHA256 is being used
> How would I append the TLS13-AES-256-CGM-SHA384 cipher suite for use with 
> TLSv1.3 as it states change cipher spec on wireshark
> 
>> On Jul 5, 2024, at 08:46, Jonathan Lee  wrote:
>> 
>> More details for Unsupported TLS option
>> 
>> When running squid -k parse
>> 
>> 2024/07/05 08:40:43| Processing: http_port 192.168.1.1:3128 ssl-bump 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
>> cert=/usr/local/etc/squid/serverkey.pem 
>> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
>> cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
>> 2024/07/05 08:40:43| UPGRADE WARNING: 
>> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
>> Use 'tls-cafile=' instead.
>> 2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_DH_USE
>> 2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_ECDH_USE
>> 2024/07/05 08:40:47| Processing: http_port 127.0.0.1:3128 intercept ssl-bump 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
>> cert=/usr/local/etc/squid/serverkey.pem 
>> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
>> cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
>> 2024/07/05 08:40:47| Starting Authentication on port 127.0.0.1:3128
>> 2024/07/05 08:40:47| Disabling Authentication on port 127.0.0.1:3128 
>> (interception enabled)
>> 2024/07/05 08:40:47| UPGRADE WARNING: 
>> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
>> Use 'tls-cafile=' instead.
>> 2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_DH_USE
>> 2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_ECDH_USE
>> 2024/07/05 08:40:51| Processing: https_port 127.0.0.1:3129 intercept 
>> ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
>> cert=/usr/local/etc/squid/serverkey.pem 
>> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
>> cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
>> 2024/07/05 08:40:51| Starting Authentication on port 127.0.0.1:3129
>> 2024/07/05 08:40:51| Disabling Authentication on port 127.0.0.1:3129 
>> (interception enabled)
>> 2024/07/05 08:40:51| UPGRADE WARNING: 
>> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in https_port. 
>> Use 'tls-cafile=' instead.
>> 2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_DH_USE
>> 2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_ECDH_USE
>> elliptic curve options are set below and I have inspected the file it is 
>> present. 
>> 
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> 
>>> On Jul 5, 2024, at 08:35, Jonathan Lee  wrote:
>>> 
>>> tls_outgoing_options 
>>> cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>>> tls_outgoing_options options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
>>> Different thread for ciphers issues
>>> 
>>> ERROR: Unsupported TLS option SINGLE_ECDH_USE
>>> 
>>> I found researching in lists-squid-cache.org 
>>>  that someone solved this error with 
>>> appending TLS13-AES-256-CGM-SHA384 to the ciphers. 
>>> 
>>> I am thinking this is my issue also.
>>> 
>>> I see that error over and over when I run "squid -k parse”
>>> 
>>> Do I append this to the options cipher list?
>>> 
>>> Does anyone know how to fix the 2 diffie-hellman key exchange algorithm 
>>> errors?
>>> 
>>> 
>>> 
>>> Jonathan Lee
>> 
> 

___
squid-users mailing list
squid-users@lists.squid-cache.org

Re: [squid-users] ERROR: Unsupported TLS option SINGLE_ECDH_USE

[Jonathan Lee]

Wireshark shows Cipher Suite: TLS_AES_128_GCM_SHA256 is being used
How would I append the TLS13-AES-256-CGM-SHA384 cipher suite for use with 
TLSv1.3 as it states change cipher spec on wireshark

> On Jul 5, 2024, at 08:46, Jonathan Lee  wrote:
> 
> More details for Unsupported TLS option
> 
> When running squid -k parse
> 
> 2024/07/05 08:40:43| Processing: http_port 192.168.1.1:3128 ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/05 08:40:43| UPGRADE WARNING: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
> Use 'tls-cafile=' instead.
> 2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 2024/07/05 08:40:47| Processing: http_port 127.0.0.1:3128 intercept ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/05 08:40:47| Starting Authentication on port 127.0.0.1:3128
> 2024/07/05 08:40:47| Disabling Authentication on port 127.0.0.1:3128 
> (interception enabled)
> 2024/07/05 08:40:47| UPGRADE WARNING: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
> Use 'tls-cafile=' instead.
> 2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 2024/07/05 08:40:51| Processing: https_port 127.0.0.1:3129 intercept ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/05 08:40:51| Starting Authentication on port 127.0.0.1:3129
> 2024/07/05 08:40:51| Disabling Authentication on port 127.0.0.1:3129 
> (interception enabled)
> 2024/07/05 08:40:51| UPGRADE WARNING: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in https_port. 
> Use 'tls-cafile=' instead.
> 2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> elliptic curve options are set below and I have inspected the file it is 
> present. 
> 
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> 
>> On Jul 5, 2024, at 08:35, Jonathan Lee  wrote:
>> 
>> tls_outgoing_options 
>> cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>> tls_outgoing_options options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
>> Different thread for ciphers issues
>> 
>> ERROR: Unsupported TLS option SINGLE_ECDH_USE
>> 
>> I found researching in lists-squid-cache.org  
>> that someone solved this error with appending TLS13-AES-256-CGM-SHA384 to 
>> the ciphers. 
>> 
>> I am thinking this is my issue also.
>> 
>> I see that error over and over when I run "squid -k parse”
>> 
>> Do I append this to the options cipher list?
>> 
>> Does anyone know how to fix the 2 diffie-hellman key exchange algorithm 
>> errors?
>> 
>> 
>> 
>> Jonathan Lee
> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Jonathan Lee]

per 

As the next step in triage, I recommend determining what that CA is in these 
cases (e.g., by capturing raw TLS packets and matching them with connection 
information from A000417 error messages in cache.log or %err_detail in 
access.log).


I have Wireshark running do I just look for information with ssl.handshake.type 
== 1

Or is there a wireshark particular filter you would like ran to help with 
isolation?



> On Jul 5, 2024, at 08:23, Jonathan Lee  wrote:
> 
> Thanks for the email and support with this. I will get wireshark running on 
> the client and get the info required. Yes the information prior is from the 
> firewall side outside of the proxy testing from the demilitarized zone area. 
> I wanted to test this first to rule that out as it’s coming in from that 
> first and hits the proxy next
> Sent from my iPhone
> 
>> On Jul 5, 2024, at 06:33, Alex Rousskov  
>> wrote:
>> 
>> On 2024-07-04 19:12, Jonathan Lee wrote:
>>> You also stated .. " my current working theory suggests that we are looking 
>>> at a (default) signUntrusted use case.”
>>> I noticed for Squid documents that default is now set to off ..
>> 
>> The http_port option you are looking at now is not the directive I was 
>> talking about earlier.
>> 
>>> http_port
>>> tls-default-ca[=off]
>>>   Whether to use the system Trusted CAs. Default is OFF.
>>> Would enabling this resolve the problem in Squid 6.6 for error.
>> 
>> 
>> No, the above poorly documented http_port option is for validating _client_ 
>> certificates. It has been off since Squid v4 AFAICT. Your clients are not 
>> sending client certificates to Squid.
>> 
>> According to the working theory, the problem we are solving is related to 
>> server certificates. http_port tls-default-ca option does not affect server 
>> certificate validation. Server certificate validation should use default CAs 
>> by default.
>> 
>> Outside of SslBump, server certificate validation is controlled by 
>> tls_outgoing_options default-ca option. That option defaults to "on". I am 
>> not sure whether SslBump honors that directive/option though. There are 
>> known related bugs in that area. However, we are jumping ahead of ourselves. 
>> We should confirm the working theory first.
>> 
>>> The squid.conf.documented lists it incorrectly
>> 
>> Squid has many directives and a directive may have many options. One should 
>> not use an directive option name instead of a directive name. One should not 
>> use an option from one directive with another directive. Squid naming is 
>> often inconsistent; be careful.
>> 
>> * http_port is a directive. tls-default-ca is an option for that directive. 
>> It is used for client certificate validation. It defaults to "off" (because 
>> client certificates are rarely signed by well-known (a.k.a. "default") CAs 
>> preinstalled in many deployment environments).
>> 
>> * tls_outgoing_options is a directive. default-ca is an option for that 
>> directive. It is used for server certificate validation outside of SslBump 
>> contexts (at least!). It defaults to "on" (because server certificates are 
>> usually signed by well-known (a.k.a. "default") CAs preinstalled in many 
>> deployment environments).
>> 
>> AFAICT, the documentation in question is not wrong (but is insufficient).
>> 
>> Again, I do not recommend changing any Squid configuration 
>> directives/options at this triage state.
>> 
>> Alex.
>> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ERROR: Unsupported TLS option SINGLE_ECDH_USE

[Jonathan Lee]

More details for Unsupported TLS option

When running squid -k parse

2024/07/05 08:40:43| Processing: http_port 192.168.1.1:3128 ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/05 08:40:43| UPGRADE WARNING: 
'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. Use 
'tls-cafile=' instead.
2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_DH_USE
2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_ECDH_USE
2024/07/05 08:40:47| Processing: http_port 127.0.0.1:3128 intercept ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/05 08:40:47| Starting Authentication on port 127.0.0.1:3128
2024/07/05 08:40:47| Disabling Authentication on port 127.0.0.1:3128 
(interception enabled)
2024/07/05 08:40:47| UPGRADE WARNING: 
'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. Use 
'tls-cafile=' instead.
2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_DH_USE
2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_ECDH_USE
2024/07/05 08:40:51| Processing: https_port 127.0.0.1:3129 intercept ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/05 08:40:51| Starting Authentication on port 127.0.0.1:3129
2024/07/05 08:40:51| Disabling Authentication on port 127.0.0.1:3129 
(interception enabled)
2024/07/05 08:40:51| UPGRADE WARNING: 
'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in https_port. 
Use 'tls-cafile=' instead.
2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_DH_USE
2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_ECDH_USE
elliptic curve options are set below and I have inspected the file it is 
present. 

 tls-dh=prime256v1:/etc/dh-parameters.2048 

> On Jul 5, 2024, at 08:35, Jonathan Lee  wrote:
> 
> tls_outgoing_options 
> cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
> tls_outgoing_options options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> Different thread for ciphers issues
> 
> ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 
> I found researching in lists-squid-cache.org  
> that someone solved this error with appending TLS13-AES-256-CGM-SHA384 to the 
> ciphers. 
> 
> I am thinking this is my issue also.
> 
> I see that error over and over when I run "squid -k parse”
> 
> Do I append this to the options cipher list?
> 
> Does anyone know how to fix the 2 diffie-hellman key exchange algorithm 
> errors?
> 
> 
> 
> Jonathan Lee

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

[squid-users] ERROR: Unsupported TLS option SINGLE_ECDH_USE

[Jonathan Lee]

tls_outgoing_options cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSStls_outgoing_options options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USEDifferent thread for ciphers issuesERROR: Unsupported TLS option SINGLE_ECDH_USEI found researching in lists-squid-cache.org that someone solved this error with appending TLS13-AES-256-CGM-SHA384 to the ciphers. I am thinking this is my issue also.I see that error over and over when I run "squid -k parse”Do I append this to the options cipher list?Does anyone know how to fix the 2 diffie-hellman key exchange algorithm errors?Jonathan Lee___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid as http to https forward proxy

[Alex Rousskov]

On 2024-07-05 10:15, Wagner, Juergen03 wrote:


FWIW, I do not know why URL scheme rewriting does not work in your use case. In 
principle, bugs notwithstanding, I would expect URL scheme rewriting to work. In 
my original response, I was focusing on avoiding rewrites for a case where they 
should not be >needed because they should not be needed (in that use case) and 
because they did not work (in your specific tests), but _not_ because they should 
not work in principle or on some fundamental level.



Do you expect that by just changing the URL scheme from http to https Squid is 
doing the encryption and decryption of the data?


Yes, I do expect Squid to honor the new URL scheme. Honoring rewriter 
instructions is natural, but there is more to the story here: Bugs 
notwithstanding, Squid is already capable for receiving a plain text 
"GET https://...; request on http_port and doing the encryption when 
talking to the requested TLS origin server. What your rewriter is doing 
feels very similar to that GET-https use case!




My suspicion was or is, that Squid is just forwarding the unencrypted data form 
the http client to the https server.


IMO, that would be a Squid bug in this case.



How can I check this when generating the Squid logs with "debug_options ALL,9"


You should not. Debugging logs are for Squid developers. Me or others 
will check if you share the logs. Share privately if needed and/or use 
fake/temporary keys/passwords/etc. to avoid leaking something sensitive. 
There are a few relevant hints at


https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction


HTH,

Alex.



<<
FWIW, I do not know why URL scheme rewriting does not work in your use case. In 
principle, bugs notwithstanding, I would expect URL scheme rewriting to work. 
In my original response, I was focusing on avoiding rewrites for a case where 
they should not be needed because they should not be needed (in that use case) 
and because they did not work (in your specific tests), but _not_ because they 
should not work in principle or on some fundamental level.




Internal
-Original Message-
From: Alex Rousskov 
Sent: Freitag, 5. Juli 2024 15:52
To: Wagner, Juergen03 ; 
squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid as http to https forward proxy

CAUTION: This is an external email. Do not click or open any attachments unless 
you recognize the sender and know that the content is safe. 
(http://links.conti.de/mailcheck)


On 2024-07-05 09:16, Wagner, Juergen03 wrote:


Actually we want to be able to connect to any remote server.
So we are not looking for a solution with a "single true origin server".


Thank you for clarifying that.



My current understanding from your response is, that a simple
url-rewrite only, as we tried, is not working to forward http requests
form a client to any https server.


FWIW, I do not know why URL scheme rewriting does not work in your use case. In 
principle, bugs notwithstanding, I would expect URL scheme rewriting to work. 
In my original response, I was focusing on avoiding rewrites for a case where 
they should not be needed because they should not be needed (in that use case) 
and because they did not work (in your specific tests), but _not_ because they 
should not work in principle or on some fundamental level.



Just to be clear, is the usage of Squid as a forward http proxy for a
client while using https for external communication possible without
any Squid code changes?


That particular question covers several different scenarios. Your use case is 
one of them. The answer for your specific use case is unknown (to me) -- I 
would expect URL scheme rewrites to work but they do not in your test. I do not 
know why.



Alex: At some point, depending on the use case, it will be easier to
enhance Squid to encrypt plain HTTP requests


That comment still applies. However, if you would prefer to avoid (or at least reduce) Squid code 
modifications, it may be useful to triage why scheme rewrites do not work in your tests. In other words, why 
Squid generates a "Bad Gateway" error when the rewriter changes request URL scheme from 
"http" to "https". Sharing a pointer to compressed cache.log collected with debug_options 
set to ALL,9 while reproducing the problem with a single test transaction may be the best next step.


HTH,

Alex.



-Original Message-
From: squid-users  On
Behalf Of Alex Rousskov
Sent: Donnerstag, 4. Juli 2024 18:43
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid as http to https forward proxy

CAUTION: This is an external email. Do not click or open any
attachments unless you recognize the sender and know that the content
is safe. (http://links.conti.de/mailcheck)


On 2024-07-04 12:36, Alex Rousskov wrote:

On 2024-07-04 10:58, Matus UHLAR - fantomas wrote:

On 2024-07-04 09:20, Wagner, Juergen03 wrote:

we are evaluating Squid to be used as a http to https forward proxy.

So 

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Jonathan Lee]

Thanks for the email and support with this. I will get wireshark running on the 
client and get the info required. Yes the information prior is from the 
firewall side outside of the proxy testing from the demilitarized zone area. I 
wanted to test this first to rule that out as it’s coming in from that first 
and hits the proxy next
Sent from my iPhone

> On Jul 5, 2024, at 06:33, Alex Rousskov  
> wrote:
> 
> On 2024-07-04 19:12, Jonathan Lee wrote:
>> You also stated .. " my current working theory suggests that we are looking 
>> at a (default) signUntrusted use case.”
>> I noticed for Squid documents that default is now set to off ..
> 
> The http_port option you are looking at now is not the directive I was 
> talking about earlier.
> 
> > http_port
>>   tls-default-ca[=off]
>>Whether to use the system Trusted CAs. Default is OFF.
>> Would enabling this resolve the problem in Squid 6.6 for error.
> 
> 
> No, the above poorly documented http_port option is for validating _client_ 
> certificates. It has been off since Squid v4 AFAICT. Your clients are not 
> sending client certificates to Squid.
> 
> According to the working theory, the problem we are solving is related to 
> server certificates. http_port tls-default-ca option does not affect server 
> certificate validation. Server certificate validation should use default CAs 
> by default.
> 
> Outside of SslBump, server certificate validation is controlled by 
> tls_outgoing_options default-ca option. That option defaults to "on". I am 
> not sure whether SslBump honors that directive/option though. There are known 
> related bugs in that area. However, we are jumping ahead of ourselves. We 
> should confirm the working theory first.
> 
> > The squid.conf.documented lists it incorrectly
> 
> Squid has many directives and a directive may have many options. One should 
> not use an directive option name instead of a directive name. One should not 
> use an option from one directive with another directive. Squid naming is 
> often inconsistent; be careful.
> 
> * http_port is a directive. tls-default-ca is an option for that directive. 
> It is used for client certificate validation. It defaults to "off" (because 
> client certificates are rarely signed by well-known (a.k.a. "default") CAs 
> preinstalled in many deployment environments).
> 
> * tls_outgoing_options is a directive. default-ca is an option for that 
> directive. It is used for server certificate validation outside of SslBump 
> contexts (at least!). It defaults to "on" (because server certificates are 
> usually signed by well-known (a.k.a. "default") CAs preinstalled in many 
> deployment environments).
> 
> AFAICT, the documentation in question is not wrong (but is insufficient).
> 
> Again, I do not recommend changing any Squid configuration directives/options 
> at this triage state.
> 
> Alex.
> 
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid as http to https forward proxy

[Wagner, Juergen03]

>FWIW, I do not know why URL scheme rewriting does not work in your use case. 
>In principle, bugs notwithstanding, I would expect URL scheme rewriting to 
>work. In my original response, I was focusing on avoiding rewrites for a case 
>where they should not be >needed because they should not be needed (in that 
>use case) and because they did not work (in your specific tests), but _not_ 
>because they should not work in principle or on some fundamental level.

Do you expect that by just changing the URL scheme from http to https Squid is 
doing the encryption and decryption of the data?
My suspicion was or is, that Squid is just forwarding the unencrypted data form 
the http client to the https server.

How can I check this when generating the Squid logs with "debug_options ALL, 9"

Regards,
Juergen


<<
FWIW, I do not know why URL scheme rewriting does not work in your use case. In 
principle, bugs notwithstanding, I would expect URL scheme rewriting to work. 
In my original response, I was focusing on avoiding rewrites for a case where 
they should not be needed because they should not be needed (in that use case) 
and because they did not work (in your specific tests), but _not_ because they 
should not work in principle or on some fundamental level.
>>

Internal
-Original Message-
From: Alex Rousskov 
Sent: Freitag, 5. Juli 2024 15:52
To: Wagner, Juergen03 ; 
squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid as http to https forward proxy

CAUTION: This is an external email. Do not click or open any attachments unless 
you recognize the sender and know that the content is safe. 
(http://links.conti.de/mailcheck)


On 2024-07-05 09:16, Wagner, Juergen03 wrote:

> Actually we want to be able to connect to any remote server.
> So we are not looking for a solution with a "single true origin server".

Thank you for clarifying that.


> My current understanding from your response is, that a simple
> url-rewrite only, as we tried, is not working to forward http requests
> form a client to any https server.

FWIW, I do not know why URL scheme rewriting does not work in your use case. In 
principle, bugs notwithstanding, I would expect URL scheme rewriting to work. 
In my original response, I was focusing on avoiding rewrites for a case where 
they should not be needed because they should not be needed (in that use case) 
and because they did not work (in your specific tests), but _not_ because they 
should not work in principle or on some fundamental level.


> Just to be clear, is the usage of Squid as a forward http proxy for a
> client while using https for external communication possible without
> any Squid code changes?

That particular question covers several different scenarios. Your use case is 
one of them. The answer for your specific use case is unknown (to me) -- I 
would expect URL scheme rewrites to work but they do not in your test. I do not 
know why.


> Alex: At some point, depending on the use case, it will be easier to
> enhance Squid to encrypt plain HTTP requests

That comment still applies. However, if you would prefer to avoid (or at least 
reduce) Squid code modifications, it may be useful to triage why scheme 
rewrites do not work in your tests. In other words, why Squid generates a "Bad 
Gateway" error when the rewriter changes request URL scheme from "http" to 
"https". Sharing a pointer to compressed cache.log collected with debug_options 
set to ALL,9 while reproducing the problem with a single test transaction may 
be the best next step.


HTH,

Alex.


> -Original Message-
> From: squid-users  On
> Behalf Of Alex Rousskov
> Sent: Donnerstag, 4. Juli 2024 18:43
> To: squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] Squid as http to https forward proxy
>
> CAUTION: This is an external email. Do not click or open any
> attachments unless you recognize the sender and know that the content
> is safe. (http://links.conti.de/mailcheck)
>
>
> On 2024-07-04 12:36, Alex Rousskov wrote:
>> On 2024-07-04 10:58, Matus UHLAR - fantomas wrote:
 On 2024-07-04 09:20, Wagner, Juergen03 wrote:
> we are evaluating Squid to be used as a http to https forward proxy.
>
> So Squid would need to support the following setup:
>
>  http (client)>   Squid  --->  https ( server )
>
> Could someone please confirm if the given setup is in principle
> possible with Squid?
>
> If yes, which configuration needs to be done?
>>>
>>> On 04.07.24 10:36, Alex Rousskov wrote:
 Yes, Squid should be able to forward plain text HTTP requests
 to a secure server. Use cache_peer directive with "tls" and "originserver"
 flags. Here is an untested sketch:

 # routing all traffic to one HTTPS origin server
 cache_peer 127.0.0.1 parent 443 0 tls originserver \
 name=MySecureOrigin \
 no-query no-digest
 cache_peer_access MySecureOrigin allow all
 

Re: [squid-users] Squid as http to https forward proxy

[Alex Rousskov]

On 2024-07-05 09:16, Wagner, Juergen03 wrote:


Actually we want to be able to connect to any remote server.
So we are not looking for a solution with a "single true origin server".


Thank you for clarifying that.



My current understanding from your response is, that a simple
url-rewrite only, as we tried, is not working to forward http
requests form a client to any https server.


FWIW, I do not know why URL scheme rewriting does not work in your use 
case. In principle, bugs notwithstanding, I would expect URL scheme 
rewriting to work. In my original response, I was focusing on avoiding 
rewrites for a case where they should not be needed because they should 
not be needed (in that use case) and because they did not work (in your 
specific tests), but _not_ because they should not work in principle or 
on some fundamental level.




Just to be clear, is the usage of Squid as a forward http proxy for a
client while using https for external communication possible without
any Squid code changes?


That particular question covers several different scenarios. Your use 
case is one of them. The answer for your specific use case is unknown 
(to me) -- I would expect URL scheme rewrites to work but they do not in 
your test. I do not know why.




Alex: At some point, depending on the use case, it will be easier to
enhance Squid to encrypt plain HTTP requests


That comment still applies. However, if you would prefer to avoid (or at 
least reduce) Squid code modifications, it may be useful to triage why 
scheme rewrites do not work in your tests. In other words, why Squid 
generates a "Bad Gateway" error when the rewriter changes request URL 
scheme from "http" to "https". Sharing a pointer to compressed cache.log 
collected with debug_options set to ALL,9 while reproducing the problem 
with a single test transaction may be the best next step.



HTH,

Alex.



-Original Message-
From: squid-users  On Behalf Of Alex 
Rousskov
Sent: Donnerstag, 4. Juli 2024 18:43
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid as http to https forward proxy

CAUTION: This is an external email. Do not click or open any attachments unless 
you recognize the sender and know that the content is safe. 
(http://links.conti.de/mailcheck)


On 2024-07-04 12:36, Alex Rousskov wrote:

On 2024-07-04 10:58, Matus UHLAR - fantomas wrote:

On 2024-07-04 09:20, Wagner, Juergen03 wrote:

we are evaluating Squid to be used as a http to https forward proxy.

So Squid would need to support the following setup:

 http (client)>   Squid  --->  https ( server )

Could someone please confirm if the given setup is in principle
possible with Squid?

If yes, which configuration needs to be done?


On 04.07.24 10:36, Alex Rousskov wrote:

Yes, Squid should be able to forward plain text HTTP requests to
a secure server. Use cache_peer directive with "tls" and "originserver"
flags. Here is an untested sketch:

# routing all traffic to one HTTPS origin server
cache_peer 127.0.0.1 parent 443 0 tls originserver \
name=MySecureOrigin \
no-query no-digest
cache_peer_access MySecureOrigin allow all
always_direct deny all
never_direct allow all
nonhierarchical_direct off


Afaik this means that it is not possible with any remote server,
because all servers you want to access this way must be explicitly
set up in squid.conf, correct?


I assumed (possibly incorrectly) that Juergen was asking about a
single "true origin server" (e.g., example.com). The above example was
written with a single "true origin server" in mind. However, exactly
the same Squid configuration may work to forward traffic to a reverse
proxy (running at 127.0.0.1 on port 443) that "represents"
multiple/different "true origin servers".

That reverse proxy will need to shovel TLS bytes received from Squid
to the right "true origin server", but I am guessing that it can do
that based on TLS SNI supplied by Squid. Some Squid code modifications
may be necessary to make this work correctly with persistent
Squid-to-peer connections and such, but nothing major AFAICT (and they
can be turned off using server_persistent_connections if they are in the way).

AFAICT, with either SslBump or some Squid code modifications, that
reverse proxy can be a Squid proxy. With even more Squid enhancements,
that reverse proxy can also become an https_port on the same Squid
proxy instance where the http_port receives plain HTTP requests!


At some point, depending on the use case, it will be easier to enhance Squid to 
encrypt plain HTTP requests without using this TLS cache_peer hack, of course.

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Alex Rousskov]

On 2024-07-04 19:12, Jonathan Lee wrote:
You also stated .. " my current working theory suggests that we are 
looking at a (default) signUntrusted use case.”


I noticed for Squid documents that default is now set to off ..


The http_port option you are looking at now is not the directive I was 
talking about earlier.


> http_port

   tls-default-ca[=off]
Whether to use the system Trusted CAs. Default is OFF.

Would enabling this resolve the problem in Squid 6.6 for error.



No, the above poorly documented http_port option is for validating 
_client_ certificates. It has been off since Squid v4 AFAICT. Your 
clients are not sending client certificates to Squid.


According to the working theory, the problem we are solving is related 
to server certificates. http_port tls-default-ca option does not affect 
server certificate validation. Server certificate validation should use 
default CAs by default.


Outside of SslBump, server certificate validation is controlled by 
tls_outgoing_options default-ca option. That option defaults to "on". I 
am not sure whether SslBump honors that directive/option though. There 
are known related bugs in that area. However, we are jumping ahead of 
ourselves. We should confirm the working theory first.


> The squid.conf.documented lists it incorrectly

Squid has many directives and a directive may have many options. One 
should not use an directive option name instead of a directive name. One 
should not use an option from one directive with another directive. 
Squid naming is often inconsistent; be careful.


* http_port is a directive. tls-default-ca is an option for that 
directive. It is used for client certificate validation. It defaults to 
"off" (because client certificates are rarely signed by well-known 
(a.k.a. "default") CAs preinstalled in many deployment environments).


* tls_outgoing_options is a directive. default-ca is an option for that 
directive. It is used for server certificate validation outside of 
SslBump contexts (at least!). It defaults to "on" (because server 
certificates are usually signed by well-known (a.k.a. "default") CAs 
preinstalled in many deployment environments).


AFAICT, the documentation in question is not wrong (but is insufficient).

Again, I do not recommend changing any Squid configuration 
directives/options at this triage state.


Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid as http to https forward proxy

[Wagner, Juergen03]

Hello,
thanks a lot for the fast responses.
Actually we want to be able to connect to any remote server.
So we are not looking for a solution with a "single true origin server".

My current understanding from your response is,
that a simple url-rewrite only, as we tried, is not working to forward http 
requests form a client to any https server.

Just to be clear, is the usage of Squid as a forward http proxy for a client 
while using https for external communication possible without any Squid code 
changes?
Could the Squid configuration directive "http_port" in combination with the 
mode "accel" be used to support that use case?

Maybe Alex' last statement is the solution:
<<
At some point, depending on the use case,
it will be easier to enhance Squid to encrypt plain HTTP requests without using 
this TLS cache_peer hack, of course
>>

Regards,
Juergen



Internal
-Original Message-
From: squid-users  On Behalf Of Alex 
Rousskov
Sent: Donnerstag, 4. Juli 2024 18:43
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Squid as http to https forward proxy

CAUTION: This is an external email. Do not click or open any attachments unless 
you recognize the sender and know that the content is safe. 
(http://links.conti.de/mailcheck)


On 2024-07-04 12:36, Alex Rousskov wrote:
> On 2024-07-04 10:58, Matus UHLAR - fantomas wrote:
>>> On 2024-07-04 09:20, Wagner, Juergen03 wrote:
 we are evaluating Squid to be used as a http to https forward proxy.

 So Squid would need to support the following setup:

 http (client)>   Squid  --->  https ( server )

 Could someone please confirm if the given setup is in principle
 possible with Squid?

 If yes, which configuration needs to be done?
>>
>> On 04.07.24 10:36, Alex Rousskov wrote:
>>>Yes, Squid should be able to forward plain text HTTP requests to
>>> a secure server. Use cache_peer directive with "tls" and "originserver"
>>> flags. Here is an untested sketch:
>>>
>>># routing all traffic to one HTTPS origin server
>>>cache_peer 127.0.0.1 parent 443 0 tls originserver \
>>>name=MySecureOrigin \
>>>no-query no-digest
>>>cache_peer_access MySecureOrigin allow all
>>>always_direct deny all
>>>never_direct allow all
>>>nonhierarchical_direct off
>>
>> Afaik this means that it is not possible with any remote server,
>> because all servers you want to access this way must be explicitly
>> set up in squid.conf, correct?
>
> I assumed (possibly incorrectly) that Juergen was asking about a
> single "true origin server" (e.g., example.com). The above example was
> written with a single "true origin server" in mind. However, exactly
> the same Squid configuration may work to forward traffic to a reverse
> proxy (running at 127.0.0.1 on port 443) that "represents"
> multiple/different "true origin servers".
>
> That reverse proxy will need to shovel TLS bytes received from Squid
> to the right "true origin server", but I am guessing that it can do
> that based on TLS SNI supplied by Squid. Some Squid code modifications
> may be necessary to make this work correctly with persistent
> Squid-to-peer connections and such, but nothing major AFAICT (and they
> can be turned off using server_persistent_connections if they are in the way).
>
> AFAICT, with either SslBump or some Squid code modifications, that
> reverse proxy can be a Squid proxy. With even more Squid enhancements,
> that reverse proxy can also become an https_port on the same Squid
> proxy instance where the http_port receives plain HTTP requests!

At some point, depending on the use case, it will be easier to enhance Squid to 
encrypt plain HTTP requests without using this TLS cache_peer hack, of course.

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Alex Rousskov]

On 2024-07-04 19:02, Jonathan Lee wrote:
I do not recommend changing your configuration at this time. I 
recommend rereading my earlier recommendation and following that 
instead: "As the next step in triage, I recommend determining what 
that CA is in these cases (e.g., by capturing raw TLS packets and 
matching them with connection information from A000417 error 
messages in cache.log or %err_detail in access.log)."


Ok I went back to 5.8 and ran the following command after I removed the 
changes I used does this help this is ran on the firewall side itself.


  openssl s_client -connect foxnews.com:443

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
Root CA


Did the above connection go through Squid? Sorry, I do not know whether 
"on the firewall side itself" implies a "yes" or "no" answer in this 
test case.




Does that help


It does not hurt, but it is not the information I have requested for the 
next triage step: I asked about the certificate corresponding to the 
A000417 error message in Squid v6.6. You are sharing the certificate 
corresponding to either a direct connection to the origin server or the 
certificate corresponding to a problem-free connection through Squid v5.8.



Should I regenerate a new certificate for the new version of Squid and 
redeploy them all to hosts again?


IMHO, on this thread, you should follow the recommended triage steps. If 
those recommendations are problematic, please discuss.


Alex.


On Jul 4, 2024, at 14:45, Alex Rousskov 
 wrote:


On 2024-07-04 15:37, Jonathan Lee wrote:


in Squid.conf I have nothing with that detective.


Sounds good; sslproxy_cert_sign default should work OK in most 
cases. I mentioned signUntrusted algorithm so that you can discover 
(from the corresponding sslproxy_cert_sign documentation) which 
CA/certificate Squid uses in which SslBump use case. Triage is often 
easier if folks share the same working theory, and my current 
working theory suggests that we are looking at a (default) 
signUntrusted use case.


The solution here probably does _not_ involve changing 
sslproxy_cert_sign configuration, but, to make progress, I need more 
info to confirm this working theory and describe next steps.




Yes I am using SSL bump with this configuration..


Noted, thank you.



So would I use this directive


I do not recommend changing your configuration at this time. I 
recommend rereading my earlier recommendation and following that 
instead: "As the next step in triage, I recommend determining what 
that CA is in these cases (e.g., by capturing raw TLS packets and 
matching them with connection information from A000417 error 
messages in cache.log or %err_detail in access.log)."



HTH,

Alex.



On Jul 4, 2024, at 09:56, Alex Rousskov wrote:

On 2024-07-04 12:11, Jonathan Lee wrote:
failure while accepting a TLS connection on conn5887 
local=192.168.1.1:3128

SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417


A000417 is an "unknown CA" alert sent by client to Squid while the 
client is trying to establish a TLS connection to/through Squid. 
The client does not trust the Certificate Authority that signed 
the certificate that was used for that TLS connection.


As the next step in triage, I recommend determining what that CA 
is in these cases (e.g., by capturing raw TLS packets and matching 
them with connection information from A000417 error messages in 
cache.log or %err_detail in access.log).


If you use SslBump for port 3128 traffic, then one of the 
possibilities here is that Squid is using an unknown-to-client CA 
to report an origin server that Squid itself does not trust (see 
signUntrusted in squid.conf.documented). In those cases, logging a 
level-1 ERROR is a Squid bug because that expected/desirable 
outcome should be treated as success (and a successful TLS accept 
treated as an error!).



HTH,

Alex.




Is my main concern however I use the squid guard URL blocker
Sent from my iPhone
On Jul 4, 2024, at 07:41, Alex Rousskov 
 wrote:


On 2024-07-03 13:56, Jonathan Lee wrote:

Hello fellow Squid users does anyone know how to fix this issue?


I counted about eight different "issues" in your cache.log 
sample. Most of them are probably independent. I recommend that 
you explicitly pick _one_, search mailing list archives for 
previous discussions about it, and then provide as many details 
about it as you can (e.g., what traffic causes it and/or 
matching access.log records).



HTH,

Alex.



Squid - Cache Logs
Date-Time    Message
31.12.1969 16:00:00
03.07.2024 10:54:34    kick abandoning 
conn7853 local=192.168.1.1:3128 remote=192.168.1.5:49710 FD 89 
flags=1

31.12.1969 16:00:00
03.07.2024 10:54:29    kick abandoning 
conn7844 local=192.168.1.1:3128 remote=192.168.1.5:49702 FD 81 
flags=1
03.07.2024 10:54:09    ERROR: failure while accepting a TLS 
connection on conn7648 local=192.168.1.1:3128 
remote=192.168.1.5:49672 FD 44 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

[Alex Rousskov]

On 2024-07-04 18:12, Jonathan Lee wrote:

I know before I could use

tls_outgoing_options 
cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS


However with the update I am seeing

ERROR: Unsupported TLS option SINGLE_ECDH_USE


FWIW, I can only (try to) help with one problem at this time. If you 
really want to attack two problems concurrently, I recommend starting 
another/new thread dedicated to the above problem. Others may be able to 
help you on that other thread.


Alex.

I found researching in lists-squid-cache.org 
 that someone solved this with appending 
TLS13-AES-256-CGM-SHA384 to the ciphers.


I am thinking this is my issue also.

I see that error over and over when I run "squid -k parse”

Do I append this to the options cipher list?

Jonathan Lee

On Jul 4, 2024, at 14:45, Alex Rousskov 
 wrote:


On 2024-07-04 15:37, Jonathan Lee wrote:


in Squid.conf I have nothing with that detective.


Sounds good; sslproxy_cert_sign default should work OK in most cases. 
I mentioned signUntrusted algorithm so that you can discover (from the 
corresponding sslproxy_cert_sign documentation) which CA/certificate 
Squid uses in which SslBump use case. Triage is often easier if folks 
share the same working theory, and my current working theory suggests 
that we are looking at a (default) signUntrusted use case.


The solution here probably does _not_ involve changing 
sslproxy_cert_sign configuration, but, to make progress, I need more 
info to confirm this working theory and describe next steps.




Yes I am using SSL bump with this configuration..


Noted, thank you.



So would I use this directive


I do not recommend changing your configuration at this time. I 
recommend rereading my earlier recommendation and following that 
instead: "As the next step in triage, I recommend determining what 
that CA is in these cases (e.g., by capturing raw TLS packets and 
matching them with connection information from A000417 error messages 
in cache.log or %err_detail in access.log)."



HTH,

Alex.



On Jul 4, 2024, at 09:56, Alex Rousskov wrote:

On 2024-07-04 12:11, Jonathan Lee wrote:
failure while accepting a TLS connection on conn5887 
local=192.168.1.1:3128

SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417


A000417 is an "unknown CA" alert sent by client to Squid while the 
client is trying to establish a TLS connection to/through Squid. The 
client does not trust the Certificate Authority that signed the 
certificate that was used for that TLS connection.


As the next step in triage, I recommend determining what that CA is 
in these cases (e.g., by capturing raw TLS packets and matching them 
with connection information from A000417 error messages in cache.log 
or %err_detail in access.log).


If you use SslBump for port 3128 traffic, then one of the 
possibilities here is that Squid is using an unknown-to-client CA to 
report an origin server that Squid itself does not trust (see 
signUntrusted in squid.conf.documented). In those cases, logging a 
level-1 ERROR is a Squid bug because that expected/desirable outcome 
should be treated as success (and a successful TLS accept treated as 
an error!).



HTH,

Alex.




Is my main concern however I use the squid guard URL blocker
Sent from my iPhone
On Jul 4, 2024, at 07:41, Alex Rousskov 
 wrote:


On 2024-07-03 13:56, Jonathan Lee wrote:

Hello fellow Squid users does anyone know how to fix this issue?


I counted about eight different "issues" in your cache.log sample. 
Most of them are probably independent. I recommend that you 
explicitly pick _one_, search mailing list archives for previous 
discussions about it, and then provide as many details about it as 
you can (e.g., what traffic causes it and/or matching access.log 
records).



HTH,

Alex.



Squid - Cache Logs
Date-Time    Message
31.12.1969 16:00:00
03.07.2024 10:54:34    kick abandoning 
conn7853 local=192.168.1.1:3128 remote=192.168.1.5:49710 FD 89 
flags=1

31.12.1969 16:00:00
03.07.2024 10:54:29    kick abandoning 
conn7844 local=192.168.1.1:3128 remote=192.168.1.5:49702 FD 81 
flags=1
03.07.2024 10:54:09    ERROR: failure while accepting a TLS 
connection on conn7648 local=192.168.1.1:3128 
remote=192.168.1.5:49672 FD 44 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:54:09    ERROR: failure while accepting a TLS 
connection on conn7647 local=192.168.1.1:3128 
remote=192.168.1.5:49670 FD 43 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:54:09    ERROR: failure while accepting a TLS 
connection on conn7646 local=192.168.1.1:3128 
remote=192.168.1.5:49668 FD 34 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:53:04    ERROR: failure while accepting a TLS 
connection on conn7367 local=192.168.1.1:3128