[squid-users] A patch for intercepted/WCCP HTTPS and 409 errors

[Scott Aitken]

> 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
Thanks Amos,

I found 
https://www.thesecuritypractice.com/the_security_practice/TransparentProxyAbuse.pdf 
extremely useful.  Unfortunately the documentation around Squid's fix doesn't 
get into the side-effects in great detail.

The biggest side-effect is accessing non-malicious sites whose full list of A 
and AAAA records is incomplete.  This is becoming increasingly common 
especially given the preponderance of CDNs (and poor administration).

For a malicious client it's easy to circumvent Squid's fix (just don't send 
an SNI at all) - this applies to my network as I peek and splice (no MITM - 
so no HTTP headers).  But the main point of the CVE seems to be a general 
user visiting a malicious site.

My reading of the PDF is that Squid could have implemented an option to 
connect to the IP of the intercepted SYN rather than use the SNI/Host:, which 
wouldn't cause these annoying 409s.

That said, do you think the implementation of an acl of permitted dstdomains 
that aren't validated to be insecure?  I'd be happy to have a prescriptive 
list of domain names which are NOT to be verified but known to be broken from 
a DNS perspective.

eg:
acl safe_domains google.com
host_verify_strict !safe_domains

Scott