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_at_clark.net which may have no basis whatsoever in fact."
PSB#9280
Received on Sep 19 1997
Intro
