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 CorporationReceived on Thu Aug 05 2004 - 09:10:21 MDT
This archive was generated by hypermail pre-2.1.9 : Wed Sep 01 2004 - 12:00:01 MDT