<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><pre style="box-sizing: border-box; overflow: auto; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; font-size: 13px; padding: 9.5px; margin-top: 0px; margin-bottom: 10px; line-height: 1.428571; color: rgb(51, 51, 51); word-break: break-all; overflow-wrap: break-word; background-color: rgb(245, 245, 245); border: 1px solid rgb(204, 204, 204); border-radius: 4px; caret-color: rgb(51, 51, 51);">tls_outgoing_options options=NO_SSLv3,NO_TLSv1_3</pre><div>NO_TLSv1_3 is the directive if you need to disable this I have found for all other users with this problem </div><div><br><blockquote type="cite"><div>On Jul 5, 2024, at 14:21, Jonathan Lee <jonathanlee571@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">output of versions <div><br></div><div><div class="panel-heading" style="box-sizing: border-box; padding: 5px 15px; border-bottom-width: 1px; border-bottom-style: solid; border-color: rgb(214, 233, 198); border-radius: 0px; color: rgb(60, 118, 61); background-color: rgb(223, 240, 216); font-family: Roboto, sans-serif; font-size: 14px;"><h2 class="panel-title" style="box-sizing: border-box; font-family: inherit; font-weight: 500; line-height: 1.1; margin-top: 0px; margin-bottom: 0px; font-size: 16px;">Shell Output - openssl ciphers -s -v ECDHE</h2></div><div class="panel-body" style="box-sizing: border-box; padding: 0px; caret-color: rgb(51, 51, 51); color: rgb(51, 51, 51); font-family: Roboto, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);"><div class="content" style="box-sizing: border-box; padding: 10px;"><pre style="box-sizing: border-box; overflow: auto; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; font-size: 13px; padding: 9.5px; margin-top: 0px; margin-bottom: 10px; line-height: 1.428571; word-break: break-all; overflow-wrap: break-word; background-color: rgb(245, 245, 245); border: 1px solid rgb(204, 204, 204); border-radius: 4px;">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</pre></div></div><div>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 </div><div><br></div><div><strong style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 21px;">openssl req -x509 -new -nodes -key myProxykey.key -sha256 -days 365 -out myProxyca.pem</strong></div><div><strong style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 21px;"><br></strong></div><div><strong style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 21px;"><br></strong></div><div><br><blockquote type="cite"><div>On Jul 5, 2024, at 13:54, Jonathan Lee <jonathanlee571@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div>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. <br><br>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 <br>Sent from my iPhone<br><br><blockquote type="cite">On Jul 5, 2024, at 11:52, Jonathan Lee <jonathanlee571@gmail.com> wrote:<br><br>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?<br><br><blockquote type="cite">On Jul 5, 2024, at 11:28, <jonathanlee571@gmail.com> <jonathanlee571@gmail.com> wrote:<br><br>The only one I got a certificate from was the non iMac<br><br>The iMac keeps sending change cipher requests and wants TLS1.3 over and over as soon as a TLS1.2 pops up it works<br><br>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?<br><br>-----Original Message-----<br>From: Alex Rousskov <rousskov@measurement-factory.com><br>Sent: Friday, July 5, 2024 11:02 AM<br>To: squid-users <squid-users@lists.squid-cache.org><br>Cc: Jonathan Lee <jonathanlee571@gmail.com><br>Subject: Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6<br><br>On 2024-07-05 12:02, Jonathan Lee wrote:<br><br><blockquote type="cite"><blockquote type="cite">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).<br></blockquote></blockquote><br><br><blockquote type="cite">I have Wireshark running do I just look for information with<br>ssl.handshake.type == 1<br></blockquote><br><blockquote type="cite">Or is there a wireshark particular filter you would like ran to help with isolation?<br></blockquote><br><br>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!<br><br>These certificates are a part of standard TLS handshake, and Wireshark usually displays their fields when one studies TLS handshake bytes using Wireshark UI.<br><br>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.<br><br><br>HTH,<br><br>Alex.<br><br><br><br><blockquote type="cite"><blockquote type="cite">On Jul 5, 2024, at 08:23, Jonathan Lee <jonathanlee571@gmail.com> wrote:<br><br>Thanks for the email and support with this. I will get wireshark<br>running on the client and get the info required. Yes the information<br>prior is from the firewall side outside of the proxy testing from the<br>demilitarized zone area. I wanted to test this first to rule that out<br>as it’s coming in from that first and hits the proxy next Sent from<br>my iPhone<br><br><blockquote type="cite">On Jul 5, 2024, at 06:33, Alex Rousskov <rousskov@measurement-factory.com> wrote:<br><br>On 2024-07-04 19:12, Jonathan Lee wrote:<br><blockquote type="cite">You also stated .. " my current working theory suggests that we are looking at a (default) signUntrusted use case.”<br>I noticed for Squid documents that default is now set to off ..<br></blockquote><br>The http_port option you are looking at now is not the directive I was talking about earlier.<br><br><blockquote type="cite">http_port<br>tls-default-ca[=off]<br> Whether to use the system Trusted CAs. Default is OFF.<br>Would enabling this resolve the problem in Squid 6.6 for error.<br></blockquote><br><br>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.<br><br>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.<br><br>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.<br><br><blockquote type="cite">The squid.conf.documented lists it incorrectly<br></blockquote><br>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.<br><br>* 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).<br><br>* 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).<br><br>AFAICT, the documentation in question is not wrong (but is insufficient).<br><br>Again, I do not recommend changing any Squid configuration directives/options at this triage state.<br><br>Alex.<br><br></blockquote></blockquote></blockquote><br><tlschange.PNG><br></blockquote><br></blockquote></div></div></blockquote></div><br></div></div></div></blockquote></div><br></body></html>