Re: SSL proxy info

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

On Fri, 19 Sep 1997, Adam Shostack wrote:

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

No, I'm not better off.  I won't pass SSH through my firewall, and our 
e-mail system is a proprietary bird that doesn't fly well with 
automated encryption like PGP.

I don't have a problem with users manually encrypting data.  I do have a 
problem with things which can programatically become tunnels into and out 
of my network.  MITM-able encryption is something I would allow, since it 
gives me an available audit point, analysis of the traffic, etc.

Excessive e-mail volumes _from_ a user is a pretty solid audit point at 
the moment, when looking for tunnels.  Excessive Web traffic another, but 
again, inspection of the traffic is possible.  Excessive encrypted 
traffic doesn't give me any level of assurance that I can detect a tunnel.

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

Then I can state categoricly that there are several thousand people who 
won't be able to use the solution.  Probably a lot more than that, but 
definitely that many.  

I'm unsure why adding proxy support should derail non-proxy support, as the addtion of
a protcol extension should be the most that is necessary to the current specs.  

Something like:  

if (client-says-tunneled) 
    {
     do server detects tunnel stuff;
     set tunnel-flag= client++;
    }

if (server-says-tunneled)
    {
     do client detects tunnel stuff;
     set tunnel-flag= server++;
    }

if (client != client.old | server != server.old)
   {
    do yet another tunnel;
   }

Then worry about implementation specifics, and proxy support in a 
sub-group, in parallel with the primary effort.


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