subject:"\[squid\-users\] squid cache"

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 direc

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

2024-07-05 Thread 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

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

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] Squid Cache Issues migration from 5.8 to 6.6

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] Squid Cache Issues migration from 5.8 to 6.6

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

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


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

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

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

It does not recognize this directive 

2024/07/04 16:16:46| Processing: url_rewrite_children 32 startup=8 idle=4 
concurrency=0
2024/07/04 16:16:46| Processing: tls-default-ca on
2024/07/04 16:16:46| /usr/local/etc/squid/squid.conf(235): unrecognized: 
'tls-default-ca’

Or with use of =

> On Jul 4, 2024, at 16: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 ..
> 
> http://www.squid-cache.org/Versions/v5/cfgman/http_port.html
> 
> http://www.squid-cache.org/Versions/v6/cfgman/http_port.html
>   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. In theory if 
> default is auto off and it is attempting to use one it would be untrusted 
> automagically after migration
> 
>> On Jul 4, 2024, at 14:45, Alex Rousskov  
>> wrote:
>> 
>>  my current working theory suggests that we are looking at a (default) 
>> signUntrusted use case.
> 

___
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

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

http://www.squid-cache.org/Versions/v5/cfgman/http_port.html

http://www.squid-cache.org/Versions/v6/cfgman/http_port.html
  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. In theory if 
default is auto off and it is attempting to use one it would be untrusted 
automagically after migration

> On Jul 4, 2024, at 14:45, Alex Rousskov  
> wrote:
> 
>  my current working theory suggests that we are looking at a (default) 
> signUntrusted use case.

___
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

>>> 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 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:
>

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

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 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-TimeMessage
>>> 31.12.1969 16:00:00
>>> 03.07.2024 10:54:34kick 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:29kick abandoning conn7844 local=192.168.1.1:3128 
>>> remote=192.168.1.5:49702 FD 81 flags=1
>>> 03.07.2024 10:54:09ERROR: 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:09ERROR: failure while accepting a TLS

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

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 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-TimeMessage
>> 31.12.1969 16:00:00
>> 03.07.2024 10:54:34kick 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:29kick abandoning conn7844 local=192.168.1.1:3128 
>> remote=192.168.1.5:49702 FD 81 flags=1
>> 03.07.2024 10:54:09ERROR: 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:09ERROR: 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:09ERROR: 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

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

2024-07-04 Thread Alex Rousskov


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 
remote=192.168.1.5:49627 FD 22 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:52:47    ERROR: failure while accepting a TLS 
connection on conn7345 local=192.168.1.1:3128 
remote=192.168.1.5:49618 FD 31 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:52:38    ERROR: failure while accepting a TLS 
connection on conn7340 local=192.168.1.1:3128 
remote=192.168.1.5:49616 FD 45 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
03.07.2024 10:52:34    ERROR: failure while accepting a TLS 
connection on conn7316 local=192.168.1.1:3128 
remote=192.168.1.5:49609 FD 45 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1

31.12.1969 16:00:00
03.07.2024 10:51:55    WARNING: Error Pages Missing Language: en-us
31.12.1969 16:00:00
03.07.2024 10:51:55    ERROR: loading file 
9;/usr/local/etc/squid/errors/en-us/ERR_ZERO_SIZE_OBJECT': (2) No 
such file or directory
03.07.2024 10:51:44    ERROR: failure while accepting a TLS 
connection on conn7102

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

Maybe adding it like this …

sslproxy_cert_sign signTrusted bump_only_mac https_login splice_only_mac 
NoBumpDNS NoSSLIntercept
ssl_bump peek step1
miss_access deny no_miss active_use
ssl_bump splice https_login active_use
ssl_bump splice splice_only_mac splice_only active_use
ssl_bump splice NoBumpDNS active_use
ssl_bump splice NoSSLIntercept active_use
ssl_bump bump bump_only_mac bump_only active_use
acl activated note active_use true
ssl_bump terminate !activated

acl markedBumped note bumped true
url_rewrite_access deny markedBumped


> 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.
> P.S. For free Squid support, please keep the discussion on the mailing list.
> 
> 
>> 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-TimeMessage
 31.12.1969 16:00:00
 03.07.2024 10:54:34kick 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:29kick abandoning conn7844 local=192.168.1.1:3128 
 remote=192.168.1.5:49702 FD 81 flags=1
 03.07.2024 10:54:09ERROR: 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:09ERROR: 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:09ERROR: 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:04ERROR: failure while accepting a TLS connection on 
 conn7367 local=192.168.1.1:3128 remote=192.168.1.5:49627 FD 22 flags=1: 
 SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
 03.07.2024 10:52:47ERROR: failure while accepting a TLS connection on 
 conn7345 local=192.168.1.1:3128 remote=192.168.1.5:49618 FD 31 flags=1: 
 SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
 03.07.2024 10:52:38ERROR: failure while accepting a TLS connection on 
 conn7340 local=192.168.1.1:3128 remote=192.168.1.5:49616 FD 45 flags=1: 
 SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
 03.07.2024 10:52:34ERROR: failure while accepting a TLS connection on 
 conn7316 local=192.168.1.1:3128 remote=192.168.1.5:49609 FD 45 flags=1: 
 SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
 31.12.1969 16:00:00
 03.07.2024 10:51:55WARNING: Error Pages Missing Language: en-us
 31.12.1969 16:00:00
 03.07.2024 10:51:55ERROR: loading file 
 9;/usr/local/etc/squid/errors/en-us/ERR_ZERO_SIZE_OBJECT': (2) No such 
 file or directory
 03.07.2024 10:51:44ERROR: failure while accepting a TLS connection on 
 conn7102 local=192.168.1.1:3128 remote=192.168.1.5:49574 FD 34 flags=1: 
 SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
 03.07.2024 10:51:28ERROR: failure while accepting a TLS connection on 
 conn7071 local=192.168.1.1:3128 remote=192.168.1.5:49568 FD 92 flags=1:

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