[squid-users] proxy_auth_regex

Mon Oct 28 20:35:32 UTC 2024

Hey everyone, 

Continuing to look into this further. 

TL;DR, anytime I turn on one of our ACL's that have "proxy_auth_regex", I'm unable to access the internet through the proxy at all. 

Here's an example of one of our rules: 

# block certain user IDs from using proxy server
acl block_user proxy_auth_regex -i "/etc/squid/block_user"
http_access deny block_user

I'm testing with an account that is not on the "block_user" list. Yet, when I browse to known good sites, I'm met with a generic webpage error, and not a squid error. The generic error, using Firefox, is "The proxy server is refusing connections". Yet, activating that ACL should not have this behavior. Only if a username that's a part of the block_user list is on there. This is the same for the 3 other rules we're using " proxy_auth_regex" for. Which leads me to believe we're not able to pass what the directive is asking for. 

The issue is, I'm having trouble pinpointing it. 

I went here, on the Squid config pages and looked into it further:
https://www.squid-cache.org/Doc/config/acl/

I read the notes for this directive but I'm still a bit confused on where the issue is. Authentication seems to be working, but it's like this term either doesn't pass the credentials along, or it's expecting some other response. Is there anyone that could help me figure out what the issue is with this? 

Thank you, 
Josh 

-----Original Message-----
From: Alex Rousskov <rousskov at measurement-factory.com> 
Sent: Thursday, October 24, 2024 4:46 PM
To: Piana, Josh <Josh.Piana at hexcel.com>; squid-users at lists.squid-cache.org
Subject: Re: [squid-users] proxy_auth_regex

Caution: This email originated from outside of Hexcel. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On 2024-10-24 16:23, Piana, Josh wrote:

> From what I can tell, squid does not receive a good username. When I check the access logs, I receive something like this:

> 24/Oct/2024:16:01:08 -0400.334 10.46.49.190 TCP_DENIED/407 7821 
> CONNECT 
> http://www.g/
> oogle.com%3A443%2F&data=05%7C02%7CJosh.Piana%40hexcel.com%7C29bbc9983f
> 2742ff81e108dcf46cd820%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C63
> 8653995560620056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=W%2BZDXkp
> r6hr5wvICtWMUGsugzHqz7%2BHS7UEKX7N5CPI%3D&reserved=0 - \ HIER_NONE/- 
> text/html ERR_CACHE_ACCESS_DENIED/-

Please check CONNECT request headers in packet captures or cache.log with debug_options set to ALL,2. If client does not send any user credentials to Squid, then Squid should request them (with a 407 CONNECT response containing appropriate headers).

> In regards to the TLS connectors vs HTTP CONNECT requests ...
 > I'm not sure if that is the case

Does the problematic test transaction arrive at http_port or https_port?

 > is "proxy_auth_regex" not compatible with certain things?

Nearly every Squid configuration option is not compatible with certain things.

 > How would you recommend I test plain http traffic?

I would start with

     curl --verbose ... http://example.com/

or a similar request (add proxy/other options instead of "..." as needed).

Alex.

> However, I think some of my log information may be missing. I believe you mentioned it before, so I'll show you what I'm using for our custom log directive. Maybe we can fix this too? What I originally tried to do with this was just get "human readable" time stamps:
> logformat custom %tl.%03tu %>a %Ss/%03>Hs %<st %rm %ru %[un \ %Sh/%<a 
> %mt %err_code/%err_detail
>
> In regards to the TLS connectors vs HTTP CONNECT requests, that is a great point. I'm not sure if that is the case, but is "proxy_auth_regex" not compatible with certain things? How would you recommend I test plain http traffic?
>
>
> -----Original Message-----
> From: Alex Rousskov <rousskov at measurement-factory.com>
> Sent: Thursday, October 24, 2024 4:13 PM
> To: Piana, Josh <Josh.Piana at hexcel.com>; 
> squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] proxy_auth_regex
>
> Caution: This email originated from outside of Hexcel. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On 2024-10-24 15:53, Piana, Josh wrote:
>> Hey Squid users,
>>
>> Running into an issue I’m trying to figure out.
>>
>> We have a few acl directives using “proxy_auth_regex –i” and when I 
>> have these active, it blocks any proxy connection with an HTTP 407 
>> error, according to the logs.
>>
>> Here’s an example:
>>
>> # block certain user IDs from using proxy server
>>
>> #acl block_user proxy_auth_regex -i "/etc/squid/block_user"
>>
>> #http_access deny block_user
>>
>> What’s supposed to happen with this ACL, is that any username we have 
>> on that list is to be blocked from internet access. But it seems to 
>> be blocking known good usernames too. I’m not sure where to go from 
>> here
>
> After asking for one with a 407 response, does Squid ever receive a "good username" from the client? Do you see a username in client HTTP request headers or access.log records containing %un field?
>
> Perhaps the client refuses to authenticate its requests because Squid intercepts TLS client connections rather than receiving HTTP CONNECT requests from the client? Have you tested this with plain text traffic?
>
> Alex.
>
>
>> we would like to use these ACL’s but for right now I have these rules 
>> commented out.
>>
>> Here's a few other rules we have that have the same issue:
>>
>> # executable blocking
>>
>> # reference this list for extensions to block
>>
>> acl exec_files url_regex -i "/etc/squid/exec_files"
>>
>> # ignore these usernames from being blocked
>>
>> #acl exec_users proxy_auth_regex -i "/etc/squid/exec_users"
>>
>> # combine the rules
>>
>> #http_access deny !bad_exception_urls !exec_users exec_files
>>
>> #deny_info ERR_BLOCK_TYPE exec_files
>>
>>   From what you can see above, we have “acl exec_files url_regex -i 
>> /etc/squid/exec_files" uncommented, but it’s not active because the 
>> “http_access directive” had to be commented out because it includes 
>> the other statements that include “proxy_auth_regex –i” which block 
>> all internet access as well.
>>
>>
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> https://lis/
>> t%2F&data=05%7C02%7CJosh.Piana%40hexcel.com%7C29bbc9983f2742ff81e108d
>> cf46cd820%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C63865399556062
>> 0056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
>> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=PCQLdRbIhLqZa1TDHvK
>> 3tJ4%2Ft7KciRwqiLysnAUxzcE%3D&reserved=0
>> s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7CJosh.Piana%
>> 4
>> 0hexcel.com%7C7fb1087ae57b47c397a408dcf4684eaf%7C4248050df19546d5ac9c
>> 0 
>> c7c52b04cae%7C0%7C0%7C638653976041876515%7CUnknown%7CTWFpbGZsb3d8eyJW
>> I
>> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%
>> 7 
>> C%7C&sdata=D6d%2BXvUp%2FHTvsqC5oneWw%2FdYNWYkmsQUz0lKHLzRk0o%3D&reser
>> v
>> ed=0
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://list/
> s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7CJosh.Piana%4
> 0hexcel.com%7C29bbc9983f2742ff81e108dcf46cd820%7C4248050df19546d5ac9c0
> c7c52b04cae%7C0%7C0%7C638653995560776281%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%
> 7C%7C%7C&sdata=oAOv7ObjGY%2FIMJOAC0LdMf0eJ1wzpn6P0Q5tCNOvSTY%3D&reserv
> ed=0