Re: SSL proxy info

[Adam Shostack <adam () homeport org>]

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