Re: git over webdav: what can I do for improving http-push ?

From: Grégoire Barbier <gb@gbarbier.org>
Date: Jan 1, 2008, 11:41 UTC
Message-ID: <477A26FD.7020408@gbarbier.org>
In-Reply-To: <20080101113301.GC9214@efreet.light.src>

Jan Hudec a écrit :

Show 24 quoted lines

> On Mon, Dec 31, 2007 at 10:57:52 -0600, Graham Barr wrote:
>   
>> Daniel Barkalow wrote:
>>     
>>> On Sun, 30 Dec 2007, Grégoire Barbier wrote:
>>>       
>>>> As for me, the main rationale to use http(s) rather than
>>>> git or ssh is to get through corporate firewalls, otherwise I would probably
>>>> not bother with webdav.
>>>>         
>>> In general, we've been able to either get through firewalls with ssh or 
>>> it's all in the same VPN. So it's kind of unloved at this point. People 
>>> poke at it occasionally, but mostly in the context of other fixes, I 
>>> think.
>>>       
>> If you have a http proxy that you can use, the you can use ssh via that with
>> something like corkscrew. http://wiki.kartbuilding.net/index.php/Corkscrew_-_ssh_over_https
>>     
>
> This, obviously, requires, that ssh is running on port 443, because most HTTP
> proxies won't let you CONNECT anywhere else. I have also heared of a HTTP
> proxy, that will check whether the session inside CONNECT starts with SSL
> handshake and will break your connection if it does not.
>

Hello Jan.

I think we have similar experiences. I have personnaly be faced to proxies that not only scan for the SSL handshake but do man-in-the-middle "attack" to break the SSL into two parts, checking for HTTP inside it (and probably scanning for viruses and things like hat, I think).

I first replied privatly to Graham because I didn't think it was interesting for the whole list. It was a mistake, here is my answer:

In fact, I already use this hack where it is possible.

However some well advised companies does not allow CONNECT through their HTTP proxy without some limitations that make this tip unusable (for instance: allowing only port 443, allowing only sites of a white-list, forcing a man-in-the-middle that not only breaks the confidentiality but too forbids the use of other protocols such as SSH, even on port 443).

BTW such circumvention of the security facilities is often (at less where I live and with my clients) forbidden in some corporate rules, even when it is technically possible. Therefore I'm not allowed to do so and, furthermore, I cannot tell my clients to do so and write documents that tell it's the good way.

I think that real HTTP support is better than all workarounds we will be able to find to get through firewalls (when CONNECT is not available, some awful VPNs that send Etherne over HTTP may work ;-)). That's why I'm ok to work several hours on git code to enhance real HTTP(S) support.

-- 
Grégoire Barbier - gb à gbarbier.org - +33 6 21 35 73 49