Firewall Wizards mailing list archives
Re: SSL proxy info
From: Adam Shostack <adam () homeport org>
Date: 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
Current thread:
- SSL proxy info Paul D. Robertson (Sep 18)
- Re: SSL proxy info Adam Shostack (Sep 19)
- Re: SSL proxy info Paul D. Robertson (Sep 19)
- Re: SSL proxy info Adam Shostack (Sep 19)
- Re: SSL proxy info Paul D. Robertson (Sep 20)
- Re: SSL proxy info Adam Shostack (Sep 20)
- Re: SSL proxy info Paul D. Robertson (Sep 20)
- Re: SSL proxy info Paul D. Robertson (Sep 19)
- Re: SSL proxy info Adam Shostack (Sep 19)