HTTP in practice

[Greg Haverkamp <gregh () instinctive com>]

Hello, all.

Having watched the firewalls mailing list for the last year or so, and
firewall-wizards for -- I guess -- the last week or so, I've developed a
good base of the feelings on the _theory_ of what people want to see in
firewall implementations and what they'd like to be using and doing.

However, as my company's product begins to head out the door, and we face
what appear to be firewall- (or proxy-) based problems, the questions I'm
being asked have made me wonder about what's actually happening "out there."

Here's some background, based on what I "can" say:
- Our product, eRoom, runs in a web browser on 95 or NT using pre-installed
(i.e., not run-time downloaded) ActiveX controls, JavaScript, and HTML.
- Some data passes as a custom application type, sent as Content-Type:
application/x-eRoom, from both POSTs and GETs.
- All communications are done via HTTP, speaking to a "standard" (IIS) HTTP
server.

I've been trying (sometimes successfully) to convey to the powers-that-be
over the last year or so that being transferred over HTTP is not a magic
bullet.  That we risk the following:
1) JavaScript being blocked at the firewall via removal of the <SCRIPT>
tags in the HTML.
2) ActiveX controls being blocked; in our case, via removal of <OBJECT> tags.
3) Content-Type: application/x-eRoom being blocked.

Now, given what I've read, I would expect 1) to be blocked fairly
regularly, possibly even on intranets.  I would expect ActiveX controls to
regularly be blocked; but would 2) be the method?  Or should I expect
blocking the be done via Content-Type?  Or perhaps a combination of both?
And, frankly, I don't know what to think of 3).  Generally, I would expect
a well-configured firewall  or proxy to block 3) until it's told otherwise.
 Is this off-base?

Unfortunately, the firewall I administer is not comprised of each of the
commercial packages that we may encounter.  I can only guess when
confronted with a new problem that appears the occur at the firewall/proxy
level.  Occasionally, I actually get to speak with the firewall
administrators, whose ignorance frequently provides me with some great
comic relief.  (Me: "Well, do your logs show it being blocked?"  Them: "I'm
not sure where the logfile is.  Can I call you back after I find it?")

In short, I would love to hear some opinions on the following:
A) In the "real" world, how often am I likely to encounter
firewalls/proxies doing 1), 2), or 3)?
B) Based on the sketchy information, could I be missing other possible
sources of blockage?
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.)
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.)
E) Expecting a decent portion of firewall administrators to be like those I
mentioned above, how restrictive are most commercial firewall products
out-of-the-box?  (i.e., Is my feeling that 3) should be blocked by default
the reality?)
F) Am I safe in assuming that proxies are the most likely candidate for
problems?  (Over, say, Firewall-1 and its ilk?  BTW, those folks above had
recently purchased Firewall-1.  I had an... err... interesting conversation
with their folks about Stateful Inspection.  But I'll save that for another
time.)

Sorry for this bulk of questions.  And thanks for all helpful thoughts.
(Or even thoughts.)

Greg

---
Greg Haverkamp, Network Administrator/Webmaster, Instinctive Technology 
See eRoom at http://www.instinctive.com "Where Teams Get Down to Business"
Of my many opinions, consider only one to be that of my employer:
I drink far too much Diet Coke