On Fri, 2008-04-25 at 09:26 -0400, Nick Duda wrote: > So are we saying that with WCCP in general all it can do as far as web > requests is port 80? And I would need to let 443 requests just go out > via the firewall...darn Not exactly. You have a few of options, depending on what you really need: - If you must look at HTTP-level details of HTTPS requests, you can redirect 443 traffic to Squid using WCCP and have Squid decrypt/encrypt traffic on the fly. Squid becomes a man-in-the-middle in this case and the browser will warn the user (correctly!) that the user may be under attack. The Squid feature required for this to work is called SslBump. It is available in Squid3 trunk and will be available in v3.1. - If you just want to do something based on TCP/IP-level of information, you can add a TCP-tunneling feature to Squid and use Squid ACLs that work at TCP/IP-level. This will not be a man-in-the-middle attack but you would not be able to check for things like viruses or information leaks. The following URL has hints on how to get new features added: http://wiki.squid-cache.org/SquidFaq/AboutSquid#HowToAddOrFix - If you just want to block traffic based on TCP/IP-level of information, your Cisco router (or other network device in the path) ACLs may be able to do some limited checks. HTH, Alex. > -----Original Message----- > From: Henrik Nordstrom [mailto:henrik@xxxxxxxxxxxxxxxxxxx] > Sent: Friday, April 25, 2008 2:05 AM > To: Nick Duda > Cc: Squid-users > Subject: Re: WCCP, Squid, ASA, HTTP redirect > > tor 2008-04-24 klockan 13:39 -0400 skrev Nick Duda: > > > I really cant imagine that all this WCCP with a web-cache can not work > > with HTTPS (that would suck) > > It's kind of due to HTTPS being fully encrypted and all that is seen on > the wire is random garbage... > > For HTTP Squid can decode the https request and understand what is going > on even when intercepted. HTTPS prevents this by nature of it's > encryption. > > Regards > Henrik
