Re: SSL proxy info

["Paul D. Robertson" <proberts () clark net>]

On Thu, 18 Sep 1997, Adam Shostack wrote:

>       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

Very good point.  I hadn't thought of that part of it.  I guess it's time 
to see how well the SSL stuff scales to SMP and how high-end processors 
handle it.

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

The way I see it, the proxy is a big fat target _anyway_.  If that 
machine isn't done right, I lose.  If it isn't administered correctly, I 
lose.  

I'm seriously considering the value of a trusted system approach to SSL 
proxying anyway, so I really need to find out if the vendor will allow 
programatic access to the data stream for analysis or monitoring during audit 
events using a role which is useful for only that (Which gives me a strong 
audit point, and misuse prevention/detection.)  I think I've convinced them 
that even should they support the "clear headers, encrypted data" option 
(CONNECT extension), that access to a MITM version is important for those of 
us who aren't fond of allowing uninspectable tunnels in and out of our networks.

With the ability to serve multiple domains from a single machine, and serve
multiple IP addresses on an interface, as well as public proxies, I'm not 
sure that header logging is as much of a security blanket as it is a 
placebo in attempting to detect intrusion via tunneling.

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

The main problem, as I see it, is the lack of ability to announce MITM 
by protocol, or to the user.  I'd like the option of notifying the user that
the transmission isn't private (ECPA concerns mostly), and I'd like the 
ability, as a server operator, to know that my data has a possible point 
of compromise before it gets to the user.  Is anyone on the list working 
on the IETF TLS committee?  I'd really like to take this discussion off-line 
and try to come up with something workable that would be possible to garner 
support for and start hitting the IETF TLS folks for interest.

>       Are there disadvantages to using DH instead of RSA?

Not that I can see.  It's only the key exchange protocol, and allows 
anonymous key exchange without certificates.  With SSL3, you 
get, if implemented, dynamic key renegotiation in stream, at any time, 
from either side, if you don't trust the key exchange mechanism for long 
periods of time, but I'd use that with either exchange protocol.  Lastly, 
from the SSL-Talk FAQ: "Ephemeral DH allows you to use signing-only 
certificates, and it protects the session from future compromise of the 
server's private key."

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