On 29 Nov 2000, Jim Blandy wrote:
> Greg Hudson <ghudson@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.
I do agree that it is possible to abuse HTTP to tunnel other
protocols. But that's true of *any* protocol: I've heard of people
creating a VPN using solely *DNS*, for example. Back in the early days of
the net there was also an email gateway for HTTP for those who only had
UUCP connections. A more immediate example might be average users who
download .exe's from web sites and run them directly.
And there'll be pressure for more - this is one of the driving forces
behind SOAP, for example, which is really just XML-over-HTTP as a cheap
form of RPC.
I suspect, though, that subversion really falls below the threshold of
what most people would suspect is "reasonable" for HTTP - there's nothing
it'll do that a cvsweb enhanced to allow commits wouldn't also allow.
We should probably think of this problem in two different contexts -
incoming to an organization's firewalled network, and outgoing from the
organization's firewalled network.
In the incoming case (i.e., firewall rules allow someone from the outside
to get to port 80 of a public web server run in a protected place),
putting SVN on that web server is no different than putting any type of
dynamic functionality - ultimately the responsibly for that security of
the system is beyond what the firewall can protect against.
In the outgoing case... well, I harbor the personal belief that preventing
your users from connecting to arbitrary remote ports on the net is just a
fool's endeavor. What protection does preventing someone from connecting
to port 2323 on a remote system gain the firewall admin? There are other
ways to detect things like port scans originating from internal sources,
or the use of streaming media. The only exception I can see is if you run
an ISP and block outgoing port 25 for your users (or filter their port 25
to always go to your local mail server) so you can prevent spamming.
But given the latter case still exists, it's really nice to remove the
impediment of asking your firewall admin to open a port, like they have to
with CVS today and port 2401. Believe it or not, CN has seen major
business decisions being made that involve that data point more than it
really should.
> 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. :)
Many already do.
Brian
Received on Sat Oct 21 14:36:15 2006