[squid-users] TProxy and client_dst_passthru

[Amos Jeffries]

On 4/07/2015 3:21 a.m., Stakres wrote:
> Amos,
> OK, got your points.
> 
> What I don't understand is:
> - The dns records do not match. Squid does the dns request by itself,

Reverse those two.

> downloads the object,

... from the ORIGINAL_DST (*not* its own DNS lookup)

> delivers it to the client and flags with an
> ORIGINAL_DST, right ?
> - Same request from another client, same way, it'll be the same object and
> flagged ORIGINAL_DST too.
> - Again and again... each time the same fresh object...
> - Why do we repeat the same action if we deliver the same object each time ?
> it makes me crazy... 

Not the same object. Different ORIGINAL_DST. Thats what ORIGINAL_DST
means ... original client dst-IP.


> 
> Here, I mean by using "*client_dst_passthru off*" and "*host_verify_strict
> off*".
> I understand the "host_verify_strict on" must act as you explain, no
> problem.

host_verify_strict applies the DNS lookup tests on more traffic than
just intercepted. Also rejecting client requests instead of allowing
through to the original dst-IP.

> 
> Squid re-checks the DNS as there is an issue, downloads and delivers the
> object. If Squid delivers the object it should be able to cache it with the
> "*client_dst_passthru off*" and "*host_verify_strict off*".
> 
> I agree Squid must respect the CVE-2009-0801 but you/we should deal nicely
> with and not just applying it...
> 
> The right way should be:
> Squid think the object is OK to be delivered ?
> Yes: deliver it and cache it.
> No: block it and don't cache it.

That is "host_verify_strict on" behaviour.

Tried exactly that for most of the 3.2 beta series. With many complaints
about rejecting traffic. As you noted a good 20-30% of traffic fails the
verify. A lot of Google and Akamai hosted sites, some Facebook traffic.

So now we have the third alternative...
  No: allow through and dont cache it.

Which is "host_verify_strict off".


Amos