Re: Network Traffic Violations

[Ken Hardy <ken () bridge com>]

On Thu, 3 Sep 1998, Jim Wamsley 303-673-8163 wrote:

> I think I have had it with some companies that are selling web based
> services that require you to use their home-brew package that fails to
> take into account the way most of us, or at least many of us are
> controlling our Internet access.
>
> {paragraph deleted}
>
> My point is, where do these folks get off designing apps without taking
> into account that the firewall policies many of us have in place will
> not allow these things to work.  I do not like some jerk deciding that
> his concepts should take precedence over my judgement. Maybe we should
> get some legislation enacted that would permit us to publicly flog
> anyone who brazenly violate another's space forcing me to rebel against
> users who are either cluelessly reckless or recklessly clueless and
> demand that we do things we don't do so they can do their jobs. ( Yes
> Marcus, I have the network traffic violations.) I am tired of being
> accused of not being a good corporate citizen because these fools
> haven't any idea what good safe network design is all about.  Don't
> dictate your policy to me.  Live in my framework.  give me options that
> I can safely use!!!!!

How does "good safe network design" result from having *everything* use
HTTP?

I work for a company that has a product that uses a proprietary
protocol on a dedicated TCP port.  I was not involved with the design
or implementation of the product, but as the local firewall expert, I
was called in for consultations when potential customers started
raising the same issues you state.  (It's asking to much to be
consulted at the start of the process, of course.)

First off, I think you need to be careful about what you call
web-based.  Our product is currently implemented in Java applets, and
those applets do get loaded into the user's execution environment via
HTTP in a web browser.  But their function is not "web" based.  I.e.,
the app does not browse HTML pages, and it requires a persistent
bi-directional datastream between desktop and server, a mode of
connection for which HTTP is ill-suited.  HTTP cannot serve all needs.

In this case we're serving up real-time (sub-second latency) financial
market data and analytics with a client-server architecture.  Not all
apps or data are suited to HTTP/HTML, even if the app is written for an
execution environment that typically resides inside a web browser.  You
probably cannot shoehorn the whole world into HTTP/1.1.

A large client and potential reseller of the service/product had a
problem with our use of a separate TCP port for the data, and they
experienced the same attitude as yours when they went to their
customers with the service.  Their chief concern was resistance from
"lazy fireall administrators" to openning the specific port to our
server.

Of course, there's more to it than just opening the port, and "lazy" is
not the right adjective.  As a f/w admin I fully understand the
reluctance to research a whole new app and protocol before opening the
port.  But, unlike others, I do not call this "opening a hole in the
firewall."  A hole connotes a security problem, as in "I found a great
big hole in sendmail." Rather, I call this "enabling an authorized
connection."  There may or may not be a hole associated with it.

In this case the client came to town with a high-powered consultant (he
should be reading this and recognize it -- hi!), and we had a nice
long meeting to discuss how we could basically render firewalls entirely
irrelevant by tunneling any data we needed over HTTP, Telnet, or
whatever else might already be available through the firewall.  From
our business perspective it makes sense -- your users can start using
our product without ever bringing you into the picture.  From a
security perspective this strikes me as ludicrous.

Think about it.  If you allow users access to the world-wide web, and
if I can tunnel any protocol I want over HTTP, your firewall is nothing
more than a diode which allows no finer degree of control than ensuring
that all connections are initiated from the inside.  In that case, you
might as well open up all ports for outgoing connections and not be
bothered by these sorts of requests.

I think there's more security available by having these special apps
use special ports.  If the CEO and EVP "need" to run an evaluation of a
new app that has to connect to a remote data server, I can set up the
firewall to allow *just* those two desktops to connect to *just* that
one server.  I could easily sniff the data connections if there's any
suspicion connected with it.  I can more easily find the connection
stats in the log files.  And I can disable the connection when the
evaluation is finished.  I'm *aware* of what's happening.

If that same app uses HTTP for its data transport, then anyone anywhere
in the company can use it at anytime without you even being aware of
its existence.  Sure, it makes your life easier.  But does that make it
safer?  I don't think so.

I like HTML over HTTP.  It's a known entity, is fairly benign, and can
be rendered more so by having the proxy remove ActiveX and
Java(script).  But if the HTTP response comes back with a Content-type
not of text/html then your proxy is just going to pass it through
untouched.  If the client program doing the HTTP is not a generic web
browser, it can get whatever it wants past your proxy even in HTML by
using a private encoding scheme understood by it and its server but not
the proxy.

I think that unless you're using an authenticating proxy the genie is
already out of the bottle.  If you're using an authenticating proxy
then your special apps that use HTTP probably won't work, and your
users are out of luck, unless you can disable the authentication
requirement on a per-site basis.  And then what's the difference from
openening those non-HTTP ports to specific sites?


Finally, if a product does use HTTP, it should be able to be configured
to know how to use a proxy.  The proxy protocol is an integral part of
the HTTP spec, after all.  Our HTTP proxy runs on a non-standard port
in order to make the trojan horses work a little harder.  I downloaded
the freeware PGP for Windoze yesterday.  It has a cool mechanism for
interfacing to key servers with HTTP.  But it appears that it cannot be
made to know about the proxy!  :'(

- KH