[squid-users] Host header forgery detected after upgrade from 3.5.8 to 3.5.9

[Alex Rousskov]

On 10/29/2015 11:29 AM, Matus UHLAR - fantomas wrote:
>> On 10/28/2015 10:46 PM, Amos Jeffries wrote:
>>> NP: these problems do not exist for forward proxies. Only for traffic
>>> hijacking interceptor proxies.
> 
> On 29.10.15 09:05, Alex Rousskov wrote:
>> For intercepted connections, Squid should, with an admin permission,
>> connect to the intended IP address without validating whether that IP
>> address matches the domain name (and without any side effects of such
>> validation). In interception mode, the proxy should be as "invisible"
>> (or as "invasive") as the admin wants it to be IMO -- all validations
>> and protections should be optional. We could still enable them by
>> default, of course.
>>
>> SslBumped CONNECT-to-IP tunnels are essentially intercepted connections
>> as well, even if they are using forwarding (not intercepting) http_ports.

> the "admin permission" is the key qestion here.  

Agreed. And understanding of what giving that permission implies!


> There's possible problem
> where the malicious client can connect to malicious server, ask for any
> server name and the malicious content could get cached by squid as a proper
> response.

Very true, provided that Squid trusts the unverified domain name to do
caching. Squid does not have to do that. As Amos have noted, there are
smart ways to minimize most of these problems, but they require more
development work.

IMHO, it is important to establish the "do no harm" principle first and
then use that to guide our development efforts. Unfortunately, some of
the validation code was introduced under different principles, and we
may still be debating what "harm" really means in this context while
adjusting that code to meet varying admin needs.

Alex.