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 <jonathanlee...@gmail.com> 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-SHA384 TLSv1.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-POLY1305 TLSv1.2 Kx=ECDH Au=RSA > Enc=CHACHA20/POLY1305(256) Mac=AEAD > ECDHE-ECDSA-AES256-CCM8 TLSv1.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-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) > Mac=AEAD > ECDHE-ECDSA-AES128-CCM8 TLSv1.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-SHA384 TLSv1.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-SHA256 TLSv1.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 <jonathanlee...@gmail.com> 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 <jonathanlee...@gmail.com> 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, <jonathanlee...@gmail.com> >>>> <jonathanlee...@gmail.com> 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 <rouss...@measurement-factory.com> >>>> Sent: Friday, July 5, 2024 11:02 AM >>>> To: squid-users <squid-users@lists.squid-cache.org> >>>> Cc: Jonathan Lee <jonathanlee...@gmail.com> >>>> 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 <jonathanlee...@gmail.com> 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 >>>>>>> <rouss...@measurement-factory.com> 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. >>>>>>> >>>> >>>> <tlschange.PNG> >>> >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
