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.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
