On 2024-05-29 17:06, Rik Theys wrote:
On 5/29/24 5:29 PM, Alex Rousskov wrote:
On 2024-05-29 05:01, Rik Theys wrote:
acl allowed_clients src "/etc/squid/allowed_clients"
acl allowed_domains dstdomain "/etc/squid/allowed_domains"
http_access allow allowed_clients allowed_domains
http_access allow allowed_clients CONNECT
http_access deny all
Please note that the second http_access rule in the above
configuration allows CONNECT tunnels to prohibited domains (i.e.
domains that do not match allowed_domains). Consider restricting your
"allow...CONNECT" rule to step1. For example:
http_access allow allowed_clients step1 CONNECT
Thanks, I've updated my configuration.
Please do test any suggested changes. There are too many variables here
for me to guarantee that a particular set of http_access and ssl_bump
rules works as expected.
squid doesn't seem to validate that the IP address we're connecting
to is valid for the specified name in the SNI header?
That observation matches my reading of Squid Host header forgery
detection code which says "we do not yet handle CONNECT tunnels well,
so ignore for them". To validate that theory, use "debug_options
ALL,3" and look for "SECURITY ALERT: Host header forgery detected"
messages in cache.log.
I've enabled this debug option, but I never see the security alert in
the logs. Maybe it was introduced in more recent versions? I'm currently
using Squid 5.5 that comes with Rocky Linux 9.4.
The code logging "SECURITY ALERT: Host header forgery detected" messages
is present in v5.5, but perhaps it is not triggered in that version (or
even in modern/supported Squids) when I expect it to be triggered.
Unfortunately, there are too many variables for me to predict what
exactly went wrong in your particular test case without doing a lot more
work (and I cannot volunteer to do that work right now).
Looking at the logs, I'm also having problems determining where each
ssl-bump step is started.
Yes, it is a known problem (even for developers). There are also bugs
related to step boundaries.
Peeking at the server certificates happens at step3. In many modern
use cases, server certificates are encrypted, so a _peeking_ Squid
cannot see them. To validate, Squid has to bump the tunnel (supported
today but problematic for other reasons) or be enhanced to use
out-of-band validation tricks (that come with their own set of problems).
I guess that explains why if I add "%ssl::<cert_subject" to my logformat
for the access log, the field is always "-"?
It may explain that, but other problems may lead to the same "no
certificate" result as well, of course. You can kind of check by using
stare/bump instead of peek/splice -- if you see certificate details
logged in that bumping test, then it is more likely that Squid just does
not get a plain text certificate in peeking configurations.
Is there a way to configure squid to validate that the server
certificate is valid for the host specified in the SNI header?
IIRC, that validation happens automatically in modern Squid versions
when Squid receives an (unencrypted) server certificate.
Do you happen to known which version of Squid introduced that check?
IIRC, Squid v5.5 has that code.
HTH,
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
