I understand that administration headache ... but with the IE vulnerabilities would have me worried. Other then that SSL filtering would be nice.
Michael. On Thu, 5 Aug 2004 11:21:24 -0400 "McDonald, Rob" <[EMAIL PROTECTED]> wrote: > No..they don't need it. > > But that is not the point. As a company, we have to say we are conforming > all traffic that is allowed to HR policy. > > Now, if I say I allow outgoing 443, then I restrict access to only the https > sites we allow for the 30,000+ users worldwide...well now, the maintenance > is a headache. > > If I were allowed to filter the traffic inside of the SSL encryption..then I > could filter out unwanted viruses, content, and sites via another easier to > manage package like DansGuardian. > > Rob > > -----Original Message----- > From: Michael Gale [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 05, 2004 10:11 AM > To: [EMAIL PROTECTED] > Subject: Re: [squid-users] Re: SSL Traffic Monitoring > > Hello, > > It seems to me we are going about this the wrong way. Most people > want to filter HTTPS traffic to add more security to > the network. > > An example was given with regards to web mail ?? -- so you are setting up > squid to use a fake CA ? > > So to filter hotmail attachment for viruses to secure the network you create > a fake CA for all HTTPS request and tell > every browser to trust this CA. > > You have just screwed over all HTTPS security -- with all the IE bugs with > regards to redirection, fake urls in the > address bar and everything. > > You have just made it 100 times easier for a hacker to exploit credit card > information and banking information from all > of your internal employees I would think. > > Unless you are having squid verify ever certificate plus the url it is > displaying to the client and so on. > > We you think about it if you want to make the network secure why allow > hotmail access ? Do they need it for work ?? I > would think not. > > Michael. > > > > > > > On Thu, 5 Aug 2004 14:14:31 +0200 (CEST) > Henrik Nordstrom <[EMAIL PROTECTED]> wrote: > > > On Thu, 5 Aug 2004, Peter Arnold wrote: > > > > >> Technically it is possible to implement a decrypting proxy using > spoofed > > >> server certificates issued by the proxy, but this has not > > >> yet been implemented in Squid. The technical drawbacks from doing this > is > > > > > > Is this the case even with the ssl patch for squid 2.5? I've been trying > to > > > get something to work for a while now but haven't been able to nut it > out. I > > > was thinking it might work to reverse proxy and sslproxy a list of known > ssl > > > email sites but I've not been able to find much info on this particular > > > scenario..... now I know why. > > > > The SSL update patch for 2.5 adds better SSL server functionality, and the > > > ability to connect to https:// sites. There is still several pieces of > > missing to make the requested functionality. > > > > You may have some limited success in a transparent proxy environment > > redirecting port 443 to an https_port of Squid-3.0, but clients will > > complain loudly about the certificate not being valid/correct. > > > > >> - End-to-end is violated, making it impossible to use/access sites > > >> requiring client side SSL certificates for authentication. > > > > > > Could squid be configured to ACL what does and doesn't get > > > decrypted/encrypted? > > > > In theory yes, and quite likely would get done in such manner when the > > feature of decrypting proxied https straffic is implemented. > > > > Note: This technology can only be made to work reasonably in a proxied > > environment. Transparent interception of port 443 won't work good. > > > > > > > > What is missing from Squid-3 is > > > > - Ability to intercept CONNECT request and transform them into an SSL > > request as if the request had arrived on an https_port. > > > > - A faked CA generating temporary certificates for the requested host > > names to make clients happy. All clients must be configured to trust this > > CA. > > > > - An interface of Squid where it asks and caches server certificates > > from the faked CA as needed. This CA may eventually be built-in to Squid > > but should start it's life as an external helper. > > > > Regards > > Henrik > > > > > > > > > > > -- > Michael Gale > Network Administrator > Utilitran Corporation > > > > -- Michael Gale Network Administrator Utilitran Corporation
