[squid-users] Validation of IP address for SSL spliced connections

[Amos Jeffries]

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