OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: SSL proxy info

Re: SSL proxy info

Adam Shostack (adamhomeport.org)
Thu, 18 Sep 1997 21:46:24 -0400 (EDT)

        I think a cryptographic MITM approach is a generally good one,
for high value traffic. There are two problems with a MITM proxy,
which we need to be aware of. The first is performace. A Sparc 20
can handle about 15-20 SSL negotiations in a second. If you need to
do two per connection (inside and outside), your proxy has no time to
do anything but negotiate at 10 SSL requests per second. The second
is that your SSL proxy just became a fat target, whose comprimise
gives an attacker an awful lot of interesting data. Its not clear to
me what criteria to use for deciding if a MITM is worthwhile.

        An alternative would be to re-write the TLS spec (TLS2?) to
allow confidentiality and authenticity keys to be seperately
negotiated, so that the proxy can partake in the confidentiality
negotiation, but the authentication is kept out of his hands. This is
not a trivial engineering task, and I suspect that there will need to
be several revs, as this is a complex three party negotiation, which
will be easy to bollux up.

        Are there disadvantages to using DH instead of RSA?

Adam

Paul D. Robertson wrote:
| I was just wondering if anyone had a consensus of SSL proxy capabilities
| from a firewall perspective. There seem to be three general schemes, the
| first is to just pass the encrypted transport straight through, which
| ensures the user's privacy, but not the site's security. The second is
| one which allows the HTTP headers to be examined, but not the data, which
| in my mind seems almost as bad security-wise as the first, though at least
| you can check site names, and do connection policy enforcement somewhat.
| The last is to get a proxy with specific support for what ammounts to a
| MITM attack on the crypto, and allows complete inspection of the packet
| contents prior to re-encryption. At the moment I'm strongly favoring the
| last, as I don't think that from a business perspective, there's a good
| deal of argument for not being able to inspect packets, but I was
| wondering if anyone else had specific thoughts on the issues, and
| generally available implementations. Patent-wise, given the expiration
| of Diffie-Hellman (6 Sep), and the pending expiration of Hellman-Merkle
| (6 Oct), freely available SSL with V3.0 (D-H, SHA, DES) is now a
| possibility in the US (for as long as the government stays away), and I
| see this as an important change.
|
| Paul
| -----------------------------------------------------------------------------
| Paul D. Robertson "My statements in this message are personal opinions
| probertsclark.net which may have no basis whatsoever in fact."
| PSB#9280
|
|
|
| 

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:08:57 CDT