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
>>
>>
