On 12/12/19 1:49 am, Scott wrote: >> On 11/12/19 8:51 pm, Scott wrote: >>> Hi, >>> >>> I understand that squid does some security checking that the SNI of an >>> intercepted/WCCP HTTPS requests matches the reverse DNS of the IP of the >>> connection. Or something like that. >> >> Not being able to say precisely what Squid is actually doing shows that >> you are lacking understanding of the processes taking place. >> >> The security check you are posting about has many secondary consequences >> and side effects to be taken into account. Quite a few people have taken >> a stab at solving these rejections and what we have in Squid right now >> is the best that can be done without significant redesign work (which is >> underway - just very slowly, help welcome). >> >> This is why we have the squid-dev mailing list for code change >> discussion. If you want to actually help solving false-positives in this >> security check please post there and we who have been working on this >> issue for 10+ years now can discuss what we know about the situation, >> the "gotcha" side effects we have to avoid and ideas for improvement. >> >> >>> >>> However with the prevalence of CDNs and badly configured DNSs and geographic >>> DNSs, this breaks lots of connections (eg, I can't watch the NHL). >>> >>> I run Squid on a trusted network and use it primarily for caching and >>> logging, and so I while I need to run WCCP for some non-proxy capable >>> devices, I don't need that security check. >> >> Without that check you cannot call your network a "secure network" >> anymore. The absence of the check opens a nest of security holes for >> attackers to walk right in past all those other protections. >> >> >>> >>> It stops all of those 409 errors occurring. >>> >>> Because of that I've created some patches that add a new option >>> "host_verify_strict_intercepted" which is off by default. They are >>> for Squid 4.9. As this is disabling a security feature of Squid do >>> not apply this patch unless you are prepared for any and all consequences. >>> >> >> Please do not spread this around. People who want to really insist on >> allowing virus/malware to spread unchecked around their networks can >> make smaller patches. >> >> Amos >> > Hi Amos, > > sorry for posting in the wrong forum. While you're here: I've seen a handful > of posts about the 409s and the response has been "security". Fair enough. > > Can you please provide a concrete example of > > a) why host_verify_strict is available as a toggle for non-intercepted > requests, and > b) why intercepted requests don't have this option at all? > a) Because the root vulnerability (CVE-2009-0801) which opens up the nest of effects has no external effect on non-intercepted HTTP syntax traffic. If you have a paranoid security policy or want to track down broken software it can be useful to validate everything. So its there, but off by default. b) While CVE-2009-0801 appears simply a Browser issue the other side effects that are possible include seeding the proxy cache with arbitrary content at arbitrary URLs, using that to spread infections, to exfiltrate data, and use that data to bypass other security mechanisms like the network border firewalls. The worst part is that the Squid access.log are also corrupted with false information from the Host header (and/or SNI in HTTPS) on the transactions where these things happen. So the attacker is hidden from admin and security forensics. That is going too far into unsafe territory IMO. Other useful reading: <http://www.squid-cache.org/Advisories/SQUID-2011_1.txt> <https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery> > I'm suffering from a lack of imagination and I've yet to see any example > given (and ok, I may have missed one somewhere) and would like one brought to > my (and other reader's) attention. > > Thanks, > Scott > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
