OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: SSL proxy info

Re: SSL proxy info

Paul D. Robertson (probertsclark.net)
Fri, 19 Sep 1997 20:54:44 -0400 (EDT)

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
probertsclark.net which may have no basis whatsoever in fact."
                                                                     PSB#9280

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:08:58 CDT