On Fri, 18 May 2007, Shawn O. Pearce wrote:
david@xxxxxxx wrote:
when a person browsing a hostile website will allow that website to take
over the machine the demand is created for 'malware filters' for http, to
do this the firewalls need to decode the http, and in the process limit
you to only doing legitimate http.
it's also the case that the companies that have firewalls paranoid enough
to not let you get to the git port are highly likely to be paranoid enough
to have a malware filtering http firewall.
I'm behind such a filter, and fetch git.git via HTTP just to keep
my work system current with Junio. ;-)
Of course we're really really really paranoid about our firewall,
but are also so paranoid that any other web browser *except*
Microsoft Internet Explorer is thought to be a security risk and
is more-or-less banned from the network.
The kicker is some of our developers create public websites, where
testing your local webpage with Firefox and Safari is pretty much
required... but those browsers still aren't as trusted as IE and
require special clearances. *shakes head*
this isn't paranoia, this is just bullheadedness
We're pretty much limited to:
*) Running the native Git protocol SSL, where the remote system
is answering to port 443. It may not need to be HTTP at all,
but it probably has to smell enough like SSL to get it through
the malware filter. Oh, what's that? The filter cannot actually
filter the SSL data? Funny! ;-)
we're actually paranoid enough to have devices that do man-in-the-middle
decryption for some sites, and are given copies of the encryption keys
that other sites (and browsers) use so that it can decrypt the SSL and
check it. I admit that this is far more paranoid then almost all sites
though :-)
*) Using a single POST upload followed by response from server,
formatted with minimal HTTP headers. The real problem as people
have pointed out is not the HTTP headers, but it is the single
exchange.
If you really want a stateful exchange you have to treat HTTP as
though it were IP, but with reliable (and much more expensive)
packet delivery, and make the Git daemon keep track of the protocol
state with the client. Yes, that means that when the client suddenly
goes away and doesn't tell you he went away you also have to garbage
collect your state. No nice messages from your local kernel. :-(
unfortunantly you are right about this.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
