RE: SSL

["Ames, Neil" <NAmes () anteon com>]

I am baffled by how a proxy would handle the SSL exchange.  Aside from all
other issues related to this thread-such as defenses at the client, or the
break in end-to-end encryption--what is right or wrong with the following?

1) A user hits an SSL site with a cert (that the user's browser may or may
not trust, and the firewall's proxy may or may not trust).  
2) The proxy lets the user determine that the proxy is going to trust the
cert, according to some policy rule that allows that.
3) Proxy manages, somehow, to act as intermediary.  (This is what I don't
get.)
4) The proxy sets up the SSL tunnel with the remote site.
5) The proxy sets up the SSL tunnel with the users browser.
6) The proxy checks everything as it hands pieces of the user-Web site
exchange, filtering according to policy.

What am I missing, particularly in how steps 3 and 5 would work?

Thank you,

Fritz Ames


-----Original Message-----
From: Scott, Richard [mailto:Richard.Scott () BestBuy com]
Sent: Wednesday, October 17, 2001 2:20 PM
To: 'Crumrine, Gary L'; firewall-wizards () nfr com
Subject: RE: [fw-wiz] SSL


<snip>
        Just a quick question on SSL.  If I allow SSL outbound, and a user
browses a web site that is corrupt with something harmful like NIMDA, is it
possible that they will infect my network... and will the firewall not pass
it along without checking?

        If true, how can I combat this?  Is there a product that will stop
the packets and inspect them before being returned to the requester?
<!snip>

Gary,

It all depends on what measures are in place and the injection vector used
in contaminate your network.  SSL, like most tunnels protects from man in
the middle attacks.  What ever data is passed through the tunnel, travels
through it from one end to the other.  Simply using SSL as a mechanism does
not prevent infections from hostile web code.  SSL prevents the vector of
attack performed by sniffing the data.

In the instance of Nimda, one would have to look at the injection vector,
the method of attack.  Let's assume that it was a single vector, the
malicious java script code and one is trying to protect the user (client
side).  This can be prevented by two popular mechanisms.  1) educating users
to switch of Javascripting in a browser or 2) Firewall packet inspection.
There are other methods, but assuming that you do not want the code to
excute (rather than exploit a bug), these mechanisms would be used.  There
are politics to each mechanism, and there are better protection mechanisms
using signatures that are available.

So to answer you question, you can do packet inspection (processing could be
very high), you can do SSL, you can educate users.  A good security policy
would involve many methods and the reason is simple.  Multi-pronged attacks
that Nimda has. infected systems from servers to clients using different
vectors.  Using just one mechanism would not have prevented your system
getting infected (of course, you could have been on a Unix platform, the
only single mechanism that would have combated it).

readinteh archives in this mailing list you can have a sense of what the
professionals are considering... if you want to do packet inspection on SSL,
you may need to proxy the SSL data to be able to inspect it.

BTW - Does anyone have any pointers to be able to SSL packet inspection on
the data?


Cheers
r.
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards