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

Adam Shostack (adamhomeport.org)
Sat, 20 Sep 1997 17:16:20 -0400 (EDT)

Paul D. Robertson wrote:
| On Fri, 19 Sep 1997, Adam Shostack wrote:
|
| > | > is that your SSL proxy just became a fat target, whose comprimise
| > | The way I see it, the proxy is a big fat target _anyway_. If that

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

        In that case, can you use a proxy that will do SSL to the
outside, and throw up a notice to your user that its cleartext on the
lan?

        As a general design issue, I think firewalls are becoming less
useful as most things users do run over HTTP; they are still useful in
that they protect all those other problems, but the desktop security
problem looms large.

        Also, do you proxy DNS? The latest phrack has a tool to
tunnel a connection over DNS packets. I expect that you've thought
about the issue, but I'll point out in a general way that going to
these lengths on your net connection may be not worthwhile if your
users can carry data out in their attache cases or on a DAT tape.

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

        The issue is that tunnel support is something that I might
play with in a cryptographic level. Its not obvious to me that having
the hook per se in the protocol is free of problems.

        For example, if we can chain proxies, perhaps I have an attack
where the proxy chain is long enough that the user only sees the right
parts of it. A real URL that the Ed Felton had set up was like:
(www.microsoft.com.cs.research.princeton.edu/updates/hotfix2.exe)

        Your pseudo-code example is clean, these things tend to pop
out in subtle ways when code is being written. There are also issues
when adding back compatibility to a protocol (see Wagner & Schneier on
SSL3, on www.counterpane.com); avoiding rollback attacks is *really*
tough.

        Its unfortunate that we can't pull out a standard protocol
that has clean support for this sort of thing, because I agree with
you that it would be damn useful.

Adam 

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

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