Re: [PATCH] host_verify_loose option

On 22/01/2012 11:34 a.m., Henrik Nordström wrote:
> sön 2012-01-22 klockan 00:41 +1300 skrev Amos Jeffries:
>
>> It adds a host_verify_loose directive which allows requests which fail
>> Host: validation to continue through processing. The default is OFF for
>> now to encourage safety. Enabling this does open the clients to some
>> minor aspects of same-origin bypass again. BUT ...
>>
>> * blocks caching on the response to protect all other network clients
>> against one compromised client spreading infections.
>>
>> * forces the original (untrusted) destination IP to be used instead of
>> any alternative Squid might find. Preventing Squid or peer DNS lookup
>> being the point of vulnerability for the same-origin bypass. For any
>> client to be vulnerable it must be vulnerable inside the browser agent
>> where the original TCP connection is established.
> I would say it should be on by default, or actually the directive should
> be named host_verify_strict and off by default.
>
> As you note for a client to be vulnerable with this on the client needs
> to be vulnerable when used with direct connection without having it's
> connections intercepted by Squid.
>
> Having this Host validation enabled breaks valid traffic, something
> which we MUST NOT do in default configuration.
>
>> It also adds a new error template ERR_CONFLICT_HOST to replace the
>> confusing invalid request message with a clear explanation of the
>> problem and some client workarounds.
>>
>>
>> FUTURE WORK:
>> adapt processing to allow these requests to safely be passed to peers.
>> adapt caching to permit safe sharing between clients making identical
>> requests to same sources.
> Short term, add a flag which by default prevents these from being passed
> to peers to avoid opening up the original CVE issue when intercepting
> and then forwarding to some peers.

We have the forward.cc start() logics for dst-passthru decision to
prevent peers being looked up right now, so they wont even be an option
if the verify fails.

This version updates the hierarchical flag and cacheHierarchical()
function to fix any other code paths which use them to see if a peer is
likely. That will be reverted when the peer relay is done.

>
> Mid term, implement tunneling over peers using CONNECT. Keep in mind
> that this requires changes in pconn state to track tunnels separately
> from normal peer connections.

That is still TODO. I'd like to get this version with initial loosening
rolled out since it fixes the more commons cases quickly.

>
> Long term, a better forwarding mechanism to allow the peer to see the
> traffic proper and avoid the tunnel. Needs to be enabled in cache_peer
> or some discovery mechanism added (OPTIONS * ?). Here I still vote for
> original IP in requested URL and Host header preserved as discussed
> before as it degrades in a safe manner no matter how wrongly things gets
> configured.
>
> Regards
> Henrik
>