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<http://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.ltwrote:
Hi,
check out www.microdasys.com <http://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<http://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
