Hi,
On 5/29/24 11:31 PM, Alex Rousskov wrote:
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:
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 https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery,
it always seems to mention the Host header. It has no mention of
performing the same checks for the SNI value. Since we're peeking at the
request, we can't see the actual Host header being sent.
And indeed: if I perform the same test for HTTP traffic, I do see the
error message:
curl http://wordpress.org --connect-to wordpress.org:80:8.8.8.8:80
I believe that for my use-case (only splice certain domains and prevent
connecting to a wrong IP address), there's currently no solution then.
Squid would also have to perform a similar check as the Host check for
the SNI information. Maybe I can perform the same function with an
external acl as you've mentioned. I will look into that later. Thanks
for your time.
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.
I've updated the configuration to use stare/bump instead. The field is
then indeed added to the log file. A curl request that forces the
connection to a different IP address then also fails because the
certificate isn't valid for the name. There's no mention of the Host
header not matching the IP address, but I assume that check comes after
the certificate check then.
Regards,
Rik
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
