[squid-users] reflecting on Squid Project Status with regard to "Joshua 55" vulnerabilities

2024-10-30 Thread Jonathan Lee
Hello, thank you for the update Francesso, there is also some chatter about 
bugs within the Netgate community. Is this also related to the fixes in V7 
(please see Redmine attached)?

I  admit, I have a bias and assumption that that Big-Tech does not like Squid 
functional, and that most of what is listed below was done within a political 
aspect to generate a confusion within the firewall community. So much so that 
the package was considered an issue and Netgate started to recommend Squid's 
removal. I have stood by this package and continue to, as it works beautifully.

This Redmine should have been more concise and simplified within its notes, it 
seems to just generate confusion.  I do not have issues like this and that is 
where I start to question what this is related to.  Can Someone please respond 
to this Redmine for verification that has a higher-level knowledge about Squid? 
I hate to see this removed for some simple reason like a PHP issue that causes 
configuration issues.

Bug #14390: Squid: SECURITY ALERT: Host header forgery detected - pfSense 
Packages - pfSense bugtracker
Bug #14390: Squid: SECURITY ALERT: Host header forgery detected - pfSense 
Packages - pfSense bugtracker
Redmine
redmine.pfsense.org

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid 6.10 SSL-Bump Woes

2024-10-10 Thread Jonathan Lee
Give it time to cache miss means it stored items Sent from my iPhoneOn Oct 10, 2024, at 15:27, Bryan Seitz  wrote:I removed the header mods and changed the refresh pattern to:refresh_pattern .               15      20%     1800    override-expire ignore-no-cache ignore-no-store ignore-privateAnd I always get TCP_MISS.  Any other thoughts? Thanks!On Thu, Oct 10, 2024 at 12:35 PM Alex Rousskov  wrote:On 2024-10-09 15:40, Bryan Seitz wrote:

 > SSL-Bump Woes

AFAICT, the problem you are trying to solve is not caused by SslBump.


 > reply_header_access Cache-Control deny all
 > reply_header_add Cache-Control  "public, max-age=1800"

The above directives are applied to responses that Squid sends to 
clients. These post-cache response modification directives have no 
effect on Squid response caching decisions (which are done earlier, 
pre-cache, while looking at the virgin or adapted response received from 
the origin server of cache_peer).

FWIW, this caveat is documented in reply_header_add description, but 
documentation improvements are welcome:

> This option adds header fields to outgoing HTTP responses (i.e., response
> headers delivered by Squid to the client). This option has no effect on
> cache hit detection. The equivalent adaptation vectoring point in
> ICAP terminology is post-cache RESPMOD.


To allow Squid to violate HTTP caching rules when deciding whether to a 
cache a response, see refresh_pattern options (e.g., "ignore-private").
http://www.squid-cache.org/Doc/config/refresh_pattern/


HTH,

Alex.


> I have the following configuration:
> 
> http_port 3128 ssl-bump generate-host-certificates=on 
> tls-cert=/etc/squid/ssl/myCA.pem
> ssl_bump bump all
> 
> # BMCs return Cache-Control: private
> reply_header_access Cache-Control deny all
> reply_header_add Cache-Control  "public, max-age=1800"
> 
> follow_x_forwarded_for allow all
> http_access allow all
> include /etc/squid/conf.d/*.conf
> host_verify_strict off
> tls_outgoing_options min-version=1.0 
> flags=DONT_VERIFY_PEER,DONT_VERIFY_DOMAIN
> sslproxy_cert_error allow all
> 
> sslcrtd_program /usr/lib/squid/security_file_certgen -s 
> /var/spool/squid/ssl_db -M 4MB
> sslcrtd_children 5
> 
> cache_mem 8192 MB
> cache_dir rock /cm/squid/squid 8192
> 
> buffered_logs on
> access_log daemon:/var/log/squid/access.log logformat=squid
> logfile_daemon /usr/lib/squid/log_file_daemon
> cache_store_log daemon:/var/log/squid/store.log
> log_mime_hdrs on
> coredump_dir /var/spool/squid
> shutdown_lifetime 2 seconds
> max_filedesc 4096
> workers 4
> 
> 
> A curl will note the resource is stale (with new host), but I never get 
> a cache hit on subsequent retries:
> 
> Store log:
> 
> 1728502393.992 RELEASE -1  02003A632F000300  200 
> 1728502382        -1        -1 application/json 1182/1182 GET 
> https://10.170.31.77/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics 
> 1728502395.674 RELEASE -1  02003B632F000200  200 
> 1728502384        -1        -1 application/json 1182/1182 GET 
> https://10.170.31.77/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics 
> 1728502408.317 RELEASE 00 00056924 04003C632F000100  200 
> 1728420588        -1 1728422388 application/json 1189/1189 GET 
> https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics 
> 1728502408.318 RELEASE -1  03003C632F000100  200 
> 1728502404        -1        -1 application/json 1179/1179 GET 
> https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics 
> 1728502417.161 RELEASE -1  05003C632F000100  200 
> 1728502413        -1        -1 application/json 1179/1179 GET 
> https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics 
> 
> Response headers:
> 
> HTTP/1.1 200 Connection established
> 
> HTTP/1.1 200 OK
> Link:  >; rel=describedby
> Allow: GET
> Content-Length: 1179
> Content-Type: application/json; charset=UTF-8
> Strict-Transport-Security: max-age=31536000; includeSubdomains
> X-XSS-Pr

Re: [squid-users] Wpad

2024-10-03 Thread Jonathan Lee
Thanks Jeffries 

Jonathan Lee
Sent from my iPhone

> On Oct 3, 2024, at 01:07, Amos Jeffries  wrote:
> 
> On 2/10/24 05:05, Jonathan Lee wrote:
>> Hello fellow squid users,
>> Can you please help? I am attempting to run wpad on the same machine as 
>> squid however port 80 443 is blocked, I have a url redirect 
>> 192.168.1.1/wpad.dat to https://192.168.1.1:8080/wpad.dat this is done with 
>> use of squid guard, however you must disable bypass for 192.168.1.1 on 
>> squid. Squid resides on 192.168.1.1:3128,
>> It works on the iMac for auto config proxy I can access the url file within 
>> the redirect.
>> My question is how can this be managed directly with squid custom config ?? 
>> Is there a way to have squid manage a simple wpad?
> 
> 
>  acl wpad urlpath_regex ^/wpad.dat$
>  deny_info 200:/etc/squid/wpad.dat wpad
>  http_access deny wpad
> 
>  reply_header_access Content-Type deny wpad
>  reply_header_replace Content-Type application/x-ns-proxy-autoconfig
> 
> 
> 
> HTH
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


[squid-users] Wpad

2024-10-01 Thread Jonathan Lee
Hello fellow squid users,

Can you please help? I am attempting to run wpad on the same machine as squid 
however port 80 443 is blocked, I have a url redirect 192.168.1.1/wpad.dat to 
https://192.168.1.1:8080/wpad.dat this is done with use of squid guard, however 
you must disable bypass for 192.168.1.1 on squid. Squid resides on 
192.168.1.1:3128,

It works on the iMac for auto config proxy I can access the url file within the 
redirect.

My question is how can this be managed directly with squid custom config ?? Is 
there a way to have squid manage a simple wpad? 
Sent from my iPhone
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] RFC: Removal of ESI Support from Squid

2024-09-07 Thread Jonathan Lee
I use bump splice, with split acls and access lists that match MAC addresses, 
plus cachemgr, I hate to admit I am using 5.8 because 6.6 has issues with so 
many errors showing and is so much slower. I do not want to reissue all my 
certificates, it works perfect for what I need in my mini firewall. 

It took many many hours of config and years of testing and changes to get it to 
this level of performance. I was very happy that 6.6 was released but it broke 
a lot of the php gui tools. Again it is like 5.8 is an everything bagel, it’s 
protected behind a firewall so I am less concerned as well. I am not protecting 
a massive corporate environment, it is just home issue
Sent from my iPhone

> On Sep 7, 2024, at 08:52, Amos Jeffries  wrote:
> 
> Hi all,
> 
> The ESI (Edge Side Includes) feature of Squid has a growing number of unfixed 
> bugs, more than a few are turning into security issues.
> 
> Also, the current Squid developers do not have spare brain cycles to maintain 
> everything and v7 is seeing a lot more effort to prune away old and unused 
> mechanisms in Squid.
> 
> 
> As such this is a callout to see how much use there is for this feature.
> 
> 
>  DO you need ESI in Squid?  Yes or No.
> 
>   Speak Now, or face regrets at upgrade time.
> 
> 
> 
> Thank You
> Amos
> 
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-08-01 Thread Jonathan Lee
https://github.com/squid-cache/squid/commit/a4e35bd8ffe51cda83e63faab79bda5a838c7e1a
Seems to want a valid username 

https://github.com/squid-cache/squid/commit/3c383cc371e7ad69c533e629c6997f325aa3752d
Has squid-internal-mgr special case change to an
// special case: /squid-internal-mgr/ index page
// special case: an index page
if (!strcmp(cmd->profile->name, "index")) {
ErrorState err(MGR_INDEX, Http::scOkay, request, ale);
err.url = xstrdup(entry->url());


I can not get status to show for anything 

> On Jul 24, 2024, at 14:29, Francesco Chemolli  wrote:
> 
> Hi Jonathan,
>  could you try:
> curl -u anything:redacted http://localhost:3128/squid-internal-mgr/menu
> 
> ?
> 
> On Mon, Jul 22, 2024 at 8:52 PM Jonathan Lee  wrote:
>> 
>> Also I have tested
>> 
>> curl 127.0.0.1:3128/squid-internal-mgr -u :redacted
>> curl localhost:3128/squid-internal-mgr -u :redacted
>> curl hostname_here:3128/squid-internal-mgr -u :redacted (per bug notes use 
>> hostname in place of localhost)
>> 
>> and testing with no password same commands lock up the system with no 
>> response and if I do them outside of the host with a web browser I get the 
>> errors below seen they are new..
>> 
>> HTTP/1.1 Expect: feature is being asked from an HTTP/1.0 software.
>> 
>> 
>> 
>> 
>> 
>> On Jul 22, 2024, at 09:01, Jonathan Lee  wrote:
>> 
>> Thanks for the info
>> 
>> I tried it and this also failed. Dang
>> 
>> Shell Output - curl localhost:3128/squid-internal-mgr/info -u :redacted
>> 
>>  % Total% Received % Xferd  Average Speed   TimeTime Time  
>> Current
>> Dload  Upload   Total   SpentLeft  Speed
>> 
>>  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
>> 100  3773  100  37730 0  90756  0 --:--:-- --:--:-- --:--:-- 
>> 94325
>> > "http://www.w3.org/TR/html4/strict.dtd";>
>> 
>> 
>> 
>> ERROR: The requested URL could not be retrieved
>> 

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-08-01 Thread Jonathan Lee
The directive
cachemgr_passwd
does not allow the ability to add a username right?



> On Aug 1, 2024, at 12:30, Jonathan Lee  wrote:
> 
>   client << " requesting '" <<
>actionName << "'" );
> 
> // special case: /squid-internal-mgr/ index page
> // special case: an index page
> if (!strcmp(cmd->profile->name, "index")) {
> ErrorState err(MGR_INDEX, Http::scOkay, request, ale);
> err.url = xstrdup(entry->url());
> 
> it shows squid-internal-mgr was removed and replaced with “an"….
> 
>> On Jul 24, 2024, at 14:29, Francesco Chemolli  wrote:
>> 
>> Hi Jonathan,
>>  could you try:
>> curl -u anything:redacted http://localhost:3128/squid-internal-mgr/menu
>> 
>> ?
>> 
>> On Mon, Jul 22, 2024 at 8:52 PM Jonathan Lee  
>> wrote:
>>> 
>>> Also I have tested
>>> 
>>> curl 127.0.0.1:3128/squid-internal-mgr -u :redacted
>>> curl localhost:3128/squid-internal-mgr -u :redacted
>>> curl hostname_here:3128/squid-internal-mgr -u :redacted (per bug notes use 
>>> hostname in place of localhost)
>>> 
>>> and testing with no password same commands lock up the system with no 
>>> response and if I do them outside of the host with a web browser I get the 
>>> errors below seen they are new..
>>> 
>>> HTTP/1.1 Expect: feature is being asked from an HTTP/1.0 software.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Jul 22, 2024, at 09:01, Jonathan Lee  wrote:
>>> 
>>> Thanks for the info
>>> 
>>> I tried it and this also failed. Dang
>>> 
>>> Shell Output - curl localhost:3128/squid-internal-mgr/info -u :redacted
>>> 
>>>  % Total% Received % Xferd  Average Speed   TimeTime Time  
>>> Current
>>> Dload  Upload   Total   SpentLeft  Speed
>>> 
>>>  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- >>> 0
>>> 100  3773  100  37730 0  90756  0 --:--:-- --:--:-- --:--:-- 
>>> 94325
>>> >> "http://www.w3.org/TR/html4/strict.dtd";>
>>> 
>>> 
>>> 
>>> ERROR: The requested URL could not be retrieved
>>> 

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-08-01 Thread Jonathan Lee

  client << " requesting '" <<
   actionName << "'" );

// special case: /squid-internal-mgr/ index page
// special case: an index page
if (!strcmp(cmd->profile->name, "index")) {
ErrorState err(MGR_INDEX, Http::scOkay, request, ale);
err.url = xstrdup(entry->url());

it shows squid-internal-mgr was removed and replaced with “an"….

> On Jul 24, 2024, at 14:29, Francesco Chemolli  wrote:
> 
> Hi Jonathan,
>  could you try:
> curl -u anything:redacted http://localhost:3128/squid-internal-mgr/menu
> 
> ?
> 
> On Mon, Jul 22, 2024 at 8:52 PM Jonathan Lee  wrote:
>> 
>> Also I have tested
>> 
>> curl 127.0.0.1:3128/squid-internal-mgr -u :redacted
>> curl localhost:3128/squid-internal-mgr -u :redacted
>> curl hostname_here:3128/squid-internal-mgr -u :redacted (per bug notes use 
>> hostname in place of localhost)
>> 
>> and testing with no password same commands lock up the system with no 
>> response and if I do them outside of the host with a web browser I get the 
>> errors below seen they are new..
>> 
>> HTTP/1.1 Expect: feature is being asked from an HTTP/1.0 software.
>> 
>> 
>> 
>> 
>> 
>> On Jul 22, 2024, at 09:01, Jonathan Lee  wrote:
>> 
>> Thanks for the info
>> 
>> I tried it and this also failed. Dang
>> 
>> Shell Output - curl localhost:3128/squid-internal-mgr/info -u :redacted
>> 
>>  % Total% Received % Xferd  Average Speed   TimeTime Time  
>> Current
>> Dload  Upload   Total   SpentLeft  Speed
>> 
>>  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
>> 100  3773  100  37730 0  90756  0 --:--:-- --:--:-- --:--:-- 
>> 94325
>> > "http://www.w3.org/TR/html4/strict.dtd";>
>> 
>> 
>> 
>> ERROR: The requested URL could not be retrieved
>> 

Re: [squid-users] Parse DNS for IPv4 and IPv6

2024-07-31 Thread Jonathan Lee
Does it require 

acl localnet src fc00::/7
acl localnet src fe80::/10
With the pfsense packages or is that coded into the php code?
Sent from my iPhone

> On Jul 31, 2024, at 13:18, Jonathan Lee  wrote:
> 
> I forgot to mention this is over a he tunnel broker gif interface with IPv4 
> only isp
> Sent from my iPhone
> 
>> On Jul 31, 2024, at 12:03, Jonathan Lee  wrote:
>> 
>> I show HTTP/1.1 409 conflict when it try to reply from the firewall back to 
>> the client.
>> 
>> I do not know if you need a pcap file
>> 
>> 
>> 
>> 
>> 
>>>> On Jul 31, 2024, at 03:35, Matus UHLAR - fantomas  
>>>> wrote:
>>> 
>>>> On 30.07.24 12:55, Jonathan Lee wrote:
>>>> Hello fellow squid users can you please help?
>>> 
>>>> I have noticed that I get 409 errors with IPv6 only clients this leads me 
>>>> to believe that it’s DNS related.
>>> 
>>> why do you think that?
>>> 
>>>> My firewall has both IPV4 and IPV6 DNS.  I wonder if when an IPV6 only 
>>>> client is trying to access the proxy it defaults to IPv4 dns.
>>> 
>>> Sice, the connection between client and squid is separate from connection 
>>> between squid and server, it should be perfectly okay to have ipv6 on one 
>>> and ipv4 on another.
>>> 
>>>> How can one manually set the system to utilize specified DNS for ACL use 
>>>> within subnets?  The system works as long as clients are double stacked.
>>> 
>>> Can we see example of those errors in log files?
>>> 
>>> --
>>> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
>>> Warning: I wish NOT to receive e-mail advertising to this address.
>>> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
>>> Support bacteria - they're the only culture some people have.
>>> ___
>>> squid-users mailing list
>>> squid-users@lists.squid-cache.org
>>> https://lists.squid-cache.org/listinfo/squid-users
>> 
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Parse DNS for IPv4 and IPv6

2024-07-31 Thread Jonathan Lee
I forgot to mention this is over a he tunnel broker gif interface with IPv4 
only isp
Sent from my iPhone

> On Jul 31, 2024, at 12:03, Jonathan Lee  wrote:
> 
> I show HTTP/1.1 409 conflict when it try to reply from the firewall back to 
> the client.
> 
> I do not know if you need a pcap file
> 
> 
> 
> 
> 
>> On Jul 31, 2024, at 03:35, Matus UHLAR - fantomas  wrote:
>> 
>>> On 30.07.24 12:55, Jonathan Lee wrote:
>>> Hello fellow squid users can you please help?
>> 
>>> I have noticed that I get 409 errors with IPv6 only clients this leads me 
>>> to believe that it’s DNS related.
>> 
>> why do you think that?
>> 
>>> My firewall has both IPV4 and IPV6 DNS.  I wonder if when an IPV6 only 
>>> client is trying to access the proxy it defaults to IPv4 dns.
>> 
>> Sice, the connection between client and squid is separate from connection 
>> between squid and server, it should be perfectly okay to have ipv6 on one 
>> and ipv4 on another.
>> 
>>> How can one manually set the system to utilize specified DNS for ACL use 
>>> within subnets?  The system works as long as clients are double stacked.
>> 
>> Can we see example of those errors in log files?
>> 
>> --
>> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
>> Warning: I wish NOT to receive e-mail advertising to this address.
>> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
>> Support bacteria - they're the only culture some people have.
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> https://lists.squid-cache.org/listinfo/squid-users
> 
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid with PV6 Tunnel Broker

2024-07-30 Thread Jonathan Lee
The error it shows when I activate IPv6 only mode not dual stack is

Error: no forward proxy ports configured 

Squid terminated
Sent from my iPhone

> On Jul 30, 2024, at 20:16, Amos Jeffries  wrote:
> 
> On 30/07/24 08:47, Jonathan Lee wrote:
>> I did not know that I had the option set to disable Squid ICMP pinger
> 
> pinger helper is not releted.
> 
> 
> What I meant was that you need to ensure ICMPv6 protocol is enabled and 
> working on your network. That is usually a firewall issue.
> 
> If it is blocked, the IPv6 packet fragmentation mechanism (required for 
> tunnels) will not work and result in behaviour like you are seeing.
> Similarly if MTU is set too large for the tunnel maximum packet size.
> 
> 
>> I enabled ping helper I show a good socket for my IPV6 interface address but 
>> every IPV6 only device shows NONE_NONE/409 on the Squid Access Table
> 
> 409 generated by Squid is a failed security check.
> <https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery>
> 
> 
>> I get the same result. How would I change MTU on Squid isn’t that set to 
>> auto discover with the HTTP port directive?
> 
> Yes, that is dneone using ICMPv6 and teh primary reason why Squid needs that 
> protocol working.
> 
>> I also forgot to mention the IPV6 only device works when I have it set to 
>> not use the proxy.
> 
> The list of ports you show below has Squid accepting direct (forward proxy) 
> connections with an IPv4-only port 3128.
> 
> 
> I really do recommend using the port-only configuration style. At least until 
> you get the proxy working properly. Squid sockets are dual-stack and accept 
> both protocols by default. That will help you sort out the scope of what each 
> port number is doing and avoid copy-paste mistakes like this.
> 
> 
>> Thanks again for the reply. It does work from IPV4 to IPV6 requests but 
>> never for IPV6 to IPV6 addresses or pure IPV6. I can disable the proxy and 
>> the system works for IPV6 to IPV6 only.
> 
> 
>> Here is my configuration I am testing..
>> # This file is automatically generated by pfSense
>> # Do not edit manually !
>> http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
>> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
>> tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
>> capath=/usr/local/share/certs/ 
>> 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
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3
>> http_port 127.0.0.1:3128 intercept ssl-bump generate-host-certificates=on 
>> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
>> tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
>> capath=/usr/local/share/certs/ 
>> 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
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3
>> https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on 
>> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
>> tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
>> capath=/usr/local/share/certs/ 
>> 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
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3
>> http_port [REDACTED:192::]:3128 intercept ssl-bump 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
>> cert=/usr/local/etc/squid/serverkey.pem 
>> tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
>> capath=/usr/local/share/certs/ 
>> 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
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3
>> https_port [REDACTED:192::]:3129 intercept ssl-bump 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
>> cert=/usr/local/etc/squid/serverkey.pem 
>> tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
>> capath=/usr/local/share/certs/ 
>> 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:

[squid-users] Parse DNS for IPv4 and IPv6

2024-07-30 Thread Jonathan Lee
Hello fellow squid users can you please help? I have noticed that I get 409 
errors with IPv6 only clients this leads me to believe that it’s DNS related. 
My firewall has both IPV4 and IPV6 DNS. I wonder if when an IPV6 only client is 
trying to access the proxy it defaults to IPv4 dns. How can one manually set 
the system to utilize specified DNS for ACL use within subnets? The system 
works as long as clients are double stacked. 


Sent from my iPhone
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid with PV6 Tunnel Broker

2024-07-29 Thread Jonathan Lee
'/usr/local/pkg/reg.url.nobump'
acl NoBumpDNS dstdomain '/usr/local/pkg/dns.nobump'

#acl markBumped annotate_client bumped=true
acl active_use annotate_client active=true
acl bump_only src 192.168.1.3 #webtv
acl bump_only src 192.168.1.4 #toshiba
acl bump_only src 192.168.1.5 #imac
acl bump_only src REDACTEDIPV6:720b:5bdd #imac
acl bump_only src 192.168.1.9 #macbook
acl bump_only src 192.168.1.13 #dell

acl bump_only_mac arp REDACTEDMAC
acl bump_only_mac arp REDACTEDMAC
acl bump_only_mac arp REDACTEDMAC
acl bump_only_mac arp REDACTEDMAC
acl bump_only_mac arp REDACTEDMAC


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 NoBumpDNS active_use
ssl_bump splice NoSSLIntercept active_use #tested without MAC match
#ssl_bump bump bump_only_mac bump_only active_use
ssl_bump bump bump_only active_use
#acl activated note active_use true
#ssl_bump terminate !activated

#acl markedBumped note bumped true
#url_rewrite_access deny markedBumped

#acl SSLIntercept ssl::server_name_regex -i '/usr/local/pkg/url.bump'
#ssl_bump bump SSLIntercept

# Setup allowed ACLs
# Allow local network(s) on interface(s)
http_access allow localnet
# Default block all to be sure
http_access deny allsrc
Does anyone else have and ideas on what I did wrong? I have also tried to 
remove the addresses in the HTTP_PORT directive so it automatically configures, 
that was the same result. I have removed my MAC address matching and the 
terminate options same result also.

I get 409 errors on ssl bumps 

> On Jul 29, 2024, at 00:17, Amos Jeffries  wrote:
> 
> On 27/07/24 10:10, Jonathan Lee wrote:
>> Hello fellow squid users can you please help me??
>> I know I have good IPV6 internet if I use the IPV4 proxy address, and the 
>> IPv6 test sites pass 10 out of 10. If I make the client IPV6 only and have 
>> the rules set to use the proxy with the proxy IPV6 address for the proxy I 
>> get no internet.
>> I am using a IPV6 tunnel broker in pfsense. When I configure my client to 
>> IPv6 only it can access all IPv6 sites. As soon as I use the proxy address 
>> in IPv6 of Squid squid gives me the following errors...
> 
> Check that ICMPv6 is working. It is mandatory when tunnels are used.
> 
> Also, check the MSS and MTU values.
> 
> 
> Cheers
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-29 Thread Jonathan Lee
Does this also auto solve for IPv6 connections changing it to just 

http_port 3128
https_port 3129??

> On Jul 12, 2024, at 04:57, Amos Jeffries  wrote:
> 
> On 12/07/24 11:50, Jonathan Lee wrote:
>>> I recommend changing your main port to this:
>>> 
>>>   http_port 3128 ssl-bump 
>> This is set to this when it processes
>> http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
>> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
>> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
>> 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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
> 
> The key thing here was the removal of the IP address. So that Squid received 
> both the 192.168.*.* and the 127.0.0.* traffic without needing separate 
> http_port lines.
> 
> 
> 
>>> and receiving the intercepted traffic on:
>>> 
>>>  http_port 3129 intercept ssl-bump …
>> Do you mean https?
> 
> Sorry. I missed that you had an https_port using 3129 already.
> 
> 
> 
>> https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on 
>> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
>> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
>> 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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
>> Https uses that port 3129
>> What should I adapt
>> http_port
>> https_port?
> 
> Both.
> 
> FYI, there are two issues:
> 
> 1) listening on IP 127.0.0.1. Inside the OS there are different devices for 
> localhost (lo) and WAN (eg. eth0). NAT is problematic already without 
> introducing any tricky behaviours from bridging those "private" (lo) and 
> "public" WAN devices.
> 
> The simplest solution is just not to put any IP address on the squid.conf 
> *port line(s) with intercept options. The OS will select one appropriate for 
> whatever device and tell Squid on a per-connection basis.
> 
> The more difficult way is to put one of the machines "global" (WAN or LAN) IP 
> addresses. In your case 192.168.1.1. With most connections being from the LAN 
> that minimizes the possible problems.
> 
> 
> 2) listening on a well-known proxy port 3128 for intercepted traffic.
> 
> There is malware in existence that scans for at least port 3128 (likely 1080, 
> 8080 etc common proxy ports) being used by proxies like yours and abuses 
> them. As a result at least one popular antivirus network scanner (from Trend) 
> does the same scan to detect insecure proxies.
> 
> The worst thing about this situation is that the NAT very effectively hides 
> the malware. So it is extremely hard to see whether it is happening to you.
> 
> 
> I am not sure what UI you are using to show those firewall rules in your 
> other email. However the one that had ALLOW for the port range 3128-3129 
> worries me. AFAIK that should only be for 3128 and a separate rule somewhere 
> else to drop the intercepted port 3129 traffic pre-NAT.
> 
> 
> HTH
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org <mailto:squid-users@lists.squid-cache.org>
> https://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid with PV6 Tunnel Broker

2024-07-27 Thread Jonathan Lee
Do I need to add ::1 as a http port? for transparent I can’t get anything to 
work I sees the attempts with ipv6 pure mode however nothing connects..

[2001:470:8052:192::]:3128 is my proxy 

I can’t get any connections from ipv6 only hosts.

I can get ipv4 all day and they can access ipv6 sites just not the other way 
around 

It is currently set as 

http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3

http_port 127.0.0.1:3128 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3

https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3

http_port [2001:470:8052:192::]:3128 intercept ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3

https_port [2001:470:8052:192::]:3129 intercept ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3


so should it include??

http_port [::1]:3128 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3

https_port [::1]:3129 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
tls-cafile=/usr/local/share/certs/ca-root-nss.crt 
capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3




> On Jul 26, 2024, at 15:10, Jonathan Lee  wrote:
> 
> Hello fellow squid users can you please help me??
> 
> I know I have good IPV6 internet if I use the IPV4 proxy address, and the 
> IPv6 test sites pass 10 out of 10. If I make the client IPV6 only and have 
> the rules set to use the proxy with the proxy IPV6 address for the proxy I 
> get no internet. 
> 
> I am using a IPV6 tunnel broker in pfsense. When I configure my client to 
> IPv6 only it can access all IPv6 sites. As soon as I use the proxy address in 
> IPv6 of Squid squid gives me the following errors...
> 
> Squid - Cache Logs
> Date-Time Message
> 26.07.2024 15:07:12   ERROR: failure while accepting a TLS connection on 
> conn26864 local=192.168.1.1:3128 remote=192.168.1.14:52687 FD 452 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000415+TLS_IO_ERR=1
> 31.12.1969 16:00:00   
> 26.07.2024 15:07:10   kick abandoning conn26863 
> local=[2001:470:8052:192::]:3128 
> remote=[2001:470:8052:192:898d:9911:720b:5bdd]:54252 FD 451 flags=33
> 

[squid-users] Squid with PV6 Tunnel Broker

2024-07-26 Thread Jonathan Lee
Hello fellow squid users can you please help me??

I know I have good IPV6 internet if I use the IPV4 proxy address, and the IPv6 
test sites pass 10 out of 10. If I make the client IPV6 only and have the rules 
set to use the proxy with the proxy IPV6 address for the proxy I get no 
internet. 

I am using a IPV6 tunnel broker in pfsense. When I configure my client to IPv6 
only it can access all IPv6 sites. As soon as I use the proxy address in IPv6 
of Squid squid gives me the following errors...

Squid - Cache Logs
Date-Time   Message
26.07.2024 15:07:12 ERROR: failure while accepting a TLS connection on 
conn26864 local=192.168.1.1:3128 remote=192.168.1.14:52687 FD 452 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000415+TLS_IO_ERR=1
31.12.1969 16:00:00 
26.07.2024 15:07:10 kick abandoning conn26863 
local=[2001:470:8052:192::]:3128 
remote=[2001:470:8052:192:898d:9911:720b:5bdd]:54252 FD 451 flags=33
31.12.1969 16:00:00 
26.07.2024 15:07:10 SECURITY ALERT: on URL: www.bing.com:443
31.12.1969 16:00:00 
26.07.2024 15:07:10 SECURITY ALERT: By user agent: Mozilla/5.0 (Macintosh; 
Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 
Safari/537.36 Edg/127.0.0.0
31.12.1969 16:00:00 
26.07.2024 15:07:10 SECURITY ALERT: Host header forgery detected on 
conn26863 local=[2001:470:8052:192::]:3128 
remote=[2001:470:8052:192:898d:9911:720b:5bdd]:54252 FD 451 flags=33 
(intercepted port does not match 443)

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-26 Thread Jonathan Lee
Shows a miss 403 in the cache logs for it 
-   -
26.07.2024 10:57:01 192.168.1.5 NONE_NONE_ABORTED/200   
dc1.ksn.kaspersky-labs.com:443  -   -
26.07.2024 10:56:48 127.0.0.1   TCP_MISS/403
http://localhost:3128/squid-internal-mgr/menu   -   127.0.0.1
26.07.2024 10:56:48 127.0.0.1   TCP_MISS/403
http://localhost:3128/squid-internal-mgr/menu   -   -
26.07.2024 10:56:45 192.168.1.5 NONE_NONE/200   gdmf.apple.com:443  
-   -
26.07.2024 10:56:44 192.168.1.5 TCP_TUNNEL/200  
configuration.apple.com:443 -   104.107.104.29
26.07.2024 10:56:16 192.168.1.5 TCP_REDIRECT/301
token.safebrowsing.apple:443


> On Jul 24, 2024, at 14:29, Francesco Chemolli  wrote:
> 
> Hi Jonathan,
>  could you try:
> curl -u anything:redacted http://localhost:3128/squid-internal-mgr/menu
> 
> ?
> 
> On Mon, Jul 22, 2024 at 8:52 PM Jonathan Lee  wrote:
>> 
>> Also I have tested
>> 
>> curl 127.0.0.1:3128/squid-internal-mgr -u :redacted
>> curl localhost:3128/squid-internal-mgr -u :redacted
>> curl hostname_here:3128/squid-internal-mgr -u :redacted (per bug notes use 
>> hostname in place of localhost)
>> 
>> and testing with no password same commands lock up the system with no 
>> response and if I do them outside of the host with a web browser I get the 
>> errors below seen they are new..
>> 
>> HTTP/1.1 Expect: feature is being asked from an HTTP/1.0 software.
>> 
>> 
>> 
>> 
>> 
>> On Jul 22, 2024, at 09:01, Jonathan Lee  wrote:
>> 
>> Thanks for the info
>> 
>> I tried it and this also failed. Dang
>> 
>> Shell Output - curl localhost:3128/squid-internal-mgr/info -u :redacted
>> 
>>  % Total% Received % Xferd  Average Speed   TimeTime Time  
>> Current
>> Dload  Upload   Total   SpentLeft  Speed
>> 
>>  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
>> 100  3773  100  37730 0  90756  0 --:--:-- --:--:-- --:--:-- 
>> 94325
>> > "http://www.w3.org/TR/html4/strict.dtd";>
>> 
>> 
>> 
>> ERROR: The requested URL could not be retrieved
>> 

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-26 Thread Jonathan Lee
Shell Output - curl -u anything:REDACTED 
http://localhost:3128/squid-internal-mgr/menu
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
100  3833  100  38330 0  64041  0 --:--:-- --:--:-- --:--:-- 64966
http://www.w3.org/TR/html4/strict.dtd";>



ERROR: The requested URL could not be retrieved

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-22 Thread Jonathan Lee
Tested thanks for the reply and idea access denied and tested with a firewall 
rule to approve everything to port 80 same result with or without mgr_passord 
configured, it is like the page is missing in Squid 6.6 or something 

Shell Output - curl localhost:3128/squid-internal-mgr/info -u admin:redacted
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
100  3783  100  37830 0   111k  0 --:--:-- --:--:-- --:--:--  115k
http://www.w3.org/TR/html4/strict.dtd";>



ERROR: The requested URL could not be retrieved

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-22 Thread Jonathan Lee
Ok thanks let me boot that environment and test again, my concern is that is 
looks like it is attempting it from my WAN side address that is my wan address 
and not the loopback 

> On Jul 22, 2024, at 11:22, Francesco Chemolli  wrote:
> 
> Not really, no. Username is not considered, it's just to make sure
> that curl sends all the data
> 
> On Mon, Jul 22, 2024 at 7:21 PM Jonathan Lee  wrote:
>> 
>> That would require a username for the cachemgr_password account right? I 
>> have no usernames set up for this.
>> 
>> How does one add a username for this directive ?
>> 
>>> On Jul 22, 2024, at 11:13, Francesco Chemolli  wrote:
>>> 
>>> Can you try supplying a username to curl? It's also common practice to
>>> put flags ('-u user:redacted') before arguments (the URL)
>>> 
>>> On Mon, Jul 22, 2024 at 5:12 PM Jonathan Lee  
>>> wrote:
>>>> 
>>>> Thanks for the info
>>>> 
>>>> I tried it and this also failed. Dang
>>>> 
>>>> Shell Output - curl localhost:3128/squid-internal-mgr/info -u :redacted
>>>> 
>>>> % Total% Received % Xferd  Average Speed   TimeTime Time  
>>>> Current
>>>>Dload  Upload   Total   SpentLeft  Speed
>>>> 
>>>> 0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- >>>> 0
>>>> 100  3773  100  37730 0  90756  0 --:--:-- --:--:-- --:--:-- 
>>>> 94325
>>>> >>> "http://www.w3.org/TR/html4/strict.dtd";>
>>>> 
>>>> 
>>>> 
>>>> ERROR: The requested URL could not be retrieved
>>>> 

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-22 Thread Jonathan Lee
That would require a username for the cachemgr_password account right? I have 
no usernames set up for this.

How does one add a username for this directive ?

> On Jul 22, 2024, at 11:13, Francesco Chemolli  wrote:
> 
> Can you try supplying a username to curl? It's also common practice to
> put flags ('-u user:redacted') before arguments (the URL)
> 
> On Mon, Jul 22, 2024 at 5:12 PM Jonathan Lee  wrote:
>> 
>> Thanks for the info
>> 
>> I tried it and this also failed. Dang
>> 
>> Shell Output - curl localhost:3128/squid-internal-mgr/info -u :redacted
>> 
>>  % Total% Received % Xferd  Average Speed   TimeTime Time  
>> Current
>> Dload  Upload   Total   SpentLeft  Speed
>> 
>>  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
>> 100  3773  100  37730 0  90756  0 --:--:-- --:--:-- --:--:-- 
>> 94325
>> > "http://www.w3.org/TR/html4/strict.dtd";>
>> 
>> 
>> 
>> ERROR: The requested URL could not be retrieved
>> 

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-22 Thread Jonathan Lee
Also I have tested 

curl 127.0.0.1:3128/squid-internal-mgr -u :redacted
curl localhost:3128/squid-internal-mgr -u :redacted
curl hostname_here:3128/squid-internal-mgr -u :redacted (per bug notes use 
hostname in place of localhost)

and testing with no password same commands lock up the system with no response 
and if I do them outside of the host with a web browser I get the errors below 
seen they are new..

> HTTP/1.1 Expect: feature is being asked from an HTTP/1.0 software.
> 





> On Jul 22, 2024, at 09:01, Jonathan Lee  wrote:
> 
> Thanks for the info
> 
> I tried it and this also failed. Dang
> 
> Shell Output - curl localhost:3128/squid-internal-mgr/info -u :redacted
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
> 100  3773  100  37730 0  90756  0 --:--:-- --:--:-- --:--:-- 94325
>  "http://www.w3.org/TR/html4/strict.dtd";>
> 
> 
> 
> ERROR: The requested URL could not be retrieved
> 

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-22 Thread Jonathan Lee
Thanks for the info

I tried it and this also failed. Dang

Shell Output - curl localhost:3128/squid-internal-mgr/info -u :redacted
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
100  3773  100  37730 0  90756  0 --:--:-- --:--:-- --:--:-- 94325
http://www.w3.org/TR/html4/strict.dtd";>



ERROR: The requested URL could not be retrieved

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-17 Thread Jonathan Lee
without password enabled 

Shell Output - curl http://127.0.0.1:3128/squid-internal-mgr/info
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
100  3714  100  37140 0  12258  0 --:--:-- --:--:-- --:--:-- 12298
http://www.w3.org/TR/html4/strict.dtd";>



ERROR: The requested URL could not be retrieved

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-17 Thread Jonathan Lee
Do I use 

curl http://localhost:3128/squid-internal-mgr/info 

Where would I place the password?

> On Jul 17, 2024, at 21:08, Jonathan Lee  wrote:
> 
> 2024/07/17 21:07:37| Processing Configuration File: 
> /usr/local/etc/squid/squid.conf (depth 0)
> 2024/07/17 21:07:37| Processing: http_port 192.168.1.1:3128 ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/17 21:07:37| WARNING: UPGRADE: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
> Use 'tls-cafile=' instead.
> 2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
> '/etc/dh-parameters.2048'
> OpenSSL-saved error #1: 0x1e08010c
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Processing: http_port 3128 intercept ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Starting Authentication on port [::]:3128
> 2024/07/17 21:07:37| Disabling Authentication on port [::]:3128 (interception 
> enabled)
> 2024/07/17 21:07:37| WARNING: UPGRADE: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
> Use 'tls-cafile=' instead.
> 2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
> '/etc/dh-parameters.2048'
> OpenSSL-saved error #1: 0x1e08010c
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Processing: https_port 3129 intercept ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Starting Authentication on port [::]:3129
> 2024/07/17 21:07:37| Disabling Authentication on port [::]:3129 (interception 
> enabled)
> 2024/07/17 21:07:37| WARNING: UPGRADE: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in https_port. 
> Use 'tls-cafile=' instead.
> 2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
> '/etc/dh-parameters.2048'
> OpenSSL-saved error #1: 0x1e08010c
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 
> I removed the : and it processed 
> 
> 
>> On Jul 12, 2024, at 09:52, Amos Jeffries  wrote:
>> 
>> On 13/07/24 04:16, Jonathan Lee wrote:
>>> tested with removal of IP and port failed If I leave port I get this
>>> 2024/07/12 09:15:17| Processing: http_port :3128 intercept
>> 
>> No  ":" before thr port number.
>> 
>> 
>> Amos
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> https://lists.squid-cache.org/listinfo/squid-users
> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-17 Thread Jonathan Lee
Again still no status page

This is the active php code used

function squid_status() {
if (is_service_running('squid')) {
init_config_arr(array('installedpackages', 
'squidcache','config'));
$proxy_ifaces = explode(",", 
config_get_path('installedpackages/squid/config/0/active_interface', ''));
foreach ($proxy_ifaces as $iface) {
if (get_interface_ip($iface)) {
$ip = get_interface_ip($iface);
$lip = '127.0.0.1';
} else {
$ip = get_interface_ipv6($iface);
$lip = '::1';
}
exec("/usr/local/sbin/squidclient -l " . 
escapeshellarg($lip) .
" -h " . escapeshellarg($ip) . " mgr:info", 
$result);
}
} else {
return(gettext('Squid Proxy is not running.'));


I use to just append the password after mgr:info@password and it worked however 
now nothing….

Also 

squidclient -l 127.0.0.1 -h localhost mgr:info 

I get nothing with password removed  

> On Jul 17, 2024, at 21:08, Jonathan Lee  wrote:
> 
> 2024/07/17 21:07:37| Processing Configuration File: 
> /usr/local/etc/squid/squid.conf (depth 0)
> 2024/07/17 21:07:37| Processing: http_port 192.168.1.1:3128 ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/17 21:07:37| WARNING: UPGRADE: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
> Use 'tls-cafile=' instead.
> 2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
> '/etc/dh-parameters.2048'
> OpenSSL-saved error #1: 0x1e08010c
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Processing: http_port 3128 intercept ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Starting Authentication on port [::]:3128
> 2024/07/17 21:07:37| Disabling Authentication on port [::]:3128 (interception 
> enabled)
> 2024/07/17 21:07:37| WARNING: UPGRADE: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
> Use 'tls-cafile=' instead.
> 2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
> '/etc/dh-parameters.2048'
> OpenSSL-saved error #1: 0x1e08010c
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Processing: https_port 3129 intercept ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Starting Authentication on port [::]:3129
> 2024/07/17 21:07:37| Disabling Authentication on port [::]:3129 (interception 
> enabled)
> 2024/07/17 21:07:37| WARNING: UPGRADE: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in https_port. 
> Use 'tls-cafile=' instead.
> 2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
> '/etc/dh-parameters.2048'
> OpenSSL-saved error #1: 0x1e08010c
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/17 21:0

[squid-users] Squid 6.6 cache_dir rock questions

2024-07-17 Thread Jonathan Lee
Squid 6.6 

Hello fellow Squid users,

What would be the correct way to convert cache_dir disks to rock?

cache_dir diskd /var/squid/cache 64000 256 256

Would it be as simple as..

cache_dir rock /var/squid/cache 64000 256 256?






___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


[squid-users] Squid 6.6 shows configuration failure: requires TPROXY feature to be enabled by ./configure

2024-07-17 Thread Jonathan Lee
How do we enable tproxy in Squid 6.6 in 5.8 we could just adapt the Squid.conf 
and it would enable tproxy 


2024/07/17 21:22:41| Processing Configuration File: 
/usr/local/etc/squid/squid.conf (depth 0)
2024/07/17 21:22:41| Processing: http_port 192.168.1.1:3128 ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/17 21:22:41| WARNING: UPGRADE: 
'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. Use 
'tls-cafile=' instead.
2024/07/17 21:22:41| WARNING: Failed to decode EC parameters 
'/etc/dh-parameters.2048'
OpenSSL-saved error #1: 0x1e08010c
2024/07/17 21:22:41| ERROR: Unsupported TLS option SINGLE_DH_USE
2024/07/17 21:22:41| ERROR: Unsupported TLS option SINGLE_ECDH_USE
2024/07/17 21:22:41| Processing: http_port 127.0.0.1:3128 tproxy ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE

This error never occurred for 5.8
**>2024/07/17 21:22:41| ERROR: configuration failure: requires TPROXY 
feature to be enabled by ./configure**


exception location: Intercept.cc(163) StartTransparency
2024/07/17 21:22:41| Not currently OK to rewrite swap log.
2024/07/17 21:22:41| storeDirWriteCleanLogs: Operation aborted.
2024/07/17 21:22:41| FATAL: Bungled /usr/local/etc/squid/squid.conf line 6: 
http_port 127.0.0.1:3128 tproxy ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/17 21:22:41| Squid Cache (Version 6.6): Terminated abnormally.
CPU Usage: 0.073 seconds = 0.049 user + 0.024 sys
Maximum Resident Size: 62512 KB
Page faults with physical i/o: 0

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-17 Thread Jonathan Lee
Same result 


Shell Output - squidclient -v -h 127.0.0.1 -p 3128 -U cachemgr -W REDACTED 
mgr:info
Request:
GET http://127.0.0.1:3128/squid-internal-mgr/info HTTP/1.0
Host: 127.0.0.1:3128
User-Agent: squidclient/6.6
Accept: */*
Authorization: Basic redacted==
Connection: close


.
HTTP/1.1 403 Forbidden
Server: squid
Mime-Version: 1.0
Date: Thu, 18 Jul 2024 04:09:35 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 3792
X-Squid-Error: ERR_ACCESS_DENIED 0
Vary: Accept-Language
Content-Language: en
Cache-Status: Lee_Family.home.arpa
Cache-Status: Lee_Family.home.arpa;detail=no-cache
Connection: close
I also tested this 

squidclient -l 127.0.0.1 -h localhost mgr:info

Per pfSense Netgate community this seemed to work for users that do not use a 
password directive 

cachemgr_passwd disable offline_toggle reconfigure shutdown
cachemgr_passwd REDACTED_PASSWORD_HERE all

Any other recommendations to try to get the password to work?

> On Jul 17, 2024, at 21:08, Jonathan Lee  wrote:
> 
> 2024/07/17 21:07:37| Processing Configuration File: 
> /usr/local/etc/squid/squid.conf (depth 0)
> 2024/07/17 21:07:37| Processing: http_port 192.168.1.1:3128 ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/17 21:07:37| WARNING: UPGRADE: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
> Use 'tls-cafile=' instead.
> 2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
> '/etc/dh-parameters.2048'
> OpenSSL-saved error #1: 0x1e08010c
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Processing: http_port 3128 intercept ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Starting Authentication on port [::]:3128
> 2024/07/17 21:07:37| Disabling Authentication on port [::]:3128 (interception 
> enabled)
> 2024/07/17 21:07:37| WARNING: UPGRADE: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
> Use 'tls-cafile=' instead.
> 2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
> '/etc/dh-parameters.2048'
> OpenSSL-saved error #1: 0x1e08010c
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Processing: https_port 3129 intercept ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/17 21:07:37| Starting Authentication on port [::]:3129
> 2024/07/17 21:07:37| Disabling Authentication on port [::]:3129 (interception 
> enabled)
> 2024/07/17 21:07:37| WARNING: UPGRADE: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in https_port. 
> Use 'tls-cafile=' instead.
> 2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
> '/etc/dh-parameters.2048'
> OpenSSL-saved error #1: 0x1e08010c
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 
> I removed the : and it processed 
> 
> 
>> On Jul 12, 2024, at 09:52, Amos Jeffries  wrote:
>> 
>> On 13/07/24 04:16, Jonathan Lee wrote:
>>> tested with removal of IP and port failed If I leave port I get this
>>> 2024/07/12 09:15:17| Processing: http_port :3128 intercept
>> 
>> No  ":" b

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-17 Thread Jonathan Lee
2024/07/17 21:07:37| Processing Configuration File: 
/usr/local/etc/squid/squid.conf (depth 0)
2024/07/17 21:07:37| Processing: http_port 192.168.1.1:3128 ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/17 21:07:37| WARNING: UPGRADE: 
'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. Use 
'tls-cafile=' instead.
2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
'/etc/dh-parameters.2048'
OpenSSL-saved error #1: 0x1e08010c
2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_ECDH_USE
2024/07/17 21:07:37| Processing: http_port 3128 intercept ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/17 21:07:37| Starting Authentication on port [::]:3128
2024/07/17 21:07:37| Disabling Authentication on port [::]:3128 (interception 
enabled)
2024/07/17 21:07:37| WARNING: UPGRADE: 
'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. Use 
'tls-cafile=' instead.
2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
'/etc/dh-parameters.2048'
OpenSSL-saved error #1: 0x1e08010c
2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_ECDH_USE
2024/07/17 21:07:37| Processing: https_port 3129 intercept ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/17 21:07:37| Starting Authentication on port [::]:3129
2024/07/17 21:07:37| Disabling Authentication on port [::]:3129 (interception 
enabled)
2024/07/17 21:07:37| WARNING: UPGRADE: 
'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in https_port. 
Use 'tls-cafile=' instead.
2024/07/17 21:07:37| WARNING: Failed to decode EC parameters 
'/etc/dh-parameters.2048'
OpenSSL-saved error #1: 0x1e08010c
2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_DH_USE
2024/07/17 21:07:37| ERROR: Unsupported TLS option SINGLE_ECDH_USE

I removed the : and it processed 


> On Jul 12, 2024, at 09:52, Amos Jeffries  wrote:
> 
> On 13/07/24 04:16, Jonathan Lee wrote:
>> tested with removal of IP and port failed If I leave port I get this
>> 2024/07/12 09:15:17| Processing: http_port :3128 intercept
> 
> No  ":" before thr port number.
> 
> 
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Tproxy or intercept

2024-07-14 Thread Jonathan Lee
IPv4 only ips, I have a BE with tunnel broker that I test out but my IPS IDS 
can’t inspect the tunnel 
Sent from my iPhone

> On Jul 14, 2024, at 22:49, Andrea Venturoli  wrote:
> 
> On 7/13/24 20:48, Jonathan Lee wrote:
>> It works 6.6 it just have a different requirement to enable it. I am using a 
>> Netgate 2100 with pfSense. The difference is that it spoofs the IP of the 
>> client so the host doesn’t see the IP of the firewall when using intercept I 
>> am told. So transparent with more of a hidden layer
> 
> Well, in my case the client IP is everywhere a private one, so the host (the 
> public web server?) will always see the IP of the firewall.
> Are you using IPv6?
> 
> bye & Thanks
>av.
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Tproxy or intercept

2024-07-13 Thread Jonathan Lee
Best way to describe it is transparent intercept maybe… tproxy takes place of 
intercept on the http_port directive 
Sent from my iPhone

> On Jul 13, 2024, at 11:49, Jonathan Lee  wrote:
> 
> It works 6.6 it just have a different requirement to enable it. I am using a 
> Netgate 2100 with pfSense. The difference is that it spoofs the IP of the 
> client so the host doesn’t see the IP of the firewall when using intercept I 
> am told. So transparent with more of a hidden layer
> Sent from my iPhone
> 
>>> On Jul 13, 2024, at 10:52, Andrea Venturoli  wrote:
>>> 
>>> On 7/13/24 17:04, Jonathan David Lee FreeBSD Alpine wrote:
>>> Do you consider pfsense freebsd or openbsd based
>> 
>> I know nothing about pfsense.
>> 
>>> becaause it does work,
>> 
>> Good to know.
>> What kind of firewall do you use? ipfw? pf? other?
>> 
>>> it does not in squid 6.6 requires a different ./ command in squid 5.8 you 
>>> can just enable it
>> 
>> Then again, if it doesn't work with 6.6, it's useless to me.
>> 
>> What would be the benefit of using tproxy instead of intercept, anyway?
>> 
>> bye & Thanks
>>   av.
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Tproxy or intercept

2024-07-13 Thread Jonathan Lee
It works 6.6 it just have a different requirement to enable it. I am using a 
Netgate 2100 with pfSense. The difference is that it spoofs the IP of the 
client so the host doesn’t see the IP of the firewall when using intercept I am 
told. So transparent with more of a hidden layer 
Sent from my iPhone

> On Jul 13, 2024, at 10:52, Andrea Venturoli  wrote:
> 
> On 7/13/24 17:04, Jonathan David Lee FreeBSD Alpine wrote:
>> Do you consider pfsense freebsd or openbsd based
> 
> I know nothing about pfsense.
> 
>> becaause it does work,
> 
> Good to know.
> What kind of firewall do you use? ipfw? pf? other?
> 
>> it does not in squid 6.6 requires a different ./ command in squid 5.8 you 
>> can just enable it
> 
> Then again, if it doesn't work with 6.6, it's useless to me.
> 
> What would be the benefit of using tproxy instead of intercept, anyway?
> 
> bye & Thanks
>av.
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


[squid-users] Tproxy or intercept

2024-07-12 Thread Jonathan Lee
For the HTTP and https derivative is it better to use tproxy or intercept on 
FreeBSD? 
Sent from my iPhone
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-12 Thread Jonathan Lee
Sorry that test was on the 5.8 version I am using that boot environment right 
now. All others were on 6.6 does 6.6 support no IP port combo?
Sent from my iPhone

> On Jul 12, 2024, at 09:16, Jonathan Lee  wrote:
> 
> tested with removal of IP and port failed If I leave port I get this
> 
> 2024/07/12 09:15:17| Processing: http_port :3128 intercept ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/12 09:15:17| FATAL: http_port: failed to resolve Host/IP:
> 2024/07/12 09:15:17| Not currently OK to rewrite swap log.
> 2024/07/12 09:15:17| storeDirWriteCleanLogs: Operation aborted.
> 2024/07/12 09:15:17| FATAL: Bungled /usr/local/etc/squid/squid.conf line 6: 
> http_port :3128 intercept ssl-bump generate-host-certificates=on 
> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/12 09:15:17| Squid Cache (Version 5.8): Terminated abnormally.
> 
>> On Jul 12, 2024, at 09:09, Jonathan Lee  wrote:
>> 
>> Thanks I fixed the firewall rules, I am trying tproxy and it seems to help 
>> with speed right now.
>> Sent from my iPhone
>> 
>>> On Jul 12, 2024, at 04:57, Amos Jeffries  wrote:
>>> 
>>> On 12/07/24 11:50, Jonathan Lee wrote:
>>>>> I recommend changing your main port to this:
>>>>> 
>>>>>  http_port 3128 ssl-bump 
>>>> This is set to this when it processes
>>>> http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
>>>> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
>>>> cafile=/usr/local/share/certs/ca-root-nss.crt 
>>>> capath=/usr/local/share/certs/ 
>>>> 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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
>>>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>>>> options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
>>> 
>>> The key thing here was the removal of the IP address. So that Squid 
>>> received both the 192.168.*.* and the 127.0.0.* traffic without needing 
>>> separate http_port lines.
>>> 
>>> 
>>> 
>>>>> and receiving the intercepted traffic on:
>>>>> 
>>>>> http_port 3129 intercept ssl-bump …
>>>> Do you mean https?
>>> 
>>> Sorry. I missed that you had an https_port using 3129 already.
>>> 
>>> 
>>> 
>>>> https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on 
>>>> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
>>>> cafile=/usr/local/share/certs/ca-root-nss.crt 
>>>> capath=/usr/local/share/certs/ 
>>>> 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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
>>>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>>>> options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
>>>> Https uses that port 3129
>>>> What should I adapt
>>>> http_port
>>>> https_port?
>>> 
>>> Both.
>>> 
>>> FYI, there are two issues:
>>> 
>>> 1) listening on IP 127.0.0.1. Inside the OS there are different devices for 
>>> localhost (lo) and WAN (eg. eth0). NAT is problematic already without 
>>> introducing any tricky behaviours from bridging those "private" (lo) and 
>>> "public" WAN devices.
>>> 
>>> The simplest solution is just not to put any IP address on the squid.conf 
>>> *port line(s) with intercept options. The OS will select one appropriate 
>>> for whatever 

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-12 Thread Jonathan Lee
tested with removal of IP and port failed If I leave port I get this

2024/07/12 09:15:17| Processing: http_port :3128 intercept ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/12 09:15:17| FATAL: http_port: failed to resolve Host/IP:
2024/07/12 09:15:17| Not currently OK to rewrite swap log.
2024/07/12 09:15:17| storeDirWriteCleanLogs: Operation aborted.
2024/07/12 09:15:17| FATAL: Bungled /usr/local/etc/squid/squid.conf line 6: 
http_port :3128 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/12 09:15:17| Squid Cache (Version 5.8): Terminated abnormally.

> On Jul 12, 2024, at 09:09, Jonathan Lee  wrote:
> 
> Thanks I fixed the firewall rules, I am trying tproxy and it seems to help 
> with speed right now. 
> Sent from my iPhone
> 
>> On Jul 12, 2024, at 04:57, Amos Jeffries  wrote:
>> 
>> On 12/07/24 11:50, Jonathan Lee wrote:
>>>> I recommend changing your main port to this:
>>>> 
>>>>  http_port 3128 ssl-bump 
>>> This is set to this when it processes
>>> http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
>>> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
>>> cafile=/usr/local/share/certs/ca-root-nss.crt 
>>> capath=/usr/local/share/certs/ 
>>> 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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
>>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>>> options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
>> 
>> The key thing here was the removal of the IP address. So that Squid received 
>> both the 192.168.*.* and the 127.0.0.* traffic without needing separate 
>> http_port lines.
>> 
>> 
>> 
>>>> and receiving the intercepted traffic on:
>>>> 
>>>> http_port 3129 intercept ssl-bump …
>>> Do you mean https?
>> 
>> Sorry. I missed that you had an https_port using 3129 already.
>> 
>> 
>> 
>>> https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on 
>>> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
>>> cafile=/usr/local/share/certs/ca-root-nss.crt 
>>> capath=/usr/local/share/certs/ 
>>> 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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
>>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>>> options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
>>> Https uses that port 3129
>>> What should I adapt
>>> http_port
>>> https_port?
>> 
>> Both.
>> 
>> FYI, there are two issues:
>> 
>> 1) listening on IP 127.0.0.1. Inside the OS there are different devices for 
>> localhost (lo) and WAN (eg. eth0). NAT is problematic already without 
>> introducing any tricky behaviours from bridging those "private" (lo) and 
>> "public" WAN devices.
>> 
>> The simplest solution is just not to put any IP address on the squid.conf 
>> *port line(s) with intercept options. The OS will select one appropriate for 
>> whatever device and tell Squid on a per-connection basis.
>> 
>> The more difficult way is to put one of the machines "global" (WAN or LAN) 
>> IP addresses. In your case 192.168.1.1. With most connections being from the 
>> LAN that minimizes the possible problems.
>> 
>> 
>> 2) listening on a well-known proxy port 3128 for intercepted traffic.
>> 
>> There is malware in existence that scans for at least port 3128 (likely 
>> 1080, 8080 etc common proxy ports) being used by proxies like yours and 
>&

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-12 Thread Jonathan Lee
Thanks I fixed the firewall rules, I am trying tproxy and it seems to help with 
speed right now. 
Sent from my iPhone

> On Jul 12, 2024, at 04:57, Amos Jeffries  wrote:
> 
> On 12/07/24 11:50, Jonathan Lee wrote:
>>> I recommend changing your main port to this:
>>> 
>>>   http_port 3128 ssl-bump 
>> This is set to this when it processes
>> http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
>> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
>> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
>> 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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
> 
> The key thing here was the removal of the IP address. So that Squid received 
> both the 192.168.*.* and the 127.0.0.* traffic without needing separate 
> http_port lines.
> 
> 
> 
>>> and receiving the intercepted traffic on:
>>> 
>>>  http_port 3129 intercept ssl-bump …
>> Do you mean https?
> 
> Sorry. I missed that you had an https_port using 3129 already.
> 
> 
> 
>> https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on 
>> dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
>> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
>> 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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
>> Https uses that port 3129
>> What should I adapt
>> http_port
>> https_port?
> 
> Both.
> 
> FYI, there are two issues:
> 
> 1) listening on IP 127.0.0.1. Inside the OS there are different devices for 
> localhost (lo) and WAN (eg. eth0). NAT is problematic already without 
> introducing any tricky behaviours from bridging those "private" (lo) and 
> "public" WAN devices.
> 
> The simplest solution is just not to put any IP address on the squid.conf 
> *port line(s) with intercept options. The OS will select one appropriate for 
> whatever device and tell Squid on a per-connection basis.
> 
> The more difficult way is to put one of the machines "global" (WAN or LAN) IP 
> addresses. In your case 192.168.1.1. With most connections being from the LAN 
> that minimizes the possible problems.
> 
> 
> 2) listening on a well-known proxy port 3128 for intercepted traffic.
> 
> There is malware in existence that scans for at least port 3128 (likely 1080, 
> 8080 etc common proxy ports) being used by proxies like yours and abuses 
> them. As a result at least one popular antivirus network scanner (from Trend) 
> does the same scan to detect insecure proxies.
> 
> The worst thing about this situation is that the NAT very effectively hides 
> the malware. So it is extremely hard to see whether it is happening to you.
> 
> 
> I am not sure what UI you are using to show those firewall rules in your 
> other email. However the one that had ALLOW for the port range 3128-3129 
> worries me. AFAIK that should only be for 3128 and a separate rule somewhere 
> else to drop the intercepted port 3129 traffic pre-NAT.
> 
> 
> HTH
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid 6.6 error clientProcessHit: Vary object loop!

2024-07-11 Thread Jonathan Lee
Thanks for the reply.

Proxy technology amazes me as I am a computer science student. I feel 
generation 2 proxy technology is key to stopping invasive containers within a 
cybersecurity perspective. Again to spot them you need to cache them and scan 
for fingerprints, thus my fascination with Squid. 

Thanks again 
Sent from my iPhone

> On Jul 11, 2024, at 22:02, Amos Jeffries  wrote:
> 
> On 12/07/24 06:43, Jonathan Lee wrote:
>> What is Vary Object loop??
> 
> In HTTP URLs can point at a set or "variants" of a resource.
> 
> Squid "Vary Object" is an entry in the cache that is used to represent these 
> types of resource.
> When the URL-only is looked up, the "Vary Object" is found and tells Squid to 
> perform a second lookup appending certain details to the hash key to find the 
> actual object that client needs.
> 
> A "Vary Object loop" is when this second lookup finds an object which is not 
> the desired variant of that original URL.
> 
> 
> You can see this in your first message ...
> 
> 
> >> 10.07.2024 09:56:30clientProcessHit: Vary object loop!
> >> 10.07.2024 09:56:30varyEvaluateMatch: Oops. Not a Vary match on
> >> second attempt,
> 
> Original request came in for "https%3A%2F%2Fstatic.foxnews.com"
> 
> That URL had a cached "Vary Object" saying there were different responses to 
> provide depending on the Accept-Encoding header:
> 
> Squdi performed a second lookup for:
> 
> >> 'origin="https%3A%2F%2Fstatic.foxnews.com", 
> >> accept-encoding="gzip,%20deflate,%20br,%20zstd"'
> 
> 
> ... which found a cache entry for this URL:
> 
> >> 'https://zagent20.h-cdn.com/cmd/get_thumb_info?customer=foxnews&ver=1.165.67&url=https%3A%2F%2F247preview.foxnews.com%2Fhls%2Flive%2F2020027%2Ffncv3preview%2Findex.m3u8'
> 
> 
> which is not the same URL.
> 
> 
> 
>> Does that  mean clear my cache?
> 
> No. But yes.
> 
> A quick check of the URLs from your log message with the tool at 
> <https://redbot.org/?uri=https://static.foxnews.com/static/orion/styles/css/fox-news/article-new.rs.css>
> 
> We can see that:
> 
> "
>The resource doesn't send Vary consistently.
>The ETag doesn't change between negotiated representations.
> "
> 
> 
> You can ignore these log messages.
> 
> Or, you can configure Squid not to cache content from this server. If you do 
> this, then clearing the cache would stop the log entries continuing.
> 
> 
>> Or is that something I am missing has anyone else seen this?
> 
> That origin server is broken. So likely everyone is seeing the same problem 
> with that website.
> 
> 
>> 11.07.2024 11:36:49clientProcessHit: Vary object loop!
>> 11.07.2024 11:36:49varyEvaluateMatch: Oops. Not a Vary match on second 
>> attempt, 
>> 'https://static.foxnews.com/static/orion/styles/css/fox-news/article-new.rs.css9;
>>  'accept-encoding="gzip,%20deflate,%20br,%20zstd"'
>> 11.07.2024 11:36:49clientProcessHit: Vary object loop!
>> 11.07.2024 11:36:49varyEvaluateMatch: Oops. Not a Vary match on second 
>> attempt, 
>> 'https://static.foxnews.com/static/strike/ver/foxnews/loader.global.js' 
>> 'accept-encoding="gzip,%20deflate,%20br,%20zstd"'
>> 31.12.1969 16:00:00
> 
> 
> 
> Cheers
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-11 Thread Jonathan Lee
Here is how it is set

http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE

http_port 127.0.0.1:3128 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE

https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE

Should be???

http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE

http_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE

https_port 127.0.0.1:3129? intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE


> On Jul 11, 2024, at 14:49, Amos Jeffries  wrote:
> 
> Oh, I see the problem:
> 
>  http_port 127.0.0.1:3128 intercept ...
> 
> (which also means you lack a firewall rule preventing external software like 
> squidclient from sending traffic directly to your intercept port.)
> 
> 
> Please **do not** use port 3128 to receive intercepted traffic.
> 
> 
> I recommend changing your main port to this:
> 
>   http_port 3128 ssl-bump 
> 
> and receiving the intercepted traffic on:
> 
>  http_port 3129 intercept ssl-bump ...
> 
> 
> and check your firewall has all the rules listed at 
> .
> One to note in particular is the "mangle" table rule.
> 
> 
> Cheers
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-11 Thread Jonathan Lee
> I recommend changing your main port to this:
> 
>   http_port 3128 ssl-bump 

This is set to this when it processes

http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE

> and receiving the intercepted traffic on:
> 
>  http_port 3129 intercept ssl-bump …

Do you mean https?

https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
Https uses that port 3129

What should I adapt 

http_port 
https_port?



> On Jul 11, 2024, at 14:49, Amos Jeffries  wrote:
> 
> Oh, I see the problem:
> 
>  http_port 127.0.0.1:3128 intercept ...
> 
> (which also means you lack a firewall rule preventing external software like 
> squidclient from sending traffic directly to your intercept port.)
> 
> 
> Please **do not** use port 3128 to receive intercepted traffic.
> 
> 
> I recommend changing your main port to this:
> 
>   http_port 3128 ssl-bump 
> 
> and receiving the intercepted traffic on:
> 
>  http_port 3129 intercept ssl-bump ...
> 
> 
> and check your firewall has all the rules listed at 
> .
> One to note in particular is the "mangle" table rule.
> 
> 
> Cheers
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-11 Thread Jonathan Lee
4:09:27| Processing: acl bump_only_mac arp 
2024/07/11 14:09:27| Processing: acl bump_only_mac arp 
2024/07/11 14:09:27| Processing: acl bump_only_mac arp 
2024/07/11 14:09:27| Processing: sslproxy_cert_sign signTrusted bump_only_mac
2024/07/11 14:09:27| Processing: ssl_bump peek step1
2024/07/11 14:09:27| Processing: miss_access deny no_miss active_use
2024/07/11 14:09:27| Processing: ssl_bump splice https_login active_use
2024/07/11 14:09:27| Processing: ssl_bump splice splice_only_mac splice_only 
active_use
2024/07/11 14:09:27| Processing: ssl_bump splice NoBumpDNS active_use
2024/07/11 14:09:27| Processing: ssl_bump splice NoSSLIntercept active_use
2024/07/11 14:09:27| Processing: ssl_bump bump bump_only_mac bump_only 
active_use
2024/07/11 14:09:27| Processing: acl activated note active_use true
2024/07/11 14:09:27| Processing: ssl_bump terminate !activated
2024/07/11 14:09:27| Processing: shutdown_lifetime 1 seconds
2024/07/11 14:09:27| Processing: negative_dns_ttl 5 minutes
2024/07/11 14:09:27| Processing: http_access allow localnet
2024/07/11 14:09:27| Processing: http_access deny allsrc
2024/07/11 14:09:27| WARNING: use of 'override-expire' in 'refresh_pattern' 
violates HTTP
2024/07/11 14:09:27| WARNING: use of 'override-lastmod' in 'refresh_pattern' 
violates HTTP
2024/07/11 14:09:27| WARNING: use of 'reload-into-ims' in 'refresh_pattern' 
violates HTTP
2024/07/11 14:09:27| WARNING: use of 'ignore-reload' in 'refresh_pattern' 
violates HTTP
2024/07/11 14:09:27| WARNING: use of 'ignore-no-store' in 'refresh_pattern' 
violates HTTP
2024/07/11 14:09:27| WARNING: use of 'ignore-private' in 'refresh_pattern' 
violates HTTP
2024/07/11 14:09:27| WARNING: HTTP requires the use of Via
2024/07/11 14:09:27| Requiring client certificates.
2024/07/11 14:09:28| Loaded signing certificate: 
/CN=internal-ca/C=US/ST=California/L=Roseville/O=Homeuse
2024/07/11 14:09:29| Not requiring any client certificates
2024/07/11 14:09:29| Loaded signing certificate: 
/CN=internal-ca/C=US/ST=California/L=Roseville/O=Homeuse
2024/07/11 14:09:30| Not requiring any client certificates
2024/07/11 14:09:30| Loaded signing certificate: 
/CN=internal-ca/C=US/ST=California/L=Roseville/O=Homeuse
2024/07/11 14:09:30| Not requiring any client certificates

> On Jul 11, 2024, at 13:16, Amos Jeffries  wrote:
> 
> 
> Lets see ...
> 
> >>> On Jul 11, 2024, at 11:02, Jonathan Lee wrote:
> >>> Shell Output - squidclient -h 127.0.0.1 -v -U admin -W redacted
> >>> mgr:info
> >>>
> >>> Request:
> >>> GET http://127.0.0.1:3128/squid-internal-mgr/info HTTP/1.0
> >>> Host: 127.0.0.1:3128
> >>> User-Agent: squidclient/6.6
> >>> Accept: */*
> >>> Authorization: Basic YWRtaW4..REDACTED..Q==
> >>> Connection: close
> 
> 
> On 12/07/24 06:12, Jonathan Lee wrote:
>> http_access allow CONNECT wuCONNECT localnet
>> http_access allow CONNECT wuCONNECT localhost
> 
> 
> ... GET is not CONNECT. Skip the above.
> 
> 
>> http_access allow windowsupdate localnet
>> http_access allow windowsupdate localhost
> 
> 
> ... 127.0.0.1 is not in *.microsoft.com. Skip the above.
> 
> 
>> http_access allow HttpAccess localnet
>> http_access allow HttpAccess localhost
> 
> 
> ... 127.0.0.1 is not listed in /usr/local/pkg/http.access. Skip the above.
> 
> 
>> http_access deny manager
> 
> 
> ... /squid-internal-mgr/ matches.  DENY the request.
> 
> 
> Problem solved.
> 
> What you should do is restore the default security settings which we ship 
> with Squid.
> 
> Place these above your custom http_access lines:
> 
>  http_access deny !Safe_ports
>  http_access deny CONNECT !SSL_ports
>  http_access allow localhost manager
>  http_access deny manager
> 
> 
> see <https://wiki.squid-cache.org/Releases/Squid-5> for the ACL details if 
> you need them too.
> 
> 
> 
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-11 Thread Jonathan Lee
Ok I sent output prior email that shows the right path but says access denied 
Sent from my iPhone

> On Jul 11, 2024, at 12:59, Amos Jeffries  wrote:
> 
> On 12/07/24 05:27, Jonathan Lee wrote:
>> Thanks what about the password is it set with@ or -p where would I place 
>> that?
> 
> Neither. It is set with -W .
> 
> Amos
> 
> 
>> Sent from my iPhone
>>>> On Jul 11, 2024, at 10:17, Amos Jeffries wrote:
>>> 
>>> It is very relevant. As Matus already mentioned, both -U and -W.
>>> 
>>> 
>>> squidclient -v -U admin -W cachemgr_password mgr:info
>>> Request:
>>> GET http://localhost:3128/squid-internal-mgr/info HTTP/1.0
>>> Host: localhost:3128
>>> User-Agent: squidclient/6.10
>>> Accept: */*
>>> Authorization: Basic YWRtaW46Y2FjaGVtZ3JfcGFzc3dvcmQ=
>>> Connection: close
>>> 
>>> 
>>> squidclient -v -U admin -W cachemgr_password /squid-internal-mgr/info
>>> Request:
>>> GET /squid-internal-mgr/info HTTP/1.0
>>> Host: localhost:3128
>>> User-Agent: squidclient/6.10
>>> Accept: */*
>>> Authorization: Basic YWRtaW46Y2FjaGVtZ3JfcGFzc3dvcmQ=
>>> Connection: close
>>> 
>>> 
>>> Cheers
>>> Amos
>>> ___
>>> squid-users mailing list
>>> squid-users@lists.squid-cache.org
>>> https://lists.squid-cache.org/listinfo/squid-users
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid 6.6 error clientProcessHit: Vary object loop!

2024-07-11 Thread Jonathan Lee
What is Vary Object loop??

Does that  mean clear my cache? Or is that something I am missing has anyone 
else seen this?

11.07.2024 11:36:49 clientProcessHit: Vary object loop!
11.07.2024 11:36:49 varyEvaluateMatch: Oops. Not a Vary match on second 
attempt, 
'https://static.foxnews.com/static/orion/styles/css/fox-news/article-new.rs.css9;
 'accept-encoding="gzip,%20deflate,%20br,%20zstd"'
11.07.2024 11:36:49 clientProcessHit: Vary object loop!
11.07.2024 11:36:49 varyEvaluateMatch: Oops. Not a Vary match on second 
attempt, 
'https://static.foxnews.com/static/strike/ver/foxnews/loader.global.js' 
'accept-encoding="gzip,%20deflate,%20br,%20zstd"'
31.12.1969 16:00:00 
11.07.2024 11:36:40 SECURITY ALERT: on URL: mask.icloud.com:443
31.12.1969 16:00:00 
11.07.2024 11:36:40 SECURITY ALERT: Host header forgery detected on 
conn10283 local=17.248.245.233:443 remote=192.168.1.10:55733 FD 37 flags=33 
(local IP does not match any domain IP)
31.12.1969 16:00:00 
11.07.2024 11:36:37 SECURITY ALERT: on URL: mask.icloud.com:443
31.12.1969 16:00:00 
11.07.2024 11:36:37 SECURITY ALERT: Host header forgery detected on 
conn10215 local=17.248.245.132:443 remote=192.168.1.10:55730 FD 26 flags=33 
(local IP does not match any domain IP)
31.12.1969 16:00:00 
11.07.2024 11:36:36 ERROR: failure while accepting a TLS connection on 
conn10136 local=17.248.245.36:443 remote=192.168.1.5:50800 FD 61 flags=33: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
11.07.2024 11:36:36 clientProcessHit: Vary object loop!
11.07.2024 11:36:36 varyEvaluateMatch: Oops. Not a Vary match on second 
attempt, 'https://www.foxnews.com/_wzln/59f1c12.js' 
'accept-encoding="gzip,%20deflate,%20br,%20zstd"'
11.07.2024 11:36:34 clientProcessHit: Vary object loop!
11.07.2024 11:36:34 varyEvaluateMatch: Oops. Not a Vary match on second 
attempt, 'https://www.foxnews.com/_wzln/77963e9.js' 
'accept-encoding="gzip,%20deflate,%20br,%20zstd"'
31.12.1969 16:00:00 
11.07.2024 11:36:30 SECURITY ALERT: on URL: mask.icloud.com:443
31.12.1969 16:00:00 
11.07.2024 11:36:30 SECURITY ALERT: Host header forgery detected on 
conn10151 local=17.248.245.132:443 remote=192.168.1.10:55728 FD 84 flags=33 
(local IP does not match any domain IP)
11.07.2024 11:36:28 clientProcessHit: Vary object loop!
11.07.2024 11:36:28 varyEvaluateMatch: Oops. Not a Vary match on second 
attempt, 'https://www.foxnews.com/_wzln/bb8a19f.js' 
'accept-encoding="gzip,%20deflate,%20br,%20zstd"'
31.12.1969 16:00:00 
11.07.2024 11:36:27 SECURITY ALERT: on URL: mask.icloud.com:443
31.12.1969 16:00:00 
11.07.2024 11:36:27 SECURITY ALERT: Host header forgery detected on 
conn10117 local=17.248.245.229:443 remote=192.168.1.10:55726 FD 32 flags=33 
(local IP does not match any domain IP)
31.12.1969 16:00:00 
11.07.2024 11:36:19 SECURITY ALERT: on URL: mask-h2.icloud.com:443
31.12.1969 16:00:00 
11.07.2024 11:36:19 SECURITY ALERT: Host header forgery detected on 
conn1 local=17.248.245.233:443 remote=192.168.1.10:55724 FD 93 flags=33 
(local IP does not match any domain IP)
31.12.1969 16:00:00 
11.07.2024 11:36:16 SECURITY ALERT: on URL: mask-h2.icloud.com:443
31.12.1969 16:00:00 
11.07.2024 11:36:16 SECURITY ALERT: Host header forgery detected on 
conn9981 local=17.248.245.132:443 remote=192.168.1.10:55722 FD 107 flags=33 
(local IP does not match any domain IP)
31.12.1969 16:00:00 
11.07.2024 11:36:16 SECURITY ALERT: on URL: mask-h2.icloud.com:443
31.12.1969 16:00:00 
11.07.2024 11:36:16 SECURITY ALERT: Host header forgery detected on 
conn9975 local=17.248.245.229:443 remote=192.168.1.10:55721 FD 102 flags=33 
(local IP does not match any domain IP)
31.12.1969 16:00:00


> On Jul 10, 2024, at 09:57, Jonathan Lee  wrote:
> 
> Has anyone seen this before? on hits?
> 
> 
> 10.07.2024 09:56:30   clientProcessHit: Vary object loop!
> 10.07.2024 09:56:30   varyEvaluateMatch: Oops. Not a Vary match on second 
> attempt, 
> 'https://zagent20.h-cdn.com/cmd/get_thumb_info?customer=foxnews&ver=1.165.67&url=https%3A%2F%2F247preview.foxnews.com%2Fhls%2Flive%2F2020027%2Ffncv3preview%2Findex.m3u8'
>  'origin="https%3A%2F%2Fstatic.foxnews.com", 
> accept-encoding="gzip,%20deflate,%20br,%20zstd"'
> 31.12.1969 16:00:00   
> 31.12.1969 16:00:00   
> 31.12.1969 16:00:00   
> 31.12.1969 16:00:00   
> 31.12.1969 16:00:00   
> 31.12.1969 16:00:00   
> 31.12.1969 16:00:00

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-11 Thread Jonathan Lee
Could this cause the issue?

acl https_login url_regex -i ^https.*(login|Login).*
cache deny https_login


> On Jul 11, 2024, at 11:12, Jonathan Lee  wrote:
> 
> cachemgr_passwd disable offline_toggle reconfigure shutdown
> cachemgr_passwd PASSWORDREDCATED all
> eui_lookup on
> acl no_miss url_regex -i gateway\.facebook\.com\/ws\/realtime\?
> acl no_miss url_regex -i web-chat-e2ee\.facebook\.com\/ws\/chat
> acl CONNECT method CONNECT
> acl wuCONNECT dstdomain www.update.microsoft.com
> acl wuCONNECT dstdomain sls.microsoft.com
> http_access allow CONNECT wuCONNECT localnet
> http_access allow CONNECT wuCONNECT localhost
> http_access allow windowsupdate localnet
> http_access allow windowsupdate localhost
> http_access allow HttpAccess localnet
> http_access allow HttpAccess localhost
> http_access deny manager
> http_access deny to_ipv6
> http_access deny from_ipv6
> 
> acl BrokenButTrustedServers dstdomain "/usr/local/pkg/dstdom.broken"
> acl DomainMismatch ssl_error SQUID_X509_V_ERR_DOMAIN_MISMATCH
> sslproxy_cert_error allow BrokenButTrustedServers DomainMismatch
> sslproxy_cert_error deny all
> 
> acl splice_only src 192.168.1.8 #Tasha iPhone
> acl splice_only src 192.168.1.10 #Jon iPhone
> acl splice_only src 192.168.1.11 #Amazon Fire
> acl splice_only src 192.168.1.15 #Tasha HP
> acl splice_only src 192.168.1.16 #iPad
> 
> acl splice_only_mac arp MACADDRESSREDACTED
> acl splice_only_mac arp MACADDRESSREDACTED
> acl splice_only_mac arp MACADDRESSREDACTED
> acl splice_only_mac arp MACADDRESSREDACTED
> acl splice_only_mac arp MACADDRESSREDACTED
> 
> acl NoSSLIntercept ssl::server_name_regex -i "/usr/local/pkg/reg.url.nobump"
> acl NoBumpDNS dstdomain "/usr/local/pkg/dns.nobump"
> 
> acl markBumped annotate_client bumped=true
> acl active_use annotate_client active=true
> acl bump_only src 192.168.1.3 #webtv
> acl bump_only src 192.168.1.4 #toshiba
> acl bump_only src 192.168.1.5 #imac
> acl bump_only src 192.168.1.9 #macbook
> acl bump_only src 192.168.1.13 #dell
> 
> acl bump_only_mac arp MACADDRESSREDACTED
> acl bump_only_mac arp MACADDRESSREDACTED
> acl bump_only_mac arp MACADDRESSREDACTED
> acl bump_only_mac arp MACADDRESSREDACTED
> acl bump_only_mac arp MACADDRESSREDACTED
> sslproxy_cert_sign signTrusted bump_only_mac
> 
> 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 NoBumpDNS active_use
> ssl_bump splice NoSSLIntercept active_use
> ssl_bump bump bump_only_mac bump_only active_use
> acl activated note active_use true
> ssl_bump terminate !activated
> 
> shutdown_lifetime 1 seconds
> negative_dns_ttl 5 minutes
> 
> 
> Does the MAC address and bump have anything to do with it? This worked in the 
> older versions without having to input a MAC for the loopback
> 
>> On Jul 11, 2024, at 11:08, Jonathan Lee  wrote:
>> 
>> I use http access acl set as followed 
>> 
>> acl getmethod method GET
>> acl to_ipv6 dst ipv6
>> acl from_ipv6 src ipv6
>> acl HttpAccess dstdomain "/usr/local/pkg/http.access”
>> 
>> 
>> /usr/local/pkg/http.access
>> contains:
>> office.com
>> data.microsoft.com
>> windowsupdate.com
>> dc1-st.ksn.kaspersky-labs.com
>> dc1-file.ksn.kaspersky-labs.com
>> dc1.ksn.kaspersky-labs.com
>> gsa.apple.com
>> apps.apple.com
>> certs.apple.com
>> crl.apple.com
>> entrust.net
>> digicert.com
>> ocsp.apple.com
>> ocsp2.apple.com
>> valid.apple.com
>> push.apple.com
>> itunes.apple.com
>> appldnld.apple.com
>> gg.apple.com
>> gs.apple.com
>> mesu.apple.com
>> oscdn.apple.com
>> osrecovery.apple.com
>> swcdn.apple.com
>> swdownload.apple.com
>> updates-http.cdn-apple.com
>> appldnld.apple.com.edgesuite.net
>> suconfig.apple.com
>> audiocontentdownload.apple.com
>> devimages-cdn.apple.com
>> download.developer.apple.com
>> sylvan.apple.com
>> static.ips.apple.com
>> 
>> 
>> http_access allow CONNECT wuCONNECT localnet
>> http_access allow CONNECT wuCONNECT localhost
>> http_access allow windowsupdate localnet
>> http_access allow windowsupdate localhost
>> http_access allow HttpAccess localnet
>> http_access allow HttpAccess localhost
>> http_access deny manager
>> http_access deny to_ipv6
>> http_access deny from_ipv6 
>> 
>>> On Jul 11, 2024, at 11:02, Jonathan Lee  wrote:
>>> 
>>> also 
>>> 
>>> Shell Output - squidclient -h 127.0.0

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-11 Thread Jonathan Lee
cachemgr_passwd disable offline_toggle reconfigure shutdown
cachemgr_passwd PASSWORDREDCATED all
eui_lookup on
acl no_miss url_regex -i gateway\.facebook\.com\/ws\/realtime\?
acl no_miss url_regex -i web-chat-e2ee\.facebook\.com\/ws\/chat
acl CONNECT method CONNECT
acl wuCONNECT dstdomain www.update.microsoft.com
acl wuCONNECT dstdomain sls.microsoft.com
http_access allow CONNECT wuCONNECT localnet
http_access allow CONNECT wuCONNECT localhost
http_access allow windowsupdate localnet
http_access allow windowsupdate localhost
http_access allow HttpAccess localnet
http_access allow HttpAccess localhost
http_access deny manager
http_access deny to_ipv6
http_access deny from_ipv6

acl BrokenButTrustedServers dstdomain "/usr/local/pkg/dstdom.broken"
acl DomainMismatch ssl_error SQUID_X509_V_ERR_DOMAIN_MISMATCH
sslproxy_cert_error allow BrokenButTrustedServers DomainMismatch
sslproxy_cert_error deny all

acl splice_only src 192.168.1.8 #Tasha iPhone
acl splice_only src 192.168.1.10 #Jon iPhone
acl splice_only src 192.168.1.11 #Amazon Fire
acl splice_only src 192.168.1.15 #Tasha HP
acl splice_only src 192.168.1.16 #iPad

acl splice_only_mac arp MACADDRESSREDACTED
acl splice_only_mac arp MACADDRESSREDACTED
acl splice_only_mac arp MACADDRESSREDACTED
acl splice_only_mac arp MACADDRESSREDACTED
acl splice_only_mac arp MACADDRESSREDACTED

acl NoSSLIntercept ssl::server_name_regex -i "/usr/local/pkg/reg.url.nobump"
acl NoBumpDNS dstdomain "/usr/local/pkg/dns.nobump"

acl markBumped annotate_client bumped=true
acl active_use annotate_client active=true
acl bump_only src 192.168.1.3 #webtv
acl bump_only src 192.168.1.4 #toshiba
acl bump_only src 192.168.1.5 #imac
acl bump_only src 192.168.1.9 #macbook
acl bump_only src 192.168.1.13 #dell

acl bump_only_mac arp MACADDRESSREDACTED
acl bump_only_mac arp MACADDRESSREDACTED
acl bump_only_mac arp MACADDRESSREDACTED
acl bump_only_mac arp MACADDRESSREDACTED
acl bump_only_mac arp MACADDRESSREDACTED
sslproxy_cert_sign signTrusted bump_only_mac

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 NoBumpDNS active_use
ssl_bump splice NoSSLIntercept active_use
ssl_bump bump bump_only_mac bump_only active_use
acl activated note active_use true
ssl_bump terminate !activated

shutdown_lifetime 1 seconds
negative_dns_ttl 5 minutes


Does the MAC address and bump have anything to do with it? This worked in the 
older versions without having to input a MAC for the loopback

> On Jul 11, 2024, at 11:08, Jonathan Lee  wrote:
> 
> I use http access acl set as followed 
> 
> acl getmethod method GET
> acl to_ipv6 dst ipv6
> acl from_ipv6 src ipv6
> acl HttpAccess dstdomain "/usr/local/pkg/http.access”
> 
> 
> /usr/local/pkg/http.access
> contains:
> office.com
> data.microsoft.com
> windowsupdate.com
> dc1-st.ksn.kaspersky-labs.com
> dc1-file.ksn.kaspersky-labs.com
> dc1.ksn.kaspersky-labs.com
> gsa.apple.com
> apps.apple.com
> certs.apple.com
> crl.apple.com
> entrust.net
> digicert.com
> ocsp.apple.com
> ocsp2.apple.com
> valid.apple.com
> push.apple.com
> itunes.apple.com
> appldnld.apple.com
> gg.apple.com
> gs.apple.com
> mesu.apple.com
> oscdn.apple.com
> osrecovery.apple.com
> swcdn.apple.com
> swdownload.apple.com
> updates-http.cdn-apple.com
> appldnld.apple.com.edgesuite.net
> suconfig.apple.com
> audiocontentdownload.apple.com
> devimages-cdn.apple.com
> download.developer.apple.com
> sylvan.apple.com
> static.ips.apple.com
> 
> 
> http_access allow CONNECT wuCONNECT localnet
> http_access allow CONNECT wuCONNECT localhost
> http_access allow windowsupdate localnet
> http_access allow windowsupdate localhost
> http_access allow HttpAccess localnet
> http_access allow HttpAccess localhost
> http_access deny manager
> http_access deny to_ipv6
> http_access deny from_ipv6 
> 
>> On Jul 11, 2024, at 11:02, Jonathan Lee  wrote:
>> 
>> also 
>> 
>> Shell Output - squidclient -h 127.0.0.1 -v -U admin -W redacted mgr:info
>> Request:
>> GET http://127.0.0.1:3128/squid-internal-mgr/info HTTP/1.0
>> Host: 127.0.0.1:3128
>> User-Agent: squidclient/6.6
>> Accept: */*
>> Authorization: Basic YWRtaW46R09Qc3lzdGVtYWRtaW4xIQ==
>> Connection: close
>> 
>> 
>> .
>> HTTP/1.1 403 Forbidden
>> Server: squid
>> Mime-Version: 1.0
>> Date: Thu, 11 Jul 2024 18:01:46 GMT
>> Content-Type: text/html;charset=utf-8
>> Content-Length: 3788
>> X-Squid-Error: ERR_ACCESS_DENIED 0
>> Vary: Accept-Language
>> Content-Language: en
>> Cache-Status: Lee_Family.home.arpa
>> Cache-Status: Lee_Family.home.arpa;detail=no-cache
>> Con

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-11 Thread Jonathan Lee
I use http access acl set as followed 

acl getmethod method GET
acl to_ipv6 dst ipv6
acl from_ipv6 src ipv6
acl HttpAccess dstdomain "/usr/local/pkg/http.access”


/usr/local/pkg/http.access
contains:
office.com
data.microsoft.com
windowsupdate.com
dc1-st.ksn.kaspersky-labs.com
dc1-file.ksn.kaspersky-labs.com
dc1.ksn.kaspersky-labs.com
gsa.apple.com
apps.apple.com
certs.apple.com
crl.apple.com
entrust.net
digicert.com
ocsp.apple.com
ocsp2.apple.com
valid.apple.com
push.apple.com
itunes.apple.com
appldnld.apple.com
gg.apple.com
gs.apple.com
mesu.apple.com
oscdn.apple.com
osrecovery.apple.com
swcdn.apple.com
swdownload.apple.com
updates-http.cdn-apple.com
appldnld.apple.com.edgesuite.net
suconfig.apple.com
audiocontentdownload.apple.com
devimages-cdn.apple.com
download.developer.apple.com
sylvan.apple.com
static.ips.apple.com


http_access allow CONNECT wuCONNECT localnet
http_access allow CONNECT wuCONNECT localhost
http_access allow windowsupdate localnet
http_access allow windowsupdate localhost
http_access allow HttpAccess localnet
http_access allow HttpAccess localhost
http_access deny manager
http_access deny to_ipv6
http_access deny from_ipv6 

> On Jul 11, 2024, at 11:02, Jonathan Lee  wrote:
> 
> also 
> 
> Shell Output - squidclient -h 127.0.0.1 -v -U admin -W redacted mgr:info
> Request:
> GET http://127.0.0.1:3128/squid-internal-mgr/info HTTP/1.0
> Host: 127.0.0.1:3128
> User-Agent: squidclient/6.6
> Accept: */*
> Authorization: Basic YWRtaW46R09Qc3lzdGVtYWRtaW4xIQ==
> Connection: close
> 
> 
> .
> HTTP/1.1 403 Forbidden
> Server: squid
> Mime-Version: 1.0
> Date: Thu, 11 Jul 2024 18:01:46 GMT
> Content-Type: text/html;charset=utf-8
> Content-Length: 3788
> X-Squid-Error: ERR_ACCESS_DENIED 0
> Vary: Accept-Language
> Content-Language: en
> Cache-Status: Lee_Family.home.arpa
> Cache-Status: Lee_Family.home.arpa;detail=no-cache
> Connection: close
> 
>> On Jul 11, 2024, at 10:57, Jonathan Lee  wrote:
>> 
>> Shell Output - squidclient -v -U admin -W REDACTED mgr:info
>> Request:
>> GET http://localhost:3128/squid-internal-mgr/info HTTP/1.0
>> Host: localhost:3128
>> User-Agent: squidclient/6.6
>> Accept: */*
>> Authorization: Basic YWRtaW46R09Qc3lzdGVtYWRtaW4xIQ==
>> Connection: close
>> 
>> 
>> .
>> HTTP/1.1 403 Forbidden
>> Server: squid
>> Mime-Version: 1.0
>> Date: Thu, 11 Jul 2024 17:55:05 GMT
>> Content-Type: text/html;charset=utf-8
>> Content-Length: 3788
>> X-Squid-Error: ERR_ACCESS_DENIED 0
>> Vary: Accept-Language
>> Content-Language: en
>> Cache-Status: Lee_Family.home.arpa
>> Cache-Status: Lee_Family.home.arpa;detail=no-cache
>> Connection: close
>> 
>> > "http://www.w3.org/TR/html4/strict.dtd";>
>> 
>> 
>> 
>> ERROR: The requested URL could not be retrieved
>> 

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-11 Thread Jonathan Lee
also 

Shell Output - squidclient -h 127.0.0.1 -v -U admin -W redacted mgr:info
Request:
GET http://127.0.0.1:3128/squid-internal-mgr/info HTTP/1.0
Host: 127.0.0.1:3128
User-Agent: squidclient/6.6
Accept: */*
Authorization: Basic YWRtaW46R09Qc3lzdGVtYWRtaW4xIQ==
Connection: close


.
HTTP/1.1 403 Forbidden
Server: squid
Mime-Version: 1.0
Date: Thu, 11 Jul 2024 18:01:46 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 3788
X-Squid-Error: ERR_ACCESS_DENIED 0
Vary: Accept-Language
Content-Language: en
Cache-Status: Lee_Family.home.arpa
Cache-Status: Lee_Family.home.arpa;detail=no-cache
Connection: close

> On Jul 11, 2024, at 10:57, Jonathan Lee  wrote:
> 
> Shell Output - squidclient -v -U admin -W REDACTED mgr:info
> Request:
> GET http://localhost:3128/squid-internal-mgr/info HTTP/1.0
> Host: localhost:3128
> User-Agent: squidclient/6.6
> Accept: */*
> Authorization: Basic YWRtaW46R09Qc3lzdGVtYWRtaW4xIQ==
> Connection: close
> 
> 
> .
> HTTP/1.1 403 Forbidden
> Server: squid
> Mime-Version: 1.0
> Date: Thu, 11 Jul 2024 17:55:05 GMT
> Content-Type: text/html;charset=utf-8
> Content-Length: 3788
> X-Squid-Error: ERR_ACCESS_DENIED 0
> Vary: Accept-Language
> Content-Language: en
> Cache-Status: Lee_Family.home.arpa
> Cache-Status: Lee_Family.home.arpa;detail=no-cache
> Connection: close
> 
>  "http://www.w3.org/TR/html4/strict.dtd";>
> 
> 
> 
> ERROR: The requested URL could not be retrieved
> 

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-11 Thread Jonathan Lee
Shell Output - squidclient -v -U admin -W REDACTED mgr:info
Request:
GET http://localhost:3128/squid-internal-mgr/info HTTP/1.0
Host: localhost:3128
User-Agent: squidclient/6.6
Accept: */*
Authorization: Basic YWRtaW46R09Qc3lzdGVtYWRtaW4xIQ==
Connection: close


.
HTTP/1.1 403 Forbidden
Server: squid
Mime-Version: 1.0
Date: Thu, 11 Jul 2024 17:55:05 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 3788
X-Squid-Error: ERR_ACCESS_DENIED 0
Vary: Accept-Language
Content-Language: en
Cache-Status: Lee_Family.home.arpa
Cache-Status: Lee_Family.home.arpa;detail=no-cache
Connection: close

http://www.w3.org/TR/html4/strict.dtd";>



ERROR: The requested URL could not be retrieved

Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-11 Thread Jonathan Lee
Thanks what about the password is it set with@ or -p where would I place that?
Sent from my iPhone

> On Jul 11, 2024, at 10:17, Amos Jeffries  wrote:
> 
> 
>> On 11/07/24 06:08, Alex Rousskov wrote:
>> On 2024-07-10 12:55, Jonathan Lee wrote:
>>>> Embedding a password in a cache manager command requires providing a
>>>> username with -U
>>> squidclient -w /squid-internal-mgr/info -u admin
>>> squidclient -w /squid-internal-mgr/info@redacted -u admin
>>> squidclient -w http://192.168.1.1:3128/squid-internal-mgr/info@redacted -u 
>>> admin
>>> squidclient -w http://127.0.0.1:3128/squid-internal-mgr/info@redacted -u 
>>> admin
>>> squidclient -w http://127.0.0.1:3128/squid-internal-mgr/info
>>> squidclient http://127.0.0.1:3128/squid-internal-mgr/info
>>> squidclient -h 127.0.0.1:3128/squid-internal-mgr/info
>>> squidclient -h 127.0.0.1 /squid-internal-mgr/info
>>> squidclient -h 127.0.0.1 /squid-internal-mgr/info@redcated
>>> squidclient -w 127.0.0.1 /squid-internal-mgr/info@redacted
>>> squidclient -w 127.0.0.1 /squid-internal-mgr/info@redcated -u admin
>>> squidclient -h 192.168.1.1:3128  /squid-internal-mgr/info@redacted
>>> squidclient -h 192.168.1.1  /squid-internal-mgr/info@redacted
>>> squidclient -h 192.168.1.1  /squid-internal-mgr/info
>>> 
>>> with -w -u -h http spaces I can’t get it to show me stats
>>> 
>>> Squid 6.6
>> I do not know whether this mistake is relevant, but squidclient 
>> documentation and error message imply that you should be using "-U" (capital 
>> letter U) while you are using "-u" (small letter u).
> 
> 
> It is very relevant. As Matus already mentioned, both -U and -W.
> 
> 
> squidclient -v -U admin -W cachemgr_password mgr:info
> Request:
> GET http://localhost:3128/squid-internal-mgr/info HTTP/1.0
> Host: localhost:3128
> User-Agent: squidclient/6.10
> Accept: */*
> Authorization: Basic YWRtaW46Y2FjaGVtZ3JfcGFzc3dvcmQ=
> Connection: close
> 
> 
> squidclient -v -U admin -W cachemgr_password /squid-internal-mgr/info
> Request:
> GET /squid-internal-mgr/info HTTP/1.0
> Host: localhost:3128
> User-Agent: squidclient/6.10
> Accept: */*
> Authorization: Basic YWRtaW46Y2FjaGVtZ3JfcGFzc3dvcmQ=
> Connection: close
> 
> 
> Cheers
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-10 Thread Jonathan Lee
Thanks
Sent from my iPhone

> On Jul 10, 2024, at 11:08, Alex Rousskov  
> wrote:
> 
> On 2024-07-10 12:55, Jonathan Lee wrote:
> 
>>> Embedding a password in a cache manager command requires providing a
>>> username with -U
> 
>> squidclient -w /squid-internal-mgr/info -u admin
>> squidclient -w /squid-internal-mgr/info@redacted -u admin
>> squidclient -w http://192.168.1.1:3128/squid-internal-mgr/info@redacted -u 
>> admin
>> squidclient -w http://127.0.0.1:3128/squid-internal-mgr/info@redacted -u 
>> admin
>> squidclient -w http://127.0.0.1:3128/squid-internal-mgr/info
>> squidclient http://127.0.0.1:3128/squid-internal-mgr/info
>> squidclient -h 127.0.0.1:3128/squid-internal-mgr/info
>> squidclient -h 127.0.0.1 /squid-internal-mgr/info
>> squidclient -h 127.0.0.1 /squid-internal-mgr/info@redcated
>> squidclient -w 127.0.0.1 /squid-internal-mgr/info@redacted
>> squidclient -w 127.0.0.1 /squid-internal-mgr/info@redcated -u admin
>> squidclient -h 192.168.1.1:3128  /squid-internal-mgr/info@redacted
>> squidclient -h 192.168.1.1  /squid-internal-mgr/info@redacted
>> squidclient -h 192.168.1.1  /squid-internal-mgr/info
>> with -w -u -h http spaces I can’t get it to show me stats
>> Squid 6.6
> 
> I do not know whether this mistake is relevant, but squidclient documentation 
> and error message imply that you should be using "-U" (capital letter U) 
> while you are using "-u" (small letter u).
> 
> FWIW, I recommend using curl instead of deprecated squidclient. If nothing 
> else, you would be dealing with a well-known tool with extensive 
> documentation and wide-spread knowledge that will continue to work when you 
> upgrade to Squid v7. Using curl is not going to solve Squid Bug 5283 and 
> similar Squid-specific problems[1], but it may reduce the number of 
> "external" problems you have to deal with (e.g., guessing what squidclient 
> command line options actually do).
> 
> [1]: https://bugs.squid-cache.org/show_bug.cgi?id=5283
> 
> 
> HTH,
> 
> Alex.
> 
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


[squid-users] Squid 6.6 error clientProcessHit: Vary object loop!

2024-07-10 Thread Jonathan Lee
Has anyone seen this before? on hits?


10.07.2024 09:56:30 clientProcessHit: Vary object loop!
10.07.2024 09:56:30 varyEvaluateMatch: Oops. Not a Vary match on second 
attempt, 
'https://zagent20.h-cdn.com/cmd/get_thumb_info?customer=foxnews&ver=1.165.67&url=https%3A%2F%2F247preview.foxnews.com%2Fhls%2Flive%2F2020027%2Ffncv3preview%2Findex.m3u8'
 'origin="https%3A%2F%2Fstatic.foxnews.com", 
accept-encoding="gzip,%20deflate,%20br,%20zstd"'
31.12.1969 16:00:00 
31.12.1969 16:00:00 
31.12.1969 16:00:00 
31.12.1969 16:00:00 
31.12.1969 16:00:00 
31.12.1969 16:00:00 
31.12.1969 16:00:00___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-10 Thread Jonathan Lee
squidclient -w /squid-internal-mgr/info -u admin
squidclient -w /squid-internal-mgr/info@redacted -u admin
squidclient -w http://192.168.1.1:3128/squid-internal-mgr/info@redacted -u admin
squidclient -w http://127.0.0.1:3128/squid-internal-mgr/info@redacted -u admin
squidclient -w http://127.0.0.1:3128/squid-internal-mgr/info
squidclient http://127.0.0.1:3128/squid-internal-mgr/info
squidclient -h 127.0.0.1:3128/squid-internal-mgr/info
squidclient -h 127.0.0.1 /squid-internal-mgr/info
squidclient -h 127.0.0.1 /squid-internal-mgr/info@redcated
squidclient -w 127.0.0.1 /squid-internal-mgr/info@redacted
squidclient -w 127.0.0.1 /squid-internal-mgr/info@redcated -u admin
squidclient -h 192.168.1.1:3128  /squid-internal-mgr/info@redacted
squidclient -h 192.168.1.1  /squid-internal-mgr/info@redacted
squidclient -h 192.168.1.1  /squid-internal-mgr/info

with -w -u -h http spaces I can’t get it to show me stats 

Squid 6.6


> On Jul 10, 2024, at 09:35, Matus UHLAR - fantomas  wrote:
> 
>> "/squid-internal-mgr/info"

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-10 Thread Jonathan Lee
I have it says denied as if it requires an entry for one to use password, again 
if I remove the password the same thing happens. Weird right? Could WPAD cause 
this? 
Sent from my iPhone

> On Jul 10, 2024, at 09:21, Matus UHLAR - fantomas  wrote:
> 
> On 10.07.24 08:52, Jonathan Lee wrote:
>> That makes sense, I only had a password in the previous version, how do I 
>> add username admin for cachemgr?  
> 
> you don't, that's why I said "username was not important"
> simply try random username
> 
>>>> On Jul 10, 2024, at 04:29, Matus UHLAR - fantomas  
>>>> wrote:
>>> 
>>>>> On 2024-07-08, Jonathan Lee  wrote:
>>>>> squidclient -h 192.168.1.1:3128 mgr:info@PASSWORD squidclient -h
>>>>> 1287.0.0.1 mgr:info@PASSWORD
>>>>> 
>>>>> Gives the following error
>>>>> 
>>>>> Embedding a password in a cache manager command requires providing a =
>>>>> username with -U: mgr:info@PASSWORDHERE
>>> 
>>>> Try "/squid-internal-mgr/info" where you have "mgr:info".
>>> 
>>>> On 09.07.24 16:30, jonathanlee...@gmail.com wrote:
>>>> Thanks that also gave the error access denied
>>> 
>>> have you tried providing -U (and maybe -W) options to squidclient?
>>> Because that one looks like squidclient error to me.
>>> 
>>> in previous versions username was not important for manager queries, just 
>>> the password, which should be either part of user or provided by -W option
> 
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Boost your system's speed by 500% - DEL C:\WINDOWS$\*.*
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-10 Thread Jonathan Lee
That makes sense, I only had a password in the previous version, how do I add 
username admin for cachemgr? I don’t have a username configured yet, I can’t 
find the directive for cachemgr username
Sent from my iPhone

> On Jul 10, 2024, at 04:29, Matus UHLAR - fantomas  wrote:
> 
> 
>> 
>>> On 2024-07-08, Jonathan Lee  wrote:
>>> squidclient -h 192.168.1.1:3128 mgr:info@PASSWORD squidclient -h
>>> 1287.0.0.1 mgr:info@PASSWORD
>>> 
>>> Gives the following error
>>> 
>>> Embedding a password in a cache manager command requires providing a =
>>> username with -U: mgr:info@PASSWORDHERE
> 
>> Try "/squid-internal-mgr/info" where you have "mgr:info".
> 
>> On 09.07.24 16:30, jonathanlee...@gmail.com wrote:
>> Thanks that also gave the error access denied
> 
> have you tried providing -U (and maybe -W) options to squidclient?
> Because that one looks like squidclient error to me.
> 
> in previous versions username was not important for manager queries, just the 
> password, which should be either part of user or provided by -W option
> 
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Christian Science Programming: "Let God Debug It!".
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-09 Thread Jonathan Lee
Thanks do I still append the cache manager password ?
Sent from my iPhone

> On Jul 9, 2024, at 05:47, Stuart Henderson  wrote:
> 
> On 2024-07-08, Jonathan Lee  wrote:
>> 
>> Also=20
>> squidclient -h 192.168.1.1:3128 mgr:info@PASSWORD
>> squidclient -h 1287.0.0.1 mgr:info@PASSWORD
>> 
>> Gives the following error
>> 
>> Embedding a password in a cache manager command requires providing a =
>> username with -U: mgr:info@PASSWORDHERE
> 
> Try "/squid-internal-mgr/info" where you have "mgr:info".
> 
> 
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-08 Thread Jonathan Lee
Also 
squidclient -h 192.168.1.1:3128 mgr:info@PASSWORD
squidclient -h 1287.0.0.1 mgr:info@PASSWORD

Gives the following error

Embedding a password in a cache manager command requires providing a username 
with -U: mgr:info@PASSWORDHERE


> On Jul 8, 2024, at 15:13, Jonathan Lee  wrote:
> 
> cachemgr_passwd disable offline_toggle reconfigure shutdown
> cachemgr_passwd REDACTED all
> 
> http_access allow CONNECT wuCONNECT localnet
> http_access allow CONNECT wuCONNECT localhost
> http_access allow windowsupdate localnet
> http_access allow windowsupdate localhost
> 
> http_access allow localhost manager with or without
> http_access allow 192.168.1.1:3128 manager  with or without
> http_access allow lee.family.home.arpa:3128 manager with or without
> http_access deny manager
> 
> I have tried all of this also
> 
> is cache_manager.cc <http://cache_manager.cc/> missing? does anyone know the 
> filesystem path for this squid-internals-mgr?
> 
> 
> 
> Miss 403 shows for them I have http_access localhost
> 
>> On Jul 8, 2024, at 14:34, Jonathan Lee  wrote:
>> 
>> This shows access denied in 6.6 I have a password for cache_manager does 
>> that cause any issues with accessing this new mgr directive ?
>> 
>>> On Apr 6, 2024, at 20:18, Amos Jeffries  wrote:
>>> 
>>> On 6/04/24 18:48, Jonathan Lee wrote:
>>>> Correction I can’t access it from the loop back
>>> 
>>> From the config in the other "Squid cache questions" thread you are only 
>>> intercepting traffic on the loopback 127.0.0.1:3128 port. You cannot access 
>>> it directly on "localhost".
>>> 
>>> You do have direct proxy (and thus manager) access via the 192.168.1.1:3128 
>>> so this URL should work:
>>> http://192.168.1.1:3128/squid-internal-mgr/menu
>>> 
>>> 
>>> .. or substitute the raw-IP for the visible_hostname setting **if** that 
>>> hostname actually resolves to that IP.
>>> 
>>> 
>>> HTH
>>> Amos
>>> ___
>>> squid-users mailing list
>>> squid-users@lists.squid-cache.org
>>> https://lists.squid-cache.org/listinfo/squid-users
>> 
> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

2024-07-08 Thread Jonathan Lee
This shows access denied in 6.6 I have a password for cache_manager does that 
cause any issues with accessing this new mgr directive ?

> On Apr 6, 2024, at 20:18, Amos Jeffries  wrote:
> 
> On 6/04/24 18:48, Jonathan Lee wrote:
>> Correction I can’t access it from the loop back
> 
> From the config in the other "Squid cache questions" thread you are only 
> intercepting traffic on the loopback 127.0.0.1:3128 port. You cannot access 
> it directly on "localhost".
> 
> You do have direct proxy (and thus manager) access via the 192.168.1.1:3128 
> so this URL should work:
>  http://192.168.1.1:3128/squid-internal-mgr/menu
> 
> 
> .. or substitute the raw-IP for the visible_hostname setting **if** that 
> hostname actually resolves to that IP.
> 
> 
> HTH
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid 6.6 kick abandoning connections

2024-07-08 Thread Jonathan Lee
I can confirm I have no ipv6 our isp is ipv4 only and I have IPv6 disabled on 
the firewall and with layer 2 and 3 traffic 
Sent from my iPhone

> On Jul 8, 2024, at 09:15, Alex Rousskov  
> wrote:
> 
> On 2024-07-05 21:07, Jonathan Lee wrote:
> 
>> I am using Bump with certificates installed on devices does anyone know what 
>> this error is...
>> kick abandoning conn43723 local=192.168.1.1:3128 remote=192.168.1.5:52129 FD 
>> 178 flags=1
> 
> 
> This "kick abandoning" message marks a Squid problem or bug: Squid enters a 
> seemingly impossible state. In some (but probably not all) cases, the client 
> connection might become stuck (hopefully until some timeout closes it). In 
> some (and possibly all) cases, Squid might immediately close the connection 
> and nobody gets hurt. Code reporting this problem does not know how we got 
> here and what will happen next.
> 
> There were several incomplete/unfinished attempts to fix this problem, 
> including two different patches posted at Bug 3715. I do not know whether 
> either of them is safe and applies to Squid v6. Neither is a comprehensive 
> solution.
> https://bugs.squid-cache.org/show_bug.cgi?id=3715
> 
> 
>> Does anyone know how to fix my last weird error I have with Squid 6.6
> 
> I do not know of a good configuration-based workaround. Squid code 
> modifications are required to properly address this problem. Other errors may 
> trigger this bug, so addressing those other errors may hide (and reduce the 
> pressure to fix) this bug. Besides fixing those other errors (if any -- I am 
> aware that you have said that there are no other errors left, but perhaps you 
> found other problems since then), these basic options apply:
> 
> https://wiki.squid-cache.org/SquidFaq/AboutSquid#how-to-add-a-new-squid-feature-enhance-of-fix-something
> 
> Alex.
> 
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] ICMP and QUIC

2024-07-07 Thread Jonathan Lee
Does anyone use this directive for QUIC in the mean time… what’s weird is that 
IP address is Apple when Facebook is running

on_unsupported_protocol <>


> On Jul 7, 2024, at 21:24, Jonathan Lee  wrote:
> 
> I have just found... YEAH!!! has anyone tested this? Does Squid 6.6 have it? 
> https://github.com/squid-cache/squid/pull/919
>> On Jul 7, 2024, at 21:10, Jonathan Lee  wrote:
>> 
>> Hello fellow Squid Users,
>> 
>> When watching facebook reels everything works as expected after about 15 
>> minutes the system starts to attempt to use QUIC and after my iMac fan goes 
>> crazy and the website locks up..
>> 
>> HTTPS was reserved for 443. QUIC is also using UDP 443 and not following 
>> proper protocol rules. 
>> 
>> I do understand that QUIC is HTTP3 and uses UDP over 443 only. Again from a 
>> cybersecurity perspective how do you set up this protocol in the proxy ?
>> 
>> Here is the photo of the pcap showing the issue..
>> 
>> Does anyone know what to do to fix this?
>> 
>> 
>> 
> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


[squid-users] ICMP and QUIC

2024-07-07 Thread Jonathan Lee
Hello fellow Squid Users,

When watching facebook reels everything works as expected after about 15 
minutes the system starts to attempt to use QUIC and after my iMac fan goes 
crazy and the website locks up..

HTTPS was reserved for 443. QUIC is also using UDP 443 and not following proper 
protocol rules. 

I do understand that QUIC is HTTP3 and uses UDP over 443 only. Again from a 
cybersecurity perspective how do you set up this protocol in the proxy ?

Here is the photo of the pcap showing the issue..

Does anyone know what to do to fix this?


___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


[squid-users] ICMP and QUIC

2024-07-07 Thread Jonathan Lee
Hello fellow Squid Users,

When watching facebook reels everything works as expected after about 15 
minutes the system starts to attempt to use QUIC and after my iMac fan goes 
crazy and the website locks up..

HTTPS was reserved for 443. QUIC is also using UDP 443 and not following proper 
protocol rules. 

I do understand that QUIC is HTTP3 and uses UDP over 443 only. Again from a 
cybersecurity perspective how do you set up this protocol in the proxy ?

Here is the photo of the pcap showing the issue..

Does anyone know what to do to fix this?


___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Speed issues

2024-07-07 Thread Jonathan Lee
This change seems to help

http_upgrade_request_protocols websocket allow all 
accept_filter httpready
accept_filter dataready
collapsed_forwarding on
half_closed_clients off
pipeline_prefetch 6

also enabling UDP on port 3128 

and disabling pinger now that the system is set up and running…



> On Jul 3, 2024, at 08:28, Jonathan Lee  wrote:
> 
> Does anyone have tips for getting the proxy to run faster when SSL intercept 
> is enabled along side splice lists with dynamic cache and ClamAV running?
> 
> 
> I just seems to have slow traffic on the interception side. 
> Sent from my iPhone

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


[squid-users] Squid 6.6 kick abandoning connections

2024-07-05 Thread Jonathan Lee
Hello fellow Squid Users 

I am using Bump with certificates installed on devices does anyone know what 
this error is...

kick abandoning conn43723 local=192.168.1.1:3128 remote=192.168.1.5:52129 FD 
178 flags=1

Does anyone know how to fix my last weird error I have with Squid 6.6 

This is my last weird error I am trying to pinpoint…

I really appreciate the new error codes that I can see the older versions did 
not have any information it was blank for 
issues like this…

thanks 




___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-05 Thread Jonathan Lee
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 
> 
> 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 know how to resolve this or wants 
> me to try something else let me know. I was originally looking for the 
> certificate when this error occurs however the error comes from the TLS_v1.3 
> as seen in the pcap files below. 
> 
> 
> Thanks again everyone  
> 
>> On Jul 4, 2024, at 16: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 packets and matching them with 
>>>>> connection information from A000417 error messages in cache.log or 
>>>>> %err_detail in access.log)."
>> 
>> 
>> Ok I went back to 5.8 and ran the following command after I removed the 
>> changes I used does this help this is ran on the firewall side itself. 
>> 
>>  openssl s_client -connect foxnews.com:443 <http://foxnews.com:443/>
>> 
>> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert 
>> Global Root CA
>> verify return:1
>> depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>> verify return:1
>> depth=0 C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN 
>> = wildcard.foxnews.com
>> verify return:1
>> CONNECTED(0004)
>> ---
>> Certificate chain
>>  0 s:C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN = 
>> wildcard.foxnews.com
>>i:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>>  1 s:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>>i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
>> Root CA
>> 
>> -END CERTIFICATE-
>> subject=C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN 
>> = wildcard.foxnews.com
>> 
>> issuer=C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>> 
>> ---
>> No client certificate CA names sent
>> Peer signing digest: SHA256
>> Peer signature type: ECDSA
>> Server Temp Key: X25519, 253 bits
>> ---
>> SSL handshake has read 4198 bytes and written 393 bytes
>> Verification: OK
>> ---
>> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
>> Server public key is 256 bit
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> No ALPN negotiated
>> Early data was not sent
>> Verify return code: 0 (ok)
>> ---
>> DONE
>> 
>> Does that help I am not going to pretend I understand TLS options I do 
>> understand how the SSL ciphers work and certificates but all the different 
>> options and kinds are what is confusing me. I did not seem to have this 
>> error before.
>> 
>> 
>> Should I regenerate a new certificate for the new version of Squid and 
>> redeploy them all to hosts again? I used this method in the past and it 
>> worked for a long time after I imported it. I am wondering if this is 
>> outdated now
>> 
>> openssl req -x509 -new -nodes -key myProxykey.key -sha256 -days 365 -out 
>> myProxyca.pem
>> 
>> 
>>> On Jul 4, 2024, at 15:13, Jonathan Lee  wrote:
>>> 
>>> 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_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
>&

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-05 Thread Jonathan Lee
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 know how to resolve this or wants 
me to try something else let me know. I was originally looking for the 
certificate when this error occurs however the error comes from the TLS_v1.3 as 
seen in the pcap files below. 


Thanks again everyone  

> On Jul 4, 2024, at 16: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 packets and matching them with 
>>>> connection information from A000417 error messages in cache.log or 
>>>> %err_detail in access.log)."
> 
> 
> Ok I went back to 5.8 and ran the following command after I removed the 
> changes I used does this help this is ran on the firewall side itself. 
> 
>  openssl s_client -connect foxnews.com:443 <http://foxnews.com:443/>
> 
> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
> Root CA
> verify return:1
> depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
> verify return:1
> depth=0 C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN 
> = wildcard.foxnews.com
> verify return:1
> CONNECTED(0004)
> ---
> Certificate chain
>  0 s:C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN = 
> wildcard.foxnews.com
>i:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>  1 s:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
> Root CA
> 
> -END CERTIFICATE-
> subject=C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN 
> = wildcard.foxnews.com
> 
> issuer=C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
> 
> ---
> No client certificate CA names sent
> Peer signing digest: SHA256
> Peer signature type: ECDSA
> Server Temp Key: X25519, 253 bits
> ---
> SSL handshake has read 4198 bytes and written 393 bytes
> Verification: OK
> ---
> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
> Server public key is 256 bit
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> Verify return code: 0 (ok)
> ---
> DONE
> 
> Does that help I am not going to pretend I understand TLS options I do 
> understand how the SSL ciphers work and certificates but all the different 
> options and kinds are what is confusing me. I did not seem to have this error 
> before.
> 
> 
> Should I regenerate a new certificate for the new version of Squid and 
> redeploy them all to hosts again? I used this method in the past and it 
> worked for a long time after I imported it. I am wondering if this is 
> outdated now
> 
> openssl req -x509 -new -nodes -key myProxykey.key -sha256 -days 365 -out 
> myProxyca.pem
> 
> 
>> On Jul 4, 2024, at 15:13, Jonathan Lee  wrote:
>> 
>> 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_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 
>>> 
>>> ERROR: Unsupported TLS option SINGLE_ECDH_USE
>>> 
>>> I found researching in lists-squid-cache.org 
>>> <http://lists-squid-cache.org/> that someone solved this with appending 
>>> TLS13-AES-256-CGM-SHA384 to the ciphers. 
>>> 
>>> I am thinking this is my issue also.
>>> 
>>> I see that error over and over when I run "squid -k parse”
>>> 
>>> Do I append this to the options cipher list?
>>> 
>>> Jonathan Lee
>>> 
>>>> On Jul 4, 2024, at 14:45, Alex Rousskov  
>>>> wrote:
>&

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-05 Thread Jonathan Lee
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  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-SHA384TLSv1.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-POLY1305TLSv1.2 Kx=ECDH Au=RSA   
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> ECDHE-ECDSA-AES256-CCM8TLSv1.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-SHA256TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(128)   
>  Mac=AEAD
> ECDHE-ECDSA-AES128-CCM8TLSv1.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-SHA384TLSv1.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-SHA256TLSv1.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  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  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,  
>>>>  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 
>>>> 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, J

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-05 Thread Jonathan Lee
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-SHA384TLSv1.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-POLY1305TLSv1.2 Kx=ECDH Au=RSA   
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM8TLSv1.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-SHA256TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(128) 
   Mac=AEAD
ECDHE-ECDSA-AES128-CCM8TLSv1.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-SHA384TLSv1.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-SHA256TLSv1.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  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  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,  
>>>  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 
>>> 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 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 th

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-05 Thread Jonathan Lee
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  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,  
>>  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 
>> 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 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  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 
>>>>>  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.
>>>>>

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-05 Thread Jonathan Lee
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,  
>  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  
> 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 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  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  
>>>> 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 

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-05 Thread Jonathan Lee
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 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?
> 
> 
> 
>> On Jul 5, 2024, at 08:23, Jonathan Lee  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  
>>> 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.
>>> 
> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] ERROR: Unsupported TLS option SINGLE_ECDH_USE

2024-07-05 Thread Jonathan Lee
Does anyone know how to activate the TLS1.3 ciphers?

Per lists.squid-cache.org <http://lists.squid-cache.org/>

Ref:
https://lists.squid-cache.org/pipermail/squid-users/2018-February/017640.html
https://openssl.org/blog/blog/2017/05/04/tlsv1.3/

And CVE-2016-0701

"Yes. Due to CVE-2016-0701 the SSL_OP_SINGLE_DH_USE option was deprecated”

It is depreciated and the new pfSense package still shows it as a default 
option, however how does one append 

ppending
> "TLS13-AES-256-GCM-SHA384" to the ciphers.
> 
> But the log shows the use of "ECDHE-ECDSA-AES256-GCM-SHA384”


> On Jul 5, 2024, at 09:11, Jonathan Lee  wrote:
> 
> Wireshark shows Cipher Suite: TLS_AES_128_GCM_SHA256 is being used
> How would I append the TLS13-AES-256-CGM-SHA384 cipher suite for use with 
> TLSv1.3 as it states change cipher spec on wireshark
> 
>> On Jul 5, 2024, at 08:46, Jonathan Lee  wrote:
>> 
>> More details for Unsupported TLS option
>> 
>> When running squid -k parse
>> 
>> 2024/07/05 08:40:43| Processing: http_port 192.168.1.1:3128 ssl-bump 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
>> cert=/usr/local/etc/squid/serverkey.pem 
>> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
>> 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
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
>> 2024/07/05 08:40:43| UPGRADE WARNING: 
>> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
>> Use 'tls-cafile=' instead.
>> 2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_DH_USE
>> 2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_ECDH_USE
>> 2024/07/05 08:40:47| Processing: http_port 127.0.0.1:3128 intercept ssl-bump 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
>> cert=/usr/local/etc/squid/serverkey.pem 
>> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
>> 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
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
>> 2024/07/05 08:40:47| Starting Authentication on port 127.0.0.1:3128
>> 2024/07/05 08:40:47| Disabling Authentication on port 127.0.0.1:3128 
>> (interception enabled)
>> 2024/07/05 08:40:47| UPGRADE WARNING: 
>> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
>> Use 'tls-cafile=' instead.
>> 2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_DH_USE
>> 2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_ECDH_USE
>> 2024/07/05 08:40:51| Processing: https_port 127.0.0.1:3129 intercept 
>> ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
>> cert=/usr/local/etc/squid/serverkey.pem 
>> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
>> 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
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
>> 2024/07/05 08:40:51| Starting Authentication on port 127.0.0.1:3129
>> 2024/07/05 08:40:51| Disabling Authentication on port 127.0.0.1:3129 
>> (interception enabled)
>> 2024/07/05 08:40:51| UPGRADE WARNING: 
>> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in https_port. 
>> Use 'tls-cafile=' instead.
>> 2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_DH_USE
>> 2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_ECDH_USE
>> elliptic curve options are set below and I have inspected the file it is 
>> present. 
>> 
>>  tls-dh=prime256v1:/etc/dh-parameters.2048 
>> 
>>> On Jul 5, 2024, at 08:35, Jonathan Lee  wrote:
>>> 
>>> 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
>>> Different thread for ciphers issues
>>> 
>>> ERROR: Unsupported TLS option SINGLE_ECDH_USE
>>> 
>>> I found researching in lists-squid-cache.org 
>>> <http:

Re: [squid-users] ERROR: Unsupported TLS option SINGLE_ECDH_USE

2024-07-05 Thread Jonathan Lee
Wireshark shows Cipher Suite: TLS_AES_128_GCM_SHA256 is being used
How would I append the TLS13-AES-256-CGM-SHA384 cipher suite for use with 
TLSv1.3 as it states change cipher spec on wireshark

> On Jul 5, 2024, at 08:46, Jonathan Lee  wrote:
> 
> More details for Unsupported TLS option
> 
> When running squid -k parse
> 
> 2024/07/05 08:40:43| Processing: http_port 192.168.1.1:3128 ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/05 08:40:43| UPGRADE WARNING: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
> Use 'tls-cafile=' instead.
> 2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 2024/07/05 08:40:47| Processing: http_port 127.0.0.1:3128 intercept ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/05 08:40:47| Starting Authentication on port 127.0.0.1:3128
> 2024/07/05 08:40:47| Disabling Authentication on port 127.0.0.1:3128 
> (interception enabled)
> 2024/07/05 08:40:47| UPGRADE WARNING: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. 
> Use 'tls-cafile=' instead.
> 2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 2024/07/05 08:40:51| Processing: https_port 127.0.0.1:3129 intercept ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
> cert=/usr/local/etc/squid/serverkey.pem 
> cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
> 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
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
> 2024/07/05 08:40:51| Starting Authentication on port 127.0.0.1:3129
> 2024/07/05 08:40:51| Disabling Authentication on port 127.0.0.1:3129 
> (interception enabled)
> 2024/07/05 08:40:51| UPGRADE WARNING: 
> 'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in https_port. 
> Use 'tls-cafile=' instead.
> 2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_DH_USE
> 2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_ECDH_USE
> elliptic curve options are set below and I have inspected the file it is 
> present. 
> 
>  tls-dh=prime256v1:/etc/dh-parameters.2048 
> 
>> On Jul 5, 2024, at 08:35, Jonathan Lee  wrote:
>> 
>> 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
>> Different thread for ciphers issues
>> 
>> ERROR: Unsupported TLS option SINGLE_ECDH_USE
>> 
>> I found researching in lists-squid-cache.org <http://lists-squid-cache.org/> 
>> that someone solved this error with appending TLS13-AES-256-CGM-SHA384 to 
>> the ciphers. 
>> 
>> I am thinking this is my issue also.
>> 
>> I see that error over and over when I run "squid -k parse”
>> 
>> Do I append this to the options cipher list?
>> 
>> Does anyone know how to fix the 2 diffie-hellman key exchange algorithm 
>> errors?
>> 
>> 
>> 
>> Jonathan Lee
> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-05 Thread Jonathan Lee
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 information with ssl.handshake.type 
== 1

Or is there a wireshark particular filter you would like ran to help with 
isolation?



> On Jul 5, 2024, at 08:23, Jonathan Lee  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  
>> 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.
>> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] ERROR: Unsupported TLS option SINGLE_ECDH_USE

2024-07-05 Thread Jonathan Lee
More details for Unsupported TLS option

When running squid -k parse

2024/07/05 08:40:43| Processing: http_port 192.168.1.1:3128 ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/05 08:40:43| UPGRADE WARNING: 
'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. Use 
'tls-cafile=' instead.
2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_DH_USE
2024/07/05 08:40:47| ERROR: Unsupported TLS option SINGLE_ECDH_USE
2024/07/05 08:40:47| Processing: http_port 127.0.0.1:3128 intercept ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/05 08:40:47| Starting Authentication on port 127.0.0.1:3128
2024/07/05 08:40:47| Disabling Authentication on port 127.0.0.1:3128 
(interception enabled)
2024/07/05 08:40:47| UPGRADE WARNING: 
'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in http_port. Use 
'tls-cafile=' instead.
2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_DH_USE
2024/07/05 08:40:51| ERROR: Unsupported TLS option SINGLE_ECDH_USE
2024/07/05 08:40:51| Processing: https_port 127.0.0.1:3129 intercept ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=20MB 
cert=/usr/local/etc/squid/serverkey.pem 
cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ 
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
 tls-dh=prime256v1:/etc/dh-parameters.2048 
options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE
2024/07/05 08:40:51| Starting Authentication on port 127.0.0.1:3129
2024/07/05 08:40:51| Disabling Authentication on port 127.0.0.1:3129 
(interception enabled)
2024/07/05 08:40:51| UPGRADE WARNING: 
'cafile=/usr/local/share/certs/ca-root-nss.crt' is deprecated in https_port. 
Use 'tls-cafile=' instead.
2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_DH_USE
2024/07/05 08:40:55| ERROR: Unsupported TLS option SINGLE_ECDH_USE
elliptic curve options are set below and I have inspected the file it is 
present. 

 tls-dh=prime256v1:/etc/dh-parameters.2048 

> On Jul 5, 2024, at 08:35, Jonathan Lee  wrote:
> 
> 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
> Different thread for ciphers issues
> 
> ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 
> I found researching in lists-squid-cache.org <http://lists-squid-cache.org/> 
> that someone solved this error with appending TLS13-AES-256-CGM-SHA384 to the 
> ciphers. 
> 
> I am thinking this is my issue also.
> 
> I see that error over and over when I run "squid -k parse”
> 
> Do I append this to the options cipher list?
> 
> Does anyone know how to fix the 2 diffie-hellman key exchange algorithm 
> errors?
> 
> 
> 
> Jonathan Lee

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


[squid-users] ERROR: Unsupported TLS option SINGLE_ECDH_USE

2024-07-05 Thread Jonathan Lee
tls_outgoing_options cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSStls_outgoing_options options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USEDifferent thread for ciphers issuesERROR: Unsupported TLS option SINGLE_ECDH_USEI found researching in lists-squid-cache.org that someone solved this error with appending TLS13-AES-256-CGM-SHA384 to the ciphers. I am thinking this is my issue also.I see that error over and over when I run "squid -k parse”Do I append this to the options cipher list?Does anyone know how to fix the 2 diffie-hellman key exchange algorithm errors?Jonathan Lee___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-05 Thread Jonathan Lee
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  
> 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.
> 
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-04 Thread Jonathan Lee
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, 2024, at 16: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 ..
> 
> http://www.squid-cache.org/Versions/v5/cfgman/http_port.html
> 
> http://www.squid-cache.org/Versions/v6/cfgman/http_port.html
>   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. In theory if 
> default is auto off and it is attempting to use one it would be untrusted 
> automagically after migration
> 
>> On Jul 4, 2024, at 14:45, Alex Rousskov  
>> wrote:
>> 
>>  my current working theory suggests that we are looking at a (default) 
>> signUntrusted use case.
> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-04 Thread Jonathan Lee
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_port.html
  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. In theory if 
default is auto off and it is attempting to use one it would be untrusted 
automagically after migration

> On Jul 4, 2024, at 14:45, Alex Rousskov  
> wrote:
> 
>  my current working theory suggests that we are looking at a (default) 
> signUntrusted use case.

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-04 Thread Jonathan Lee
>>> 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 connection 
>>> information from A000417 error messages in cache.log or %err_detail in 
>>> access.log)."


Ok I went back to 5.8 and ran the following command after I removed the changes 
I used does this help this is ran on the firewall side itself. 

 openssl s_client -connect foxnews.com:443 <http://foxnews.com:443/>

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
verify return:1
depth=0 C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN = 
wildcard.foxnews.com
verify return:1
CONNECTED(0004)
---
Certificate chain
 0 s:C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN = 
wildcard.foxnews.com
   i:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
 1 s:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root 
CA

-END CERTIFICATE-
subject=C = US, ST = New York, L = New York, O = "Fox News Network, LLC", CN = 
wildcard.foxnews.com

issuer=C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4198 bytes and written 393 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE

Does that help I am not going to pretend I understand TLS options I do 
understand how the SSL ciphers work and certificates but all the different 
options and kinds are what is confusing me. I did not seem to have this error 
before.


Should I regenerate a new certificate for the new version of Squid and redeploy 
them all to hosts again? I used this method in the past and it worked for a 
long time after I imported it. I am wondering if this is outdated now

openssl req -x509 -new -nodes -key myProxykey.key -sha256 -days 365 -out 
myProxyca.pem


> On Jul 4, 2024, at 15:13, Jonathan Lee  wrote:
> 
> 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_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 
>> 
>> ERROR: Unsupported TLS option SINGLE_ECDH_USE
>> 
>> I found researching in lists-squid-cache.org <http://lists-squid-cache.org/> 
>> that someone solved this with appending TLS13-AES-256-CGM-SHA384 to the 
>> ciphers. 
>> 
>> I am thinking this is my issue also.
>> 
>> I see that error over and over when I run "squid -k parse”
>> 
>> Do I append this to the options cipher list?
>> 
>> Jonathan Lee
>> 
>>> On Jul 4, 2024, at 14:45, Alex Rousskov  
>>> wrote:
>>> 
>>> 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/certificate Squid 
>>> uses in which SslBump use case. Triage is often easier if folks share the 
>>> same working theory, and my current working theory suggests that we are 
>>> looking at a (default) signUntrusted use case.
>>> 
>>> The solution here probably does _not_ involve changing sslproxy_cert_sign 
>>> configuration, but, to make progress, I need more info to confirm this 
>>> working theory and describe next steps.
>>> 
>>> 
>>>> Yes I am using SSL bump with this configuration..
>>> 
>>> Noted, thank you.
>>> 
>>> 
>>>> So would I use this di

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-04 Thread Jonathan Lee
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_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 
> 
> ERROR: Unsupported TLS option SINGLE_ECDH_USE
> 
> I found researching in lists-squid-cache.org <http://lists-squid-cache.org/> 
> that someone solved this with appending TLS13-AES-256-CGM-SHA384 to the 
> ciphers. 
> 
> I am thinking this is my issue also.
> 
> I see that error over and over when I run "squid -k parse”
> 
> Do I append this to the options cipher list?
> 
> Jonathan Lee
> 
>> On Jul 4, 2024, at 14:45, Alex Rousskov  
>> wrote:
>> 
>> 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/certificate Squid 
>> uses in which SslBump use case. Triage is often easier if folks share the 
>> same working theory, and my current working theory suggests that we are 
>> looking at a (default) signUntrusted use case.
>> 
>> The solution here probably does _not_ involve changing sslproxy_cert_sign 
>> configuration, but, to make progress, I need more info to confirm this 
>> working theory and describe next steps.
>> 
>> 
>>> Yes I am using SSL bump with this configuration..
>> 
>> Noted, thank you.
>> 
>> 
>>> So would I use this directive
>> 
>> 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 connection 
>> information from A000417 error messages in cache.log or %err_detail in 
>> access.log)."
>> 
>> 
>> HTH,
>> 
>> Alex.
>> 
>> 
>>>> On Jul 4, 2024, at 09:56, Alex Rousskov wrote:
>>>> 
>>>> 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 client does 
>>>> not trust the Certificate Authority that signed the certificate that was 
>>>> used for that TLS connection.
>>>> 
>>>> 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).
>>>> 
>>>> If you use SslBump for port 3128 traffic, then one of the possibilities 
>>>> here is that Squid is using an unknown-to-client CA to report an origin 
>>>> server that Squid itself does not trust (see signUntrusted in 
>>>> squid.conf.documented). In those cases, logging a level-1 ERROR is a Squid 
>>>> bug because that expected/desirable outcome should be treated as success 
>>>> (and a successful TLS accept treated as an error!).
>>>> 
>>>> 
>>>> HTH,
>>>> 
>>>> Alex.
>> 
>> 
>>>>> Is my main concern however I use the squid guard URL blocker
>>>>> Sent from my iPhone
>>>>>> On Jul 4, 2024, at 07:41, Alex Rousskov 
>>>>>>  wrote:
>>>>>> 
>>>>>> 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

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-04 Thread Jonathan Lee
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 

ERROR: Unsupported TLS option SINGLE_ECDH_USE

I found researching in lists-squid-cache.org <http://lists-squid-cache.org/> 
that someone solved this with appending TLS13-AES-256-CGM-SHA384 to the 
ciphers. 

I am thinking this is my issue also.

I see that error over and over when I run "squid -k parse”

Do I append this to the options cipher list?

Jonathan Lee

> On Jul 4, 2024, at 14:45, Alex Rousskov  
> wrote:
> 
> 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/certificate Squid 
> uses in which SslBump use case. Triage is often easier if folks share the 
> same working theory, and my current working theory suggests that we are 
> looking at a (default) signUntrusted use case.
> 
> The solution here probably does _not_ involve changing sslproxy_cert_sign 
> configuration, but, to make progress, I need more info to confirm this 
> working theory and describe next steps.
> 
> 
>> Yes I am using SSL bump with this configuration..
> 
> Noted, thank you.
> 
> 
>> So would I use this directive
> 
> 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 connection information 
> from A000417 error messages in cache.log or %err_detail in access.log)."
> 
> 
> HTH,
> 
> Alex.
> 
> 
>>> On Jul 4, 2024, at 09:56, Alex Rousskov wrote:
>>> 
>>> 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 client does 
>>> not trust the Certificate Authority that signed the certificate that was 
>>> used for that TLS connection.
>>> 
>>> 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).
>>> 
>>> If you use SslBump for port 3128 traffic, then one of the possibilities 
>>> here is that Squid is using an unknown-to-client CA to report an origin 
>>> server that Squid itself does not trust (see signUntrusted in 
>>> squid.conf.documented). In those cases, logging a level-1 ERROR is a Squid 
>>> bug because that expected/desirable outcome should be treated as success 
>>> (and a successful TLS accept treated as an error!).
>>> 
>>> 
>>> HTH,
>>> 
>>> Alex.
> 
> 
>>>> Is my main concern however I use the squid guard URL blocker
>>>> Sent from my iPhone
>>>>> On Jul 4, 2024, at 07:41, Alex Rousskov 
>>>>>  wrote:
>>>>> 
>>>>> 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 previous discussions about it, 
>>>>> and then provide as many details about it as you can (e.g., what traffic 
>>>>> causes it and/or matching access.log records).
>>>>> 
>>>>> 
>>>>> HTH,
>>>>> 
>>>>> Alex.
>>>>> 
>>>>> 
>>>>>> Squid - Cache Logs
>>>>>> Date-TimeMessage
>>>>>> 31.12.1969 16:00:00
>>>>>> 03.07.2024 10:54:34kick abandoning conn7853 local=192.168.1.1:3128 
>>>>>> remote=192.168.1.5:49710 FD 89 flags=1
>>>>>> 31.12.1969 16:00

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-04 Thread Jonathan Lee
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 NoBumpDNS active_use
ssl_bump splice NoSSLIntercept active_use
ssl_bump bump bump_only_mac bump_only active_use
acl activated note active_use true
ssl_bump terminate !activated

acl markedBumped note bumped true
url_rewrite_access deny markedBumped


> On Jul 4, 2024, at 09:56, Alex Rousskov  
> wrote:
> 
> 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 client does not 
> trust the Certificate Authority that signed the certificate that was used for 
> that TLS connection.
> 
> 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).
> 
> If you use SslBump for port 3128 traffic, then one of the possibilities here 
> is that Squid is using an unknown-to-client CA to report an origin server 
> that Squid itself does not trust (see signUntrusted in 
> squid.conf.documented). In those cases, logging a level-1 ERROR is a Squid 
> bug because that expected/desirable outcome should be treated as success (and 
> a successful TLS accept treated as an error!).
> 
> 
> HTH,
> 
> Alex.
> P.S. For free Squid support, please keep the discussion on the mailing list.
> 
> 
>> Is my main concern however I use the squid guard URL blocker
>> Sent from my iPhone
>>> On Jul 4, 2024, at 07:41, Alex Rousskov  
>>> wrote:
>>> 
>>> 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 previous discussions about it, and then 
>>> provide as many details about it as you can (e.g., what traffic causes it 
>>> and/or matching access.log records).
>>> 
>>> 
>>> HTH,
>>> 
>>> Alex.
>>> 
>>> 
>>>> Squid - Cache Logs
>>>> Date-TimeMessage
>>>> 31.12.1969 16:00:00
>>>> 03.07.2024 10:54:34kick 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:29kick abandoning conn7844 local=192.168.1.1:3128 
>>>> remote=192.168.1.5:49702 FD 81 flags=1
>>>> 03.07.2024 10:54:09ERROR: failure while accepting a TLS connection on 
>>>> conn7648 local=192.168.1.1:3128 remote=192.168.1.5:49672 FD 44 flags=1: 
>>>> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
>>>> 03.07.2024 10:54:09ERROR: failure while accepting a TLS connection on 
>>>> conn7647 local=192.168.1.1:3128 remote=192.168.1.5:49670 FD 43 flags=1: 
>>>> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
>>>> 03.07.2024 10:54:09ERROR: failure while accepting a TLS connection on 
>>>> conn7646 local=192.168.1.1:3128 remote=192.168.1.5:49668 FD 34 flags=1: 
>>>> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
>>>> 03.07.2024 10:53:04ERROR: failure while accepting a TLS connection on 
>>>> conn7367 local=192.168.1.1:3128 remote=192.168.1.5:49627 FD 22 flags=1: 
>>>> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
>>>> 03.07.2024 10:52:47ERROR: failure while accepting a TLS connection on 
>>>> conn7345 local=192.168.1.1:3128 remote=192.168.1.5:49618 FD 31 flags=1: 
>>>> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
>>>> 03.07.2024 10:52:38ERROR: failure while accepting a TLS connection on 
>>>> conn7340 local=192.168.1.1:3128 remote=192.168.1.5:49616 FD 45 flags=1: 
>>>> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
>>>> 03.07.2024 10:52:34ERROR: failure while accepting a TLS connection on 
>>>> conn7316 local=192.168.1.1:3128 remote=192.168.1.5:49609 FD 45 flags=1: 
>>>> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
&

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-04 Thread Jonathan Lee
p redacted
acl splice_only_mac arp redacted
acl splice_only_mac arp redacted
acl splice_only_mac arp redacted

acl NoSSLIntercept ssl::server_name_regex -i "/usr/local/pkg/reg.url.nobump"
acl NoBumpDNS dstdomain "/usr/local/pkg/dns.nobump"

acl markBumped annotate_client bumped=true
acl active_use annotate_client active=true
acl bump_only src 192.168.1.3 #webtv
acl bump_only src 192.168.1.4 #toshiba
acl bump_only src 192.168.1.5 #imac
acl bump_only src 192.168.1.9 #macbook
acl bump_only src 192.168.1.13 #dell

acl bump_only_mac arp redacted redacted redacted
acl bump_only_mac arp 
acl bump_only_mac arp 
acl bump_only_mac arp 
acl bump_only_mac arp 

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 NoBumpDNS active_use
ssl_bump splice NoSSLIntercept active_use
ssl_bump bump bump_only_mac bump_only active_use
acl activated note active_use true
ssl_bump terminate !activated

acl markedBumped note bumped true
url_rewrite_access deny markedBumped

#workers 3
read_ahead_gap 32 KB
#negative_ttl 1 second
#connect_timeout 30 seconds
#request_timeout 60 seconds
#half_closed_clients off
#shutdown_lifetime 10 seconds
#negative_dns_ttl 1 seconds
#ignore_unknown_nameservers on
#client_persistent_connections off
#server_persistent_connections off
#pipeline_prefetch 100

#acl SSLIntercept ssl::server_name_regex -i "/usr/local/pkg/url.bump"
#ssl_bump bump SSLIntercept

# Setup allowed ACLs
# Allow local network(s) on interface(s)
http_access allow localnet
# Default block all to be sure
http_access deny allsrc

icap_enable on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_encode off
icap_client_username_header X-Authenticated-User
icap_preview_enable on
icap_preview_size 1024

icap_service service_avi_req reqmod_precache icap://127.0.0.1:1344/squid_clamav 
bypass=off
adaptation_access service_avi_req allow all
icap_service service_avi_resp respmod_precache 
icap://127.0.0.1:1344/squid_clamav bypass=on
adaptation_access service_avi_resp allow all


I see nothing with that derivative I also added my firewalls cert a bit ago as 
an extra cert but it had no affect on the errors..

So would I use this directive like this

 sslproxy_cert_sign signTrusted bump_only_mac

with bump only mac as my ACL? the reference does not really show a good example 
of use it explains it well 

 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 browsers. This is the
default for trusted origin server certificates.

   signUntrusted
Sign to guarantee an X509_V_ERR_CERT_UNTRUSTED browser error.
This is the default for untrusted origin server certificates
that are not self-signed (see ssl::certUntrusted).

   signSelf
Sign using a self-signed certificate with the right CN to
generate a X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT error in the
browser. This is the default for self-signed origin server
certificates (see ssl::certSelfSigned).

This clause only supports fast acl types.

When sslproxy_cert_sign acl(s) match, Squid uses the corresponding
signing algorithm to generate the certificate and ignores all
subsequent sslproxy_cert_sign options (the first match wins). If no
acl(s) match, the default signing algorithm is determined by errors
detected when obtaining and validating the origin server certificate.

WARNING: SQUID_X509_V_ERR_DOMAIN_MISMATCH and ssl:certDomainMismatch can
be used with sslproxy_cert_adapt, but if and only if Squid is bumping a
CONNECT request that carries a domain name. In all other cases (CONNECT
to an IP address or an intercepted SSL connection), Squid cannot detect
the domain mismatch at certificate generation time when
bump-server-first is used.




> On Jul 4, 2024, at 09:56, Alex Rousskov  
> wrote:
> 
> 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 client does not 
> trust the Certificate Authority that signed the certificate that was used for 
> that TLS connection.
> 
> 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.

Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-03 Thread Jonathan Lee
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 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 abandoning conn7844 local=192.168.1.1:3128 
> remote=192.168.1.5:49702 FD 81 flags=1
> 03.07.2024 10:54:09   ERROR: failure while accepting a TLS connection on 
> conn7648 local=192.168.1.1:3128 remote=192.168.1.5:49672 FD 44 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 03.07.2024 10:54:09   ERROR: failure while accepting a TLS connection on 
> conn7647 local=192.168.1.1:3128 remote=192.168.1.5:49670 FD 43 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 03.07.2024 10:54:09   ERROR: failure while accepting a TLS connection on 
> conn7646 local=192.168.1.1:3128 remote=192.168.1.5:49668 FD 34 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 03.07.2024 10:53:04   ERROR: failure while accepting a TLS connection on 
> conn7367 local=192.168.1.1:3128 remote=192.168.1.5:49627 FD 22 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 03.07.2024 10:52:47   ERROR: failure while accepting a TLS connection on 
> conn7345 local=192.168.1.1:3128 remote=192.168.1.5:49618 FD 31 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 03.07.2024 10:52:38   ERROR: failure while accepting a TLS connection on 
> conn7340 local=192.168.1.1:3128 remote=192.168.1.5:49616 FD 45 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
> 03.07.2024 10:52:34   ERROR: failure while accepting a TLS connection on 
> conn7316 local=192.168.1.1:3128 remote=192.168.1.5:49609 FD 45 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 31.12.1969 16:00:00   
> 03.07.2024 10:51:55   WARNING: Error Pages Missing Language: en-us
> 31.12.1969 16:00:00   
> 03.07.2024 10:51:55   ERROR: loading file 
> 9;/usr/local/etc/squid/errors/en-us/ERR_ZERO_SIZE_OBJECT': (2) No such file 
> or directory
> 03.07.2024 10:51:44   ERROR: failure while accepting a TLS connection on 
> conn7102 local=192.168.1.1:3128 remote=192.168.1.5:49574 FD 34 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 03.07.2024 10:51:28   ERROR: failure while accepting a TLS connection on 
> conn7071 local=192.168.1.1:3128 remote=192.168.1.5:49568 FD 92 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 03.07.2024 10:50:29   ERROR: failure while accepting a TLS connection on 
> conn6944 local=192.168.1.1:3128 remote=192.168.1.5:49534 FD 101 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
> 03.07.2024 10:49:54   ERROR: failure while accepting a TLS connection on 
> conn6866 local=192.168.1.1:3128 remote=192.168.1.5:49519 FD 31 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 03.07.2024 10:49:38   ERROR: failure while accepting a TLS connection on 
> conn6809 local=192.168.1.1:3128 remote=192.168.1.5:49503 FD 31 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 31.12.1969 16:00:00   
> 03.07.2024 10:49:32   ERROR: system call failure while accepting a TLS 
> connection on conn6794 local=192.168.1.1:3128 remote=192.168.1.5:49496 FD 19 
> flags=1: SQUID_TLS_ERR_ACCEPT+TLS_IO_ERR=5+errno=54
> 03.07.2024 10:49:24   ERROR: failure while accepting a TLS connection on 
> conn6776 local=192.168.1.1:3128 remote=192.168.1.5:49481 FD 137 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
> 03.07.2024 10:48:49   ERROR: failure while accepting a TLS connection on 
> conn6440 local=192.168.1.1:3128 remote=192.168.1.5:49424 FD 16 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
> 03.07.2024 10:48:49   ERROR: failure while accepting a TLS connection on 
> conn6445 local=192.168.1.1:3128 remote=192.168.1.5:49426 FD 34 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 03.07.2024 10:48:22   ERROR: failure while accepting a TLS connection on 
> conn6035 local=192.168.1.1:3128 remote=192.168.1.5:49355 FD 226 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
> 03.07.2024 10:48:09   ERROR: failure while accepting a TLS connection on 
> conn5887 local=192.168.1.1:3128 remote=192.168.1.5:49318 FD 33 flags=1: 
> SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
> 03.07.2024 10:48:09   ERROR: failure while accepting a TLS connection on 
> conn5875 local=192.168.1.1:3128 re

[squid-users] Squid Cache Issues migration from 5.8 to 6.6

2024-07-03 Thread Jonathan Lee
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 abandoning conn7844 local=192.168.1.1:3128 
remote=192.168.1.5:49702 FD 81 flags=1
03.07.2024 10:54:09 ERROR: failure while accepting a TLS connection on 
conn7648 local=192.168.1.1:3128 remote=192.168.1.5:49672 FD 44 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:54:09 ERROR: failure while accepting a TLS connection on 
conn7647 local=192.168.1.1:3128 remote=192.168.1.5:49670 FD 43 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:54:09 ERROR: failure while accepting a TLS connection on 
conn7646 local=192.168.1.1:3128 remote=192.168.1.5:49668 FD 34 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:53:04 ERROR: failure while accepting a TLS connection on 
conn7367 local=192.168.1.1:3128 remote=192.168.1.5:49627 FD 22 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:52:47 ERROR: failure while accepting a TLS connection on 
conn7345 local=192.168.1.1:3128 remote=192.168.1.5:49618 FD 31 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:52:38 ERROR: failure while accepting a TLS connection on 
conn7340 local=192.168.1.1:3128 remote=192.168.1.5:49616 FD 45 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
03.07.2024 10:52:34 ERROR: failure while accepting a TLS connection on 
conn7316 local=192.168.1.1:3128 remote=192.168.1.5:49609 FD 45 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
31.12.1969 16:00:00 
03.07.2024 10:51:55 WARNING: Error Pages Missing Language: en-us
31.12.1969 16:00:00 
03.07.2024 10:51:55 ERROR: loading file 
9;/usr/local/etc/squid/errors/en-us/ERR_ZERO_SIZE_OBJECT': (2) No such file or 
directory
03.07.2024 10:51:44 ERROR: failure while accepting a TLS connection on 
conn7102 local=192.168.1.1:3128 remote=192.168.1.5:49574 FD 34 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:51:28 ERROR: failure while accepting a TLS connection on 
conn7071 local=192.168.1.1:3128 remote=192.168.1.5:49568 FD 92 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:50:29 ERROR: failure while accepting a TLS connection on 
conn6944 local=192.168.1.1:3128 remote=192.168.1.5:49534 FD 101 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
03.07.2024 10:49:54 ERROR: failure while accepting a TLS connection on 
conn6866 local=192.168.1.1:3128 remote=192.168.1.5:49519 FD 31 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:49:38 ERROR: failure while accepting a TLS connection on 
conn6809 local=192.168.1.1:3128 remote=192.168.1.5:49503 FD 31 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
31.12.1969 16:00:00 
03.07.2024 10:49:32 ERROR: system call failure while accepting a TLS 
connection on conn6794 local=192.168.1.1:3128 remote=192.168.1.5:49496 FD 19 
flags=1: SQUID_TLS_ERR_ACCEPT+TLS_IO_ERR=5+errno=54
03.07.2024 10:49:24 ERROR: failure while accepting a TLS connection on 
conn6776 local=192.168.1.1:3128 remote=192.168.1.5:49481 FD 137 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
03.07.2024 10:48:49 ERROR: failure while accepting a TLS connection on 
conn6440 local=192.168.1.1:3128 remote=192.168.1.5:49424 FD 16 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
03.07.2024 10:48:49 ERROR: failure while accepting a TLS connection on 
conn6445 local=192.168.1.1:3128 remote=192.168.1.5:49426 FD 34 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:48:22 ERROR: failure while accepting a TLS connection on 
conn6035 local=192.168.1.1:3128 remote=192.168.1.5:49355 FD 226 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
03.07.2024 10:48:09 ERROR: failure while accepting a TLS connection on 
conn5887 local=192.168.1.1:3128 remote=192.168.1.5:49318 FD 33 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:48:09 ERROR: failure while accepting a TLS connection on 
conn5875 local=192.168.1.1:3128 remote=192.168.1.5:49312 FD 216 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:48:09 ERROR: failure while accepting a TLS connection on 
conn5876 local=192.168.1.1:3128 remote=192.168.1.5:49314 FD 217 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1
03.07.2024 10:47:57 ERROR: failure while accepting a TLS connection on 
conn5815 local=192.168.1.1:3128 remote=192.168.1.5:49297 FD 201 flags=1: 
SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1
03.07.2024 10:47:54 ERROR: failure while accepting a TLS conne

[squid-users] Speed issues

2024-07-03 Thread Jonathan Lee
Does anyone have tips for getting the proxy to run faster when SSL intercept is 
enabled along side splice lists with dynamic cache and ClamAV running?


I just seems to have slow traffic on the interception side. 
Sent from my iPhone
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] FATAL: assertion failed: mem/PageStack.cc:159: "StoredNode().is_lock_free()"

2024-06-27 Thread Jonathan Lee
I have Squid 5.8 I can’t start it with multiple workers enabled in pfSense 
also. It is a 64bit 2100MAX
Sent from my iPhone

> On Jun 27, 2024, at 08:12, Nishant Sharma  wrote:
> 
> Hello,
> 
> I am running squid 6.10 on Openwrt 23.05.2, which is cross compiled for 
> ramips / mipsel_24kc which has a 32 bit CPU (MT7621A) with 2 cores and 2 
> threads.
> 
> Squid fails to start in SMP mode when I set workers > 1.
> 
> SMP worked fine with squid 4.13 on same architecture.
> 
> I have filed a bug report with Openwrt at
> 
> https://github.com/openwrt/packages/issues/24469
> 
> where someone suggested, "ramips has one CPU and the assert is that system 
> pointers are not 64bit."
> 
> Below are the logs for debug_options 54,9:
> 
> 2024/06/27 19:48:45.888| 54,3| mem/Segment.cc(245) unlink: unlinked 
> /squid-cf__metadata.shm segment
> 2024/06/27 19:48:45.888| 54,3| mem/Segment.cc(128) create: created 
> /squid-cf__metadata.shm segment: 8
> 2024/06/27 19:48:45.888| 54,5| mem/Segment.cc(211) lock: mlock(2)-ing disabled
> 2024/06/27 19:48:45.889| 54,3| mem/Segment.cc(245) unlink: unlinked 
> /squid-cf__queues.shm segment
> 2024/06/27 19:48:45.889| 54,3| mem/Segment.cc(128) create: created 
> /squid-cf__queues.shm segment: 32852
> 2024/06/27 19:48:45.889| 54,5| mem/Segment.cc(211) lock: mlock(2)-ing disabled
> 2024/06/27 19:48:45.890| 54,3| mem/Segment.cc(245) unlink: unlinked 
> /squid-cf__readers.shm segment
> 2024/06/27 19:48:45.890| 54,3| mem/Segment.cc(128) create: created 
> /squid-cf__readers.shm segment: 40
> 2024/06/27 19:48:45.890| 54,5| mem/Segment.cc(211) lock: mlock(2)-ing disabled
> 2024/06/27 19:48:45.891| 54,7| Queue.cc(50) QueueReader: constructed ipcQR1
> 2024/06/27 19:48:45.891| 54,7| Queue.cc(50) QueueReader: constructed ipcQR2
> 2024/06/27 19:48:45.891| 54,5| mem/PageStack.cc(129) IdSetMeasurements: 
> rounded capacity up from 8192 to 8192
> 2024/06/27 19:48:45.891| 54,3| mem/Segment.cc(245) unlink: unlinked 
> /squid-squid-page-pool.shm segment
> 2024/06/27 19:48:45.892| 54,3| mem/Segment.cc(128) create: created 
> /squid-squid-page-pool.shm segment: 268437592
> 2024/06/27 19:48:45.892| 54,5| mem/Segment.cc(211) lock: mlock(2)-ing disabled
> 2024/06/27 19:48:45.892| 54,5| mem/PageStack.cc(129) IdSetMeasurements: 
> rounded capacity up from 8192 to 8192
> 2024/06/27 19:48:45| FATAL: assertion failed: mem/PageStack.cc:159: 
> "StoredNode().is_lock_free()"
> 
> 
> Any pointers would be really helpful.
> 
> Thanks in advance.
> 
> Regards,
> Nishant
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] FATAL: assertion failed: mem/PageStack.cc:159: "StoredNode().is_lock_free()"

2024-06-27 Thread Jonathan Lee
Has anyone ran this on a Banana Pi r3 or r4? 
Sent from my iPhone

> On Jun 27, 2024, at 08:12, Nishant Sharma  wrote:
> 
> Hello,
> 
> I am running squid 6.10 on Openwrt 23.05.2, which is cross compiled for 
> ramips / mipsel_24kc which has a 32 bit CPU (MT7621A) with 2 cores and 2 
> threads.
> 
> Squid fails to start in SMP mode when I set workers > 1.
> 
> SMP worked fine with squid 4.13 on same architecture.
> 
> I have filed a bug report with Openwrt at
> 
> https://github.com/openwrt/packages/issues/24469
> 
> where someone suggested, "ramips has one CPU and the assert is that system 
> pointers are not 64bit."
> 
> Below are the logs for debug_options 54,9:
> 
> 2024/06/27 19:48:45.888| 54,3| mem/Segment.cc(245) unlink: unlinked 
> /squid-cf__metadata.shm segment
> 2024/06/27 19:48:45.888| 54,3| mem/Segment.cc(128) create: created 
> /squid-cf__metadata.shm segment: 8
> 2024/06/27 19:48:45.888| 54,5| mem/Segment.cc(211) lock: mlock(2)-ing disabled
> 2024/06/27 19:48:45.889| 54,3| mem/Segment.cc(245) unlink: unlinked 
> /squid-cf__queues.shm segment
> 2024/06/27 19:48:45.889| 54,3| mem/Segment.cc(128) create: created 
> /squid-cf__queues.shm segment: 32852
> 2024/06/27 19:48:45.889| 54,5| mem/Segment.cc(211) lock: mlock(2)-ing disabled
> 2024/06/27 19:48:45.890| 54,3| mem/Segment.cc(245) unlink: unlinked 
> /squid-cf__readers.shm segment
> 2024/06/27 19:48:45.890| 54,3| mem/Segment.cc(128) create: created 
> /squid-cf__readers.shm segment: 40
> 2024/06/27 19:48:45.890| 54,5| mem/Segment.cc(211) lock: mlock(2)-ing disabled
> 2024/06/27 19:48:45.891| 54,7| Queue.cc(50) QueueReader: constructed ipcQR1
> 2024/06/27 19:48:45.891| 54,7| Queue.cc(50) QueueReader: constructed ipcQR2
> 2024/06/27 19:48:45.891| 54,5| mem/PageStack.cc(129) IdSetMeasurements: 
> rounded capacity up from 8192 to 8192
> 2024/06/27 19:48:45.891| 54,3| mem/Segment.cc(245) unlink: unlinked 
> /squid-squid-page-pool.shm segment
> 2024/06/27 19:48:45.892| 54,3| mem/Segment.cc(128) create: created 
> /squid-squid-page-pool.shm segment: 268437592
> 2024/06/27 19:48:45.892| 54,5| mem/Segment.cc(211) lock: mlock(2)-ing disabled
> 2024/06/27 19:48:45.892| 54,5| mem/PageStack.cc(129) IdSetMeasurements: 
> rounded capacity up from 8192 to 8192
> 2024/06/27 19:48:45| FATAL: assertion failed: mem/PageStack.cc:159: 
> "StoredNode().is_lock_free()"
> 
> 
> Any pointers would be really helpful.
> 
> Thanks in advance.
> 
> Regards,
> Nishant
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Anybody still using src_as and dst_as ACLs?

2024-06-17 Thread Jonathan Lee
Is there a different type of directive for source and destination acts?
Sent from my iPhone

> On Jun 17, 2024, at 11:03, Alex Rousskov  
> wrote:
> 
> On 2024-06-17 11:43, Jonathan Lee wrote:
>> acl to_ipv6 dst ipv6
>> acl from_ipv6 src ipv6
> 
> 
> Glad I asked! The above configuration is not using "src_as" and "dst_as" ACL 
> types that I am asking about. It is using "src" and "dst" ACL types.
> 
> 
> > I hope that helps our isp is ipv6 only
> 
> Matching IPv6 addresses is completely unrelated to this thread topic, but you 
> may want to see the following commit message about "ipv6" problems recently 
> fixed in master/v7. If you want to discuss IPv6 matching, please start a new 
> mailing list thread!
> https://github.com/squid-cache/squid/commit/51c518d5
> 
> 
> 
> Thank you,
> 
> Alex.
> 
> 
>>>> On Jun 17, 2024, at 08:17, Alex Rousskov 
>>>>  wrote:
>>> 
>>> On 2024-06-16 19:46, Jonathan Lee wrote:
>>>> I use them for ipv6 blocks they seem to work that way in 5.8
>>> 
>>> Just to double check that we are on the same page here, please share an 
>>> example (or two) of your src_as or dst_as ACL definitions (i.e., "acl ... 
>>> dst_as ..." or similar lines). I do _not_ need the corresponding directives 
>>> that use those AS-based ACLs (e.g., "http_access deny..."), just the "acl" 
>>> lines themselves.
>>> 
>>> As an added bonus, I may be able to confirm whether Squid v5.8 can grok 
>>> responses about Autonomous System Numbers used by your specific 
>>> configuration :-).
>>> 
>>> 
>>> Thank you,
>>> 
>>> Alex.
>>> 
>>> 
>>>>> On Jun 16, 2024, at 17:00, Alex Rousskov 
>>>>>  wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>>Does anybody still have src_as and dst_as ACLs configured in their 
>>>>> production Squids? There are several serious problems with those ACLs, 
>>>>> and those problems have been present in Squid for many years. I hope that 
>>>>> virtually nobody uses those ACLs today.
>>>>> 
>>>>> If you do use them, please respond (publicly or privately) and, if 
>>>>> possible, please indicate whether you have verified that those ACLs are 
>>>>> working correctly in your deployment environment.
>>>>> 
>>>>> 
>>>>> Thank you,
>>>>> 
>>>>> Alex.
>>>>> 
>>>>> 
>>>>>>acl aclname src_as number ...
>>>>>>acl aclname dst_as number ...
>>>>>>  # [fast]
>>>>>>  # Except for access control, AS numbers can be used for
>>>>>>  # routing of requests to specific caches. Here's an
>>>>>>  # example for routing all requests for AS#1241 and only
>>>>>>  # those to mycache.mydomain.net:
>>>>>>  # acl asexample dst_as 1241
>>>>>>  # cache_peer_access mycache.mydomain.net allow asexample
>>>>>>  # cache_peer_access mycache_mydomain.net deny all
>>>>> ___
>>>>> squid-users mailing list
>>>>> squid-users@lists.squid-cache.org
>>>>> https://lists.squid-cache.org/listinfo/squid-users
>>> 
> 
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Anybody still using src_as and dst_as ACLs?

2024-06-17 Thread Jonathan Lee
acl to_ipv6 dst ipv6
acl from_ipv6 src ipv6

I after block them with terminate connections.

I hope that helps our isp is ipv6 only
Sent from my iPhone

> On Jun 17, 2024, at 08:17, Alex Rousskov  
> wrote:
> 
> On 2024-06-16 19:46, Jonathan Lee wrote:
>> I use them for ipv6 blocks they seem to work that way in 5.8
> 
> Just to double check that we are on the same page here, please share an 
> example (or two) of your src_as or dst_as ACL definitions (i.e., "acl ... 
> dst_as ..." or similar lines). I do _not_ need the corresponding directives 
> that use those AS-based ACLs (e.g., "http_access deny..."), just the "acl" 
> lines themselves.
> 
> As an added bonus, I may be able to confirm whether Squid v5.8 can grok 
> responses about Autonomous System Numbers used by your specific configuration 
> :-).
> 
> 
> Thank you,
> 
> Alex.
> 
> 
>>>> On Jun 16, 2024, at 17:00, Alex Rousskov 
>>>>  wrote:
>>> 
>>> Hello,
>>> 
>>>Does anybody still have src_as and dst_as ACLs configured in their 
>>> production Squids? There are several serious problems with those ACLs, and 
>>> those problems have been present in Squid for many years. I hope that 
>>> virtually nobody uses those ACLs today.
>>> 
>>> If you do use them, please respond (publicly or privately) and, if 
>>> possible, please indicate whether you have verified that those ACLs are 
>>> working correctly in your deployment environment.
>>> 
>>> 
>>> Thank you,
>>> 
>>> Alex.
>>> 
>>> 
>>>>acl aclname src_as number ...
>>>>acl aclname dst_as number ...
>>>>  # [fast]
>>>>  # Except for access control, AS numbers can be used for
>>>>  # routing of requests to specific caches. Here's an
>>>>  # example for routing all requests for AS#1241 and only
>>>>  # those to mycache.mydomain.net:
>>>>  # acl asexample dst_as 1241
>>>>  # cache_peer_access mycache.mydomain.net allow asexample
>>>>  # cache_peer_access mycache_mydomain.net deny all
>>> ___
>>> squid-users mailing list
>>> squid-users@lists.squid-cache.org
>>> https://lists.squid-cache.org/listinfo/squid-users
> 
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Anybody still using src_as and dst_as ACLs?

2024-06-16 Thread Jonathan Lee
I use them for ipv6 blocks they seem to work that way in 5.8
Sent from my iPhone

> On Jun 16, 2024, at 17:00, Alex Rousskov  
> wrote:
> 
> Hello,
> 
>Does anybody still have src_as and dst_as ACLs configured in their 
> production Squids? There are several serious problems with those ACLs, and 
> those problems have been present in Squid for many years. I hope that 
> virtually nobody uses those ACLs today.
> 
> If you do use them, please respond (publicly or privately) and, if possible, 
> please indicate whether you have verified that those ACLs are working 
> correctly in your deployment environment.
> 
> 
> Thank you,
> 
> Alex.
> 
> 
>>acl aclname src_as number ...
>>acl aclname dst_as number ...
>>  # [fast]
>>  # Except for access control, AS numbers can be used for
>>  # routing of requests to specific caches. Here's an
>>  # example for routing all requests for AS#1241 and only
>>  # those to mycache.mydomain.net:
>>  # acl asexample dst_as 1241
>>  # cache_peer_access mycache.mydomain.net allow asexample
>>  # cache_peer_access mycache_mydomain.net deny all
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Information Request: "Accept-Ranges" with use of SSL intercept and dynamic update caching

2024-06-14 Thread Jonathan Lee
Thanks for the info. That makes this directive very clear.
Sent from my iPhone

> On Jun 14, 2024, at 01:46, Amos Jeffries  wrote:
> 
> On 11/06/24 16:47, Jonathan Lee wrote:
>> The reason I ask is sometimes Facebook when I am using it locks up and my 
>> fan goes crazy I close Safari and restart the browser and it works fine 
>> again. It acts like it is restarting a download over and over again.
> 
> Because it is. Those websites use "infinite scrolling" for delivery. 
> Accept-Ranges tells the server that it does not have to re-deliver the entire 
> JSON dataset for the scrolling part in full, every few seconds.
> 
> That header is defined by 
> <https://www.rfc-editor.org/rfc/rfc9110#name-accept-ranges>
> 
> 
> HTH
> Amos
> 
> 
>>>> On Jun 10, 2024, at 21:45, Jonathan Lee wrote:
>>> 
>>> Hello fellow Squid community can you please help?
>>> 
>>> Should I be using the following if I have SSL certificates, dynamic 
>>> updates, StoreID, and ClamAV running?
>>> 
>>> *request_header_access Accept-Ranges deny all reply_header_access 
>>> Accept-Ranges deny all request_header_replace Accept-Ranges none 
>>> reply_header_replace Accept-Ranges none*
>>> 
>>> None of the documents show what Accept-Ranges does
>>> 
>>> Can anyone help explain this to me?
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Error Question

2024-06-13 Thread Jonathan Lee
Bug #1: Coredumps not functional for non-root processes. - pfSense - pfSense bugtrackerredmine.pfsense.orgThere is a bug in pfSense not allowing core dumps. Sent from my iPhoneOn Jun 12, 2024, at 17:58, Jonathan Lee  wrote:Shell Output - ls -l /var/log/squid/try.sh-rwxrwxrwx  1 root  squid  46 Jun 12 17:55 /var/log/squid/try.shOn Jun 12, 2024, at 15:38, Alex Rousskov  wrote:If same user does not expose the difference, start the test script from the directory where you told Squid to dump core.___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Error Question

2024-06-12 Thread Jonathan Lee
Shell Output - ls -l /var/log/squid/try.sh
-rwxrwxrwx  1 root  squid  46 Jun 12 17:55 /var/log/squid/try.sh
> On Jun 12, 2024, at 15:38, Alex Rousskov  
> wrote:
> 
> If same user does not expose the difference, start the test script from the 
> directory where you told Squid to dump core.

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Error Question

2024-06-12 Thread Jonathan Lee
If same user does not expose the difference, start the test script from the 
directory where you told Squid to dump core.

Shell Output - /var/log/squid/try.sh
sh: /var/log/squid/try.sh: Permission denied
I can’t run it I have set it to chmod 777 and running it as root.
I do not have the sudo enabled currently however I wonder if I add root to the 
/var/log/squid it that would fix it


> On Jun 12, 2024, at 15:38, Alex Rousskov  
> wrote:
> 
> If same user does not expose the difference, start the test script from the 
> directory where you told Squid to dump core.

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Error Question

2024-06-12 Thread Jonathan Lee
when killing squid I only get the following and no core dumps core does does 
work I have tested it with a sanity check with the help of FreeBSD forum users. 
However it just does not show a core dump for me on anything kill -11 kill -6 
killall or kill -SIGABRT. I have it set in the config to use coredump directory 
also 
https://forums.freebsd.org/threads/core-dumps.93778/page-2


Jun 12 14:49:09 kernel  pid 87824 (squid), jid 0, uid 100: exited on 
signal 6
Jun 12 14:47:52 kernel  pid 87551 (squid), jid 0, uid 0: exited on 
signal 11


> On Jun 12, 2024, at 10:19, Jonathan Lee  wrote:
> 
> You know what it was, it needed to be bound to the loopback and not just the 
> LAN, again I am still working on getting a core dump file manually. Will 
> update once I get one. Chmod might be needed. 
> Sent from my iPhone
> 
>> On Jun 12, 2024, at 06:13, Alex Rousskov  
>> wrote:
>> 
>> On 2024-06-11 23:32, Jonathan Lee wrote:
>> 
>>> So I just run this on command line SIGABRT squid?
>> 
>> On Unix-like systems, the command to send a process a signal is called 
>> "kill": https://www.man7.org/linux/man-pages/man1/kill.1p.html
>> 
>> For example, if you want to abort a Squid worker process that has OS process 
>> ID (PID) 12345, you may do something like this:
>> 
>>   sudo kill -SIGABRT 12345
>> 
>> You can use "ps" or "top" commands to learn PIDs of processes you want to 
>> signal.
>> 
>> 
>>> also added an item to the Netgate forum to, but not many users are Squid 
>>> wizards
>> 
>> Beyond using a reasonable coredump_dir value in squid.conf, the system 
>> administration problems you need to solve to enable Squid core dumps are 
>> most likely not specific to Squid.
>> 
>> 
>> HTH,
>> 
>> Alex.
>> 
>> 
>>> It’s funny as soon as I enabled the sysctl command and set the directory it 
>>> won’t crash anymore. I also changed it to reside on the loopback before it 
>>> was only on my lan interface. I run an external drive as my swap partition 
>>> or a swap drive, it works I get crash reports when playing around with 
>>> stuff. /dev/da0 or something it dumps to it and when it reboots shows in 
>>> the var/crash folder and will display on gui report ready, again if anyone 
>>> else knows pfSense let me know. I also added an item to the Netgate forum 
>>> to, but not many users are Squid wizards so it might take a long time to 
>>> get any community input over there.
>> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Error Question

2024-06-12 Thread Jonathan Lee
You know what it was, it needed to be bound to the loopback and not just the 
LAN, again I am still working on getting a core dump file manually. Will update 
once I get one. Chmod might be needed. 
Sent from my iPhone

> On Jun 12, 2024, at 06:13, Alex Rousskov  
> wrote:
> 
> On 2024-06-11 23:32, Jonathan Lee wrote:
> 
>> So I just run this on command line SIGABRT squid?
> 
> On Unix-like systems, the command to send a process a signal is called 
> "kill": https://www.man7.org/linux/man-pages/man1/kill.1p.html
> 
> For example, if you want to abort a Squid worker process that has OS process 
> ID (PID) 12345, you may do something like this:
> 
>sudo kill -SIGABRT 12345
> 
> You can use "ps" or "top" commands to learn PIDs of processes you want to 
> signal.
> 
> 
>> also added an item to the Netgate forum to, but not many users are Squid 
>> wizards
> 
> Beyond using a reasonable coredump_dir value in squid.conf, the system 
> administration problems you need to solve to enable Squid core dumps are most 
> likely not specific to Squid.
> 
> 
> HTH,
> 
> Alex.
> 
> 
>> It’s funny as soon as I enabled the sysctl command and set the directory it 
>> won’t crash anymore. I also changed it to reside on the loopback before it 
>> was only on my lan interface. I run an external drive as my swap partition 
>> or a swap drive, it works I get crash reports when playing around with 
>> stuff. /dev/da0 or something it dumps to it and when it reboots shows in the 
>> var/crash folder and will display on gui report ready, again if anyone else 
>> knows pfSense let me know. I also added an item to the Netgate forum to, but 
>> not many users are Squid wizards so it might take a long time to get any 
>> community input over there.
> 
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Error Question

2024-06-11 Thread Jonathan Lee
So I just run this on command line SIGABRT squid? It’s funny as soon as I 
enabled the sysctl command and set the directory it won’t crash anymore. I also 
changed it to reside on the loopback before it was only on my lan interface. I 
run an external drive as my swap partition or a swap drive, it works I get 
crash reports when playing around with stuff. /dev/da0 or something it dumps to 
it and when it reboots shows in the var/crash folder and will display on gui 
report ready, again if anyone else knows pfSense let me know. I also added an 
item to the Netgate forum to, but not many users are Squid wizards so it might 
take a long time to get any community input over there. 
Sent from my iPhone

> On Jun 11, 2024, at 19:15, Alex Rousskov  
> wrote:
> 
> SIGABRT
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Error Question

2024-06-11 Thread Jonathan Lee
When I run  sysctl debug.kdb.panic=1 I get a crash report for pfsense in 
var/crash should my path for core dumps use my swap drive too?



> On Jun 11, 2024, at 14:42, Alex Rousskov  
> wrote:
> 
> On 2024-06-11 17:06, Jonathan Lee wrote:
> 
>> I can’t locate the dump file for segmentation fault it never generates one.
> 
> I assume that you cannot locate the core dump file because your 
> OS/environment is not configured to produce core dump files. Enabling core 
> dumps is a sysadmin task that is mostly independent from Squid specifics. The 
> FAQ I linked to earlier has some hints, but none are pfsense-specific. If 
> others on the list do not tell you how to enable coredumps on pfsense, you 
> may want to ask on pfsense or sysadmin forums.
> 
> Alternatively, you can try starting Squid from gdb or attacking gdb to a 
> running Squid kid process, but neither is trivial, especially if you are 
> using SMP Squid. The same FAQ has some hints.
> 
> BTW, to test whether core dumps are enabled in your environment, you do not 
> need to wait for Squid to crash. Instead, you can send a SIGABRT signal (as 
> "root" if needed) to any running test process and see whether it creates a 
> core dump file when crashing.
> 
> 
>> I am running cache it shows a swap file however it is not readable.
> 
> There are many kinds of swap files, but the core file we need is probably not 
> one of them.
> 
> 
>> I fixed the other issues.
> 
> Glad to hear that!
> 
> Alex.
> 
> 
>>> On Jun 11, 2024, at 14:00, Alex Rousskov  
>>> wrote:
>>> 
>>> On 2024-06-11 14:46, Jonathan Lee wrote:
>>>> 2024-05-16 14:10:23 [60780] loading dbfile 
>>>> /var/db/squidGuard/Nick_Blocks/urls.db
>>>> 2024/06/11 10:23:05 kid1| FATAL: Received Segment Violation...dying.
>>>> 2024/06/11 10:23:25 kid1| Starting Squid Cache version 5.8 for 
>>>> aarch64-portbld-freebsd14.0...
>>>> 2024/06/11 10:23:25 kid1| Service Name: squid
>>>> 2024-06-11 10:23:25 [9471] (squidGuard): can't write to logfile 
>>>> /var/log/squidGuard/squidGuard.log
>>>> 2024-06-11 10:23:25 [9471] New setting: logdir: /var/squidGuard/log
>>>> 2024-06-11 10:23:25 [9471] New setting: dbhome: /var/db/squidGuard
>>>> 2024-06-11 10:23:25 [9471] init domainlist 
>>>> /var/db/squidGuard/blk_blacklists_adult/domains
>>>> 2024-06-11 10:23:25 [9471] loading dbfile 
>>>> /var/db/squidGuard/blk_blacklists_adult/domains.db
>>>> 2024-06-11 10:23:25 [9471] init expressionlist 
>>>> /var/db/squidGuard/blk_blacklists_adult/expressions
>>>> There is my log file being blocked for some reason
>>> 
>>> Just to avoid a misunderstanding: This mailing list thread is about the 
>>> segmentation fault bug you have reported earlier. The above log is _not_ 
>>> the requested backtrace that we need to triage that bug. If there is 
>>> another problem you need help with, please start a new mailing list thread 
>>> and detail _that_ problem there.
>>> 
>>> 
>>> Thank you,
>>> 
>>> Alex.
>>> 
>>> 
>>>>> On Jun 11, 2024, at 11:24, Jonathan Lee  wrote:
>>>>> 
>>>>> thanks i have enabled
>>>>> 
>>>>> coredump_dir /var/squid/logs
>>>>> 
>>>>> I will submit a dump as soon as it occurs again
>>>>> 
>>>>>> On Jun 11, 2024, at 11:17, Jonathan Lee  wrote:
>>>>>> 
>>>>>> I have attempted to upgrade the program fails to recognize ”DHParamas 
>>>>>> Key Size” and will no longer use my certificates and shows many errors. 
>>>>>> I am kind of stuck on 5.8
>>>>>> 
>>>>>> I do not know where the core dump would be located on pfSense let me 
>>>>>> research this and get back to you.
>>>>>> 
>>>>>>> On Jun 11, 2024, at 11:04, Alex Rousskov 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> On 2024-06-11 13:24, Jonathan Lee wrote:
>>>>>>>> FATAL: Received Segment Violation...dying.
>>>>>>>> Does any know how to fix this??
>>>>>>> 
>>>>>>> Please post full backtrace from this failure:
>>>>>>> https://wiki.squid-cache.org/SquidFaq/BugReporting#crashes-and-core-dumps
>>>>>>> 
>>>>>>> The other information you have already provided may help, but without a 
>>>>>>> usable stack trace, it is unlikely that somebody will guess what is 
>>>>>>> going on with your Squid.
>>>>>>> 
>>>>>>> Please note that you are running Squid v5 that is no longer supported 
>>>>>>> by the Squid Project. You should upgrade to v6+. However, I do not know 
>>>>>>> whether that upgrade is going to address the specific problem you are 
>>>>>>> suffering from.
>>>>>>> 
>>>>>>> 
>>>>>>> HTH,
>>>>>>> 
>>>>>>> Alex.
>>>>>>> 
>>>>>>> ___
>>>>>>> squid-users mailing list
>>>>>>> squid-users@lists.squid-cache.org
>>>>>>> https://lists.squid-cache.org/listinfo/squid-users
> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] Error Question

2024-06-11 Thread Jonathan Lee
I can’t locate the dump file for segmentation fault it never generates one. I 
am running cache it shows a swap file however it is not readable.

I fixed the other issues. 

> On Jun 11, 2024, at 14:00, Alex Rousskov  
> wrote:
> 
> On 2024-06-11 14:46, Jonathan Lee wrote:
>> 2024-05-16 14:10:23 [60780] loading dbfile 
>> /var/db/squidGuard/Nick_Blocks/urls.db
>> 2024/06/11 10:23:05 kid1| FATAL: Received Segment Violation...dying.
>> 2024/06/11 10:23:25 kid1| Starting Squid Cache version 5.8 for 
>> aarch64-portbld-freebsd14.0...
>> 2024/06/11 10:23:25 kid1| Service Name: squid
>> 2024-06-11 10:23:25 [9471] (squidGuard): can't write to logfile 
>> /var/log/squidGuard/squidGuard.log
>> 2024-06-11 10:23:25 [9471] New setting: logdir: /var/squidGuard/log
>> 2024-06-11 10:23:25 [9471] New setting: dbhome: /var/db/squidGuard
>> 2024-06-11 10:23:25 [9471] init domainlist 
>> /var/db/squidGuard/blk_blacklists_adult/domains
>> 2024-06-11 10:23:25 [9471] loading dbfile 
>> /var/db/squidGuard/blk_blacklists_adult/domains.db
>> 2024-06-11 10:23:25 [9471] init expressionlist 
>> /var/db/squidGuard/blk_blacklists_adult/expressions
>> There is my log file being blocked for some reason
> 
> Just to avoid a misunderstanding: This mailing list thread is about the 
> segmentation fault bug you have reported earlier. The above log is _not_ the 
> requested backtrace that we need to triage that bug. If there is another 
> problem you need help with, please start a new mailing list thread and detail 
> _that_ problem there.
> 
> 
> Thank you,
> 
> Alex.
> 
> 
>>> On Jun 11, 2024, at 11:24, Jonathan Lee  wrote:
>>> 
>>> thanks i have enabled
>>> 
>>> coredump_dir /var/squid/logs
>>> 
>>> I will submit a dump as soon as it occurs again
>>> 
>>>> On Jun 11, 2024, at 11:17, Jonathan Lee  wrote:
>>>> 
>>>> I have attempted to upgrade the program fails to recognize ”DHParamas Key 
>>>> Size” and will no longer use my certificates and shows many errors. I am 
>>>> kind of stuck on 5.8
>>>> 
>>>> I do not know where the core dump would be located on pfSense let me 
>>>> research this and get back to you.
>>>> 
>>>>> On Jun 11, 2024, at 11:04, Alex Rousskov 
>>>>>  wrote:
>>>>> 
>>>>> On 2024-06-11 13:24, Jonathan Lee wrote:
>>>>>> FATAL: Received Segment Violation...dying.
>>>>>> Does any know how to fix this??
>>>>> 
>>>>> Please post full backtrace from this failure:
>>>>> https://wiki.squid-cache.org/SquidFaq/BugReporting#crashes-and-core-dumps
>>>>> 
>>>>> The other information you have already provided may help, but without a 
>>>>> usable stack trace, it is unlikely that somebody will guess what is going 
>>>>> on with your Squid.
>>>>> 
>>>>> Please note that you are running Squid v5 that is no longer supported by 
>>>>> the Squid Project. You should upgrade to v6+. However, I do not know 
>>>>> whether that upgrade is going to address the specific problem you are 
>>>>> suffering from.
>>>>> 
>>>>> 
>>>>> HTH,
>>>>> 
>>>>> Alex.
>>>>> 
>>>>> ___
>>>>> squid-users mailing list
>>>>> squid-users@lists.squid-cache.org
>>>>> https://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users


  1   2   >