Re: HTTP in practice

[Greg Haverkamp <gregh () instinctive com>]

I appreciate all the responses I've received, both private and on the list.
 I didn't necessarily approach this knowing just what sort of answers I
hoped to receive.  But now perhaps I'll indulge a little more.

Marcus J. Ranum said (09:53 PM 9/22/97 +0000):
> > B) Based on the sketchy information, could I be missing other possible
> > sources of blockage?
>
> You *might* have a proxy that mangles your data even
> if it lets it through. Some proxies look for "bad URLs" and
> possible attack signatures -- and might choose to "fix"
> things, thereby making your life miserable.

Hmmm.  Any examples of what you'd consider one of these "bad URLs" to look
like?  We try to be pretty friendly URL-wise.

> > C) What sort of configurable options are likely be selected in A) or B)
> > that might allow more specificity to prevent impact?  (e.g., Traffic from
> > specific servers, etc.)
>
> I dunno. :( You could do something like encode your data
> in a "harmless" encoding that the firewall won't look into.
> The preceeding was a joke. <-------------
> Seriously, though, active content is *coming* and the
> firewall model isn't going to survive it unless firewall
> builders can come up with a better answer than "you
> can't do that!"

Uh.  Certainly not what I was implying.  Our encoding is pretty
straightforward, and much is plain text.  (Our sniffer can monitor eRoom
traffic just fine.)  We use HTTP to transfer both HTML and data.  The only
things encoded are the blocks of data that are transferred.  And, of
course, we thought we were being good citizens using application/x-eRoom
rather than, say, image/gif.

What I was really asking was more akin to: How often can exceptions be
expected in (for instance) proxy rules such that may allow <OBJECT> tags
from a particular host?  Or for that matter, are many commercial firewalls
configurable enough that I could specify specific GUIDs to allow?

(I know ActiveX is seen as a great evil.  In fact, I don't entirely
disagree, especially when it concerns downloading controls over the 'Net.
I'll just reiterate, we don't download ActiveX.  Our components are
pre-installed.  As such, we're basically in the same boat as any other
COM-based object on a Windows system.  For whatever benefit that may be
worth.)

> > D) On a survivability in hell scale, where 1 represents a snowball, and 10
> > represents Satan himself, where do things likely stand when it comes to
> > getting configuration changed? (Where, understandably, I am loathe to
> > change the settings on my firewall, to be sure.)
>
> I'd guess it's about 50/50 -- depends how COOL your
> application is!! I noticed a lot of folks "fixed" their
> firewalls for real audio pretty quick. It seems to me that
> these decisions become market-driven, not security
> driven. Which says something unclear but important
> about the state of security and the likelihood of a
> rosy future.

And this goes along with my question to some degree.  Do we face a greater
obstacle because we're browser- and web-server-based, rather than if we had
crafted our own server and protocol and released proxy code?  Or is it
roughly the same?  Basically, I reckon odds are slim we'll see the firewall
"fixed" to allow us to pass through <OBJECT> and <SCRIPT> tags, unless
there are some pretty precise specificity settings for that.

(None of this is to say I don't understand.  I responded an ardent "No" to
requests to make ICQ available recently, for instance.)

Ugh.

Greg