Re: HTTP in practice

["Paul D. Robertson" <proberts () clark net>]

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