navigating proxies/firewalls (was: Re: svn_ra.h)

[Greg Stein <gs...@lyra.org>]

On Wed, Nov 29, 2000 at 04:54:31PM -0500, Jim Blandy wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
> > > This way libsvn_ra_dav is still HTTP proxy happy, and you don't have
> > > to let ssh through your firewall if you don't have to.
> > 
> > This argument is terrible, incidentally.  A firewall which allows HTTP
> > through is allowing it for the sake of web browsing, not for
> > Subversion.  By making Subversion run over HTTP, we are subverting
> > that policy, which is a bad thing, not a good thing.
> 
> I think this is a pretty funny situation.  It's true that doing
> Subversion work over HTTP will get us through a lot of firewalls.  And
> it's true that this is subverting the intent of the firewall.
> 
> It's kind of an arms race between users who want to do things, and
> sysadmins who want to keep the system secure.  In general, you could
> embed just about anything in HTTP, and get around firewalls.
> 
> As a consequence, I say it's just a matter of time before firewalls
> start looking inside HTTP streams.  :)

It depends a lot on the firewall/proxy. Most "firewalls" simply do port
management. Proxies/caches are "application level" services. They will
almost always open the packet up, see what kind of HTTP request it is,
perform various monkey work related to caching and optimizing the two
network streams (e.g. a client might use HTTP/1.0, but the proxy will speak
HTTP/1.1 to the server), etc.

These app-level services can and *do* filter on the HTTP method. In fact, if
you take a look at http://www.webdav.org/other/proxy.html, you'll see that a
number of proxies exist that block DAV methods (on purpose rarely; most just
haven't been updated to HTTP/1.1 and/or have the UI/config to allow
admin-defined methods thru).

The point here is that the admin is almost always in control of whether he
wants to allow DAV through his proxy. Firewalls... yah: different story. If
the admin wants real control, then they will always use a full app-level
proxy for *all* traffic (e.g. SMTP, POP, HTTP).

Last point: the DAV design had this particular "effect" in mind when it was
created (that a network admin can filter on HTTP method).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/