RE: [squid-users] Re: SSL Traffic Monitoring

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:michael.gale@utilitran.com]
Sent: Thursday, August 05, 2004 10:11 AM
To: squid-users@squid-cache.org
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 <hno@squid-cache.org> 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