On 30/05/24 18:30, Rik Theys wrote:
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.
FYI, The SSL-Bump feature uses a CONNECT tunnel at the HTTP layer to
transfer the HTTPS (or encrypted non-HTTPS) content through Squid. The
SNI value, cert altSubjectName, or raw-IP (whichever most-trusted is
available) received from peek/bump gets used as the Host header on that
internal CONNECT tunnel.
The Host header forgery check at HTTP layer is performed on that
HTTP-level CONNECT request regardless of whether a specific SNI-vs-IP
check was done by the TLS logic. Ideally both layers would do it, but
SSL-Bump permutations/complexity makes that hard.
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.
IIRC there is at least one SSL-Bump permutation which does server name
vs IP validation (in a way, not explicitly). But that particular code
path is not always taken and the SSL-Bump logic does not go out of its
way to lookup missing details. So likely you are just not encountering
the rare case that SNI gets verified.
HTH
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
