Firewall Wizards mailing list archives
Re: SSL proxy info
From: "Paul D. Robertson" <proberts () clark net>
Date: Sat, 20 Sep 1997 18:16:25 -0400 (EDT)
On Sat, 20 Sep 1997, Adam Shostack wrote:
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?
I'm looking at that issue right now. I'd rather just have the proxy MITM the SSL, it's much cleaner overall, and easier to support.
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
Pretty much, the proxy server handles DNS requests, one of the advantages of non-transparent proxies is that the client need never resolve external addresses. Since I control the proxy, no clients get external name resolution answers directly or indirectly.
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.
In a secure data environment, that's an issue. In an environment where one simply wants to do as much as possible to stop someone from tunneling in to attack hosts and services, the issue of everything over HTTP is something which is _slightly_ more managable, not pretty, not easily, but doable to a level where I can sleep at night, even if fitfully.
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.
Nor is it to me, which is why I posed the questions and follow-ups here. I _think_ it's solvable, but I'd like to know that. I don't have a problem with calling Winn and trying to slide into things, I'd just like to feel it's worth attempting.
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)
That's why the pseudo-code had tunnel counters, not just flags, I thought about that pseudo-code for 4 or 5 minutes before I wrote it.
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.
Implementation is always the hard part, that's why I do strategy ;)
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.
Just once, I'd like to see true proxy support in a cryptographic protocol, where at the administrator's option, and with notification of each end, it would be possible to enforce a security policy. If there's something that we, as a collective group, can do to further that, then I think it's a good thing. But then again, if I'm the only one who has these concerns, it's not worth the battle. Watching all these folks allow IP protocol 47 in at will for PPTP, along with 24x7 cable modem access to the Net makes me think that we'll see a great deal more tunneling activity in attacks. If we don't speak now, we'll be the ones doing clean-up from attacks at our sites, not the protocol developers. If I can get some sort of feeling (privately, the list doesn't need cluttered) of who's interested in such a thing, as well as some public disucussion on these issues (VPNs are coming, we as an industry need to be aware of the issues - unless Marcus objects to this list being used to discuss such things, I'd rather we hashed it all out now) [This space left blank for moderator's note] If there's sufficient interest, I can set up a side list for the discussion if we stray too much, or the volume gets too bad. Opinions on such should also be directed to my address. I'd rather we, as firewallers, could reach a pseudo-consensus and move it forward now, even if it's slated for a future version, than have us come in on the back end and only get lip service a la the CONNECT headers. 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
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)