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
