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

[Dan Charlesworth]

Thanks for the perspective on this, folks.

Going back to the technical stuff—and this isn’t really a squid thing—but is there any way I can minimise this using my DNS server? 

Can I force my local DNS to only ever return 1 address from the pool on a hostname I’m having trouble with?

> On 30 Oct 2015, at 4:50 AM, Alex Rousskov <rousskov at measurement-factory.com> wrote:
> 
> 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.
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users