Re: SSL proxy info

[Adam Shostack <adam () homeport org>]

Paul D. Robertson wrote:
| On Thu, 18 Sep 1997, Adam Shostack wrote:
| 
| > 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

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

        NCipher makes some very nice scsi accelerator boxes to deal
with this.  www.ncipher.com.

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

        Yes, but!

        First, most of the connections through a proxy are not
encrypted.  If they are, I'll assume they hit one of three encryption
standards, PGP, SSH, or SSL.  If its PGP encrypted mail, it will
probably pass through your proxy fine.  If its SSH, most people pass
it with no decryption.  Now you're proposing handling SSL differently,
and I ask, what for?  How should I decide to decrypt on the proxy or
not?  Do the extant HTTP proxies really add enough value that you're
gaining much by using one?  Are you better of with Netsscape's
Adminsuite, to distribute security to your desktops?

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

        I think we should not get this into TLS now.  TLS is having a
lot of trouble getting out the door because of patent issues.  Adding
a new requirement today for proxy support would add a year to
deployment.

Adam

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