Re: SSL Web Proxy is a Double Edged Sword

Mervyn is 100 percent right :)) That's
the way the microdasys perform. You then can control what certificates
are valid, all expired or revoked certificates are not allowed and so on.

I agree with you  that port 443
is major security risk. We allready noticed some interesting use for that
port by the outsiders - that's why we are controling this :))

Don't know about your company policy,
but it might be achieved  ( in my opinion ) - something like this
- everything what an employee does in its work place should be related
only to his job and cannot be related to anything personal. This way there
should't be any personal information involved. Your company policy then
should state that everything could be monitored and so on. 



Best regards
__________________________________________________________
The opinion expressed in this communication is my own, 
and do not necessarily reflect those of my employer.

Bank of Lithuania
Darius Povilaitis

Mervyn Heng <barcajax@gmail.com> 2005.09.14 04:01 Please respond to barcajax

To:        "integral@integral.homelinux.net" <integral@integral.homelinux.net>         cc:        firewalls@securityfocus.com         Subject:        Re: SSL Web Proxy is a Double Edged Sword

What I know about SSL Proxies is that it validates the
certificate received from the SSL site and issues the client (ie. browser)
its own certificate. The implication of this is that the SSL Proxy establishes
a tunnel between itself and the SSL site and another between itself and
the end user's browser.

barcajax

On 9/12/05, integral@integral.homelinux.net
<
integral@integral.homelinux.net> wrote:
Sorry for the late question...I'm curious as to how www.microdasys.com
acheives their goal. Do they simply decrypt, scan data, re-encrypte,
then send to the orgin server? If so, this is a total gap in many
company policies. Also, how is this de/re-encryption performed? I 
thought only the sender and receiver could en/decrypt the packet
content. Thanks!

Sean

On Sun, Jul 24, 2005 at 10:04:17PM +0300, RemoveThisDPovilaitis@lb.lt
wrote:
> Hi,
>
> check out www.microdasys.com
for the solution. They terminate tunnel at
> the proxy and the proxy establishes second connection to the destination.
> In that way it is possible to control what is going through the SSL
> tunnel.
>
> Hope this helps
>
>
> Best regards
> __________________________________________________________ 
> The opinion expressed in this communication is my own,
> and do not necessarily reflect those of my employer.
>
> Bank of Lithuania
> Darius Povilaitis
>
>
>
>
> 
>
>
>
> Greg Jones <grjones@gmail.com>
> 07/21/05 12:29 AM
> Please respond to Greg Jones
>
>
>         To:     firewalls@securityfocus.com
>         cc:
>         Subject:        SSL
Web Proxy is a Double Edged Sword
>
> Greetings,
>
> I was thinking about this the other day and would like to hear any
> thoughts you may have.  Many businesses have a strict egress
> network/firewall configuration where the only allowed traffic is HTTP
> 80 and HTTPS 443 via a web proxy.
>
> What concerns me is the proxying of SSL.  Many think this is
super
> duper secure, saying "Since SSL encrypts, it must be good!"
 But if
> what you are trying to do is limit outbound connections from your
> employees, this is basically a wide open hole.  Here's how:
>
> - For the client (from work): Get the stunnel source from stunnel.org
> and apply the patch for SSL web proxying.  Compile.  This
works on 
> Unix, Linux, and Windows too.
> - For the server (home box): Configure stunnel to listen on port 443
> since many proxies only allow this port for SSL.  At first I
was going
> to tunnel the connection to telnet, but if you tunnel it to SSH then
> you have the benefit of using SSH tunneling (which even Putty can
do)
> so that you don't have to reconfigure your stunnel server every time
> you want to connect to something new.  So, it's a bit redundant
having 
> SSH over SSL, but it's worth it.
>
> Is there a way to prevent arbitrary data going over your SSL web
> proxy?  Here are some ideas:
>
> - Use various group policy and host-based security packages that 
> restrict which executables are allowed to run, with a default policy
> of deny. Also, some kind of network-level authentication should
> probably be implemented in a way that would not allow the user to
> bypass the exe security by simply reformatting their machine or using
> a live cd.
>
> - Or maybe better, after the SSL session key exchange takes place,
the
> browser could make a second connection via SSL to the proxy server,and
> transmit the session key allowing the proxy to see inside the SSL
> connection and verify that it is indeed HTTP and not arbitrary data..
>
> Comments?
>
> Thanks
>
> Gregory Jones 
>
>