Firewall Wizards mailing list archives
Re: SSL proxy info
From: Adam Shostack <adam () homeport org>
Date: 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 | proberts () clark 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
Current thread:
- SSL proxy info Paul D. Robertson (Sep 18)
- Re: SSL proxy info Adam Shostack (Sep 19)
- Re: SSL proxy info Paul D. Robertson (Sep 19)
- Re: SSL proxy info Adam Shostack (Sep 19)
- Re: SSL proxy info Paul D. Robertson (Sep 20)
- Re: SSL proxy info Adam Shostack (Sep 20)
- Re: SSL proxy info Paul D. Robertson (Sep 20)
- Re: SSL proxy info Paul D. Robertson (Sep 19)
- Re: SSL proxy info Adam Shostack (Sep 19)