I agree my friend. Oh, I wish the world were text-based, and we never left
the console.
(insert usual M$ hate comment here).
Rob
-----Original Message-----
From: Michael Gale [mailto:michael.gale@utilitran.com]
Sent: Thursday, August 05, 2004 10:57 AM
To: squid-users@squid-cache.org
Subject: Re: [squid-users] Re: SSL Traffic Monitoring
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" <RMcDonald@dieboldes.com> 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: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
>
>
>
>
-- Michael Gale Network Administrator Utilitran CorporationReceived on Thu Aug 05 2004 - 10:11:03 MDT
This archive was generated by hypermail pre-2.1.9 : Wed Sep 01 2004 - 12:00:01 MDT