On Wed, Sep 14, 2005 at 09:29:04AM +0200, Johan Nilsson wrote:
Hi,
Just a quick comment:
Isn't this the definition of a Man-In-The-Middle-attack? You will have
problems with how the certificate is handled....
In my world, wouldn't it be better to default deny SSL-connections, and
only open for certain, trusted sites? If this is a concern on a company
basis, then wouldn't it be better to manage this by policy, than by
technical solutions? You will have the same problem if you allow other
SSL'ed protocols, such as IMAPS or POP3S....
To my experiance, if you deny the users someting, they'll find a way to
circumvent this, and do stuff in a even more unsecure way. Therefore, I
believe that it's better to allow in a controlled way, than deny, and
get the traffic thru a "back-door" somewhere.
Just my 2 cent.....
Brgds
Johan Nilsson
Senior Systems- and network administrator
AXIS Communications
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
I think you have a decent point Gregory. However, once you start
blocking access based on destination domain/IP, you inevitably end up
not allowing someone access to their mail via some unknown site or
someone to securely purchase something on a website. If this is the
company policy, so be it. But from the looks of the previous discussion,
it would appear that connections to the internet are allowed, wherever
the destination may be, so long as it's a website. That's what an SSL'd
web proxy does, of course. You're right though, there are certification
problems in having the proxy require the certs of all the clients using
the proxy (if that's how the client's browsers are set up). Anywho, it
seems to be a matter of necessity. I would personally only allow access
to specific sites, but that seems limiting. There's got to be a way
around this that we aren't thinking of
Sean Williams
