Firewall Wizards mailing list archives
Re: HTTP in practice
From: "Paul D. Robertson" <proberts () clark net>
Date: Mon, 29 Sep 1997 00:42:57 -0400 (EDT)
On Wed, 24 Sep 1997, Greg Haverkamp wrote:
Ah, yes. In a similar vain, I never saw the answer in Paul Robertson's SSL (HTTP) Proxy thread the other day. Is anyone actually doing the MITM approach?
Netscape's proxy supports it, and I'm attempting to get answers from other vendors. In the 'trusted computing' (or rather under evaluation thereof) arena, BDM hopefully has it on their list for Cybershield's SSL v3 proxy as of my last conversation.
I was speaking with a vendor of another product the other day who relies upon Java applets to be downloaded. Their answer to the filtering problem was SSL, which would equally apply to my solution. However, I just assumed the MITM method was being used when firewall vendors speak of SSL proxies. Further (albeit, cursory) investigation led me to the opposite conclusion.
It's been high on my list of questions recently, and I have a tentative "yes" from a couple of other vendors, but I haven't ensured that they're not just doing the "connect" thing, once I get the test boxes in, it'll be readily apparent after the sniffer is fired up though.
However, if most don't handle that, and assuming that most firewall administrators can't get away with not allowing https access to the outside (which seems a fair assumption to me), all of these issues become somewhat moot. Executable content can then only be controlled via control of the desktop. And that's pretty damn elusive.
I've yet to succumb to the pressure of allowing SSL (Multi-billion dollar corp, with thousands of screaming users). I won't allow it without being able to MITM it and then it will be HTTP over SSL only. That makes it just like HTTP, which I already allow somewhat. Marketing-wise, non-MITM proxies are easily exportable, so that's a barrier that I didn't think of until recently.
Well, that's the trick, isn't it? I've even been forced to make concessions for those things that are not even necessarily cool or useful. And that's disturbing (from the firewall administration perspective.)
I'm not of the mind to make concessions to the even useful if it's proprietary, and an unknown, undocumented protocol. I tell the vendors that if they want folks to use it, then do a valid Web implementation unless it's absolutely, positively impossible.
I find myself continually pushing back to the political realms of all of this. We have to make the right people want the product. Compounding our
I turn down division presidents, and VPs, I'm not particularly interested in who wants a product or service. Without a damn good business reason, and a good protocol, client and server evaluation, it's not going to happen at my site. If it goes further than that, then it won't be my site anymore. I've yet to see a vendor willing to post a bond against intrusion over their protocol, and/or from their site. Got that much faith in your ability not to compromise my site's security? Put up a bond for $100M, and find someone with a business reason to do whatever it is, and I'll start thinking of opening holes in my perimeter. I'm not comfortable with the number of holes I already have, and I'm the guy who has to sleep at night. My job is about protecting my corporation from harm, not currying political favor, or allowing vendors to sell their wares, education programs, data formats or information. I'm not convinced that 90% of the MIME/ActiveX/Java stuff couldn't be done in CGI anyway. I could make up a protocol every day for a year. I could even write silly little programs to use them. I'm unsure how that relates, in the minds of most vendors to everyone happily opening up holes in their firewalls. Really, I just don't get it. *Now* I have to figure out how to block RealAudio over HTTP *sigh* </vendor rant> 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:
- HTTP in practice Greg Haverkamp (Sep 22)
- Re: HTTP in practice Marcus J. Ranum (Sep 22)
- Re: HTTP in practice Greg Haverkamp (Sep 23)
- Re: HTTP in practice Marcus J. Ranum (Sep 23)
- Re: HTTP in practice Greg Haverkamp (Sep 24)
- Re: HTTP in practice Bennett Todd (Sep 24)
- Re: HTTP in practice Paul D. Robertson (Sep 29)
- Re: HTTP in practice Joe Klemmer (Sep 26)
- Re: HTTP in practice Greg Haverkamp (Sep 23)
- Re: HTTP in practice Marcus J. Ranum (Sep 22)
- <Possible follow-ups>
- Re: HTTP in practice Anton J Aylward (Sep 24)