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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
