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
