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
