On 2024-07-05 20:55, Jonathan Lee wrote:
FIXED
I think it wanted a new certificate generated mine became to weak I
needed one that ECDSA with prime256v sha256 and not RSA anymore that
solved my errors
Glad you found a solution! And if these errors resurface, you now have a
blueprint for the
FIXED
I think it wanted a new certificate generated mine became to weak I needed one
that ECDSA with prime256v sha256 and not RSA anymore that solved my errors
The error is gone when this cert is used :)
> On Jul 5, 2024, at 14:33, Jonathan Lee wrote:
>
> However even with it marked as no
However even with it marked as no
05.07.2024 14:30:46 ERROR: failure while accepting a TLS connection on
conn4633 local=192.168.1.1:3128 remote=192.168.1.5:49721 FD 30 flags=1:
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
continues
I am going to take a break please if anyone kn
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 do
s 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
>&
as 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
>>
> -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:
>
>>>
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 rec
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 ju
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
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 informa
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
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
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 packe
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
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
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_po
>>> 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
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_opt
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
ER
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/cer
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 NoBum
I found it
# TAG: sslproxy_cert_sign
#
#sslproxy_cert_sign acl ...
#
#The following certificate signing algorithms are supported:
#
# signTrusted
# Sign using the configured CA certificate which is usually
# placed in and trusted by end-user
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
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 prev
I forgot to mention my certificates I use on squid was generated from this
method
openssl req -x509 -new -nodes -key myProxykey.key -sha256 -days 365 -out
myProxyca.pem
Sent from my iPhone
> On Jul 3, 2024, at 10:56, Jonathan Lee wrote:
>
> Hello fellow Squid users does anyone know how to
Hello fellow Squid users does anyone know how to fix this issue?
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
27 matches
Mail list logo