[squid-users] Questions about Squid configuration

[Alex Rousskov]

On 2024-09-25 01:57, にば wrote:

> We then added the following settings that were in the existing Squid proxy
> 
> # SSL_BUMP
> acl allowed_https_sites ssl::server_name "/etc/squid/whitelist"
> acl allowed_https_sites ssl::server_name "/etc/squid/whitelist_transparent"
> acl allowed_https_sites ssl::server_name "/etc/squid/whitelist_https"
> acl allowed_https_sites ssl::server_name
> "/etc/squid/whitelist_transparent_https"
> sslcrtd_program [sslcrtd-program-setting]
> 
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> 
> ssl_bump peek step1 all
> ssl_bump peek step2 allowed_https_sites
> ssl_bump splice step3 allowed_https_sites
> ssl_bump terminate step2 all
> 
> Then I verified the 4 patterns again and all of them gave me 403 Forbidden...
> Even the following pattern which is allowed in whitelist.
>> 1. successful communication of a valid request to an allowed site
>> curl https://pypi.org/ -v --cacert squid.crt -k
> 
> After checking access-transparent.log and cache.log, it appears that
> pypi.org is comparing inspections by IP and not by domain.

AFAICT, you expect allowed_https_sites ACL to match the above 
intercepted pypi request and, hence, to be allowed by the following 
http_access rule:

     http_access allow allowed_https_sites https_port

Since you are intercepting traffic, at SslBump step1, Squid only sees 
TCP-level information extracted from the intercepted connection. There 
are no domain names. There is no HTTP-level information at that time. 
See "Step 1:" at https://wiki.squid-cache.org/Features/SslPeekAndSplice

When evaluating that dstdomain ACL (allowed_https_sites), Squid will 
attempt to convert the intended destination IP address of the 
intercepted TCP connection to a domain name and will compare the result 
of that conversion to allowed_https_sites entries. Evidently, either 
that reverse DNS lookup fails in your case, or the result (is not 
"pypi.org" and) does not match any allowed_https_sites names.

Since no other "http_access allow" rule matches the fake CONNECT at 
SslBump step1, the transaction is denied by the first "http_access deny 
all" rule (BTW, you can remove the second one -- it is unreachable).


> How do I modify the configuration to allow this correctly by domain?

It is difficult for me to answer this loaded question in a meaningful 
way. At SslBump step1, Squid gets an IP address. Squid has to either 
allow or deny that request based on available information. You have 
several options, including:

A. During SslBump step1, deny access based on IP addresses by adding 
appropriate dst ACLs that would be checked by http_access rules.

B. During SslBump step1, allow fake CONNECT requests to any IP address 
while making sure that you deny what needs to be denied at step2 or step3.


Needless to say, for an http_access rule to only apply during SslBump 
step1 it has to have an "SslBump1" ACL name. For example, the following 
rule allows any(*) fake CONNECT request during SslBump step1:

     # Allow all fake CONNECTs on intercepted connections until
     # we have a chance to extract TLS SNI information (step2).
     http_access allow step1 https_port


(*) any request that was not denied by earlier rules, of course


> Also, to begin with, these settings follow the existing squid proxy
> created by my predecessor, so I don't know what they are for...
> What are the disadvantages of removing these settings?

If you remove all ssl_bump rules, then Squid will not examine traffic 
inside intercepted TCP/TLS connections. Thus, TLS clients will be able 
to request/do anything (if their intercepted TCP connections are allowed 
using TCP-level information). Whether that effect is a "disadvantage" is 
your call.


HTH,

Alex.