git:// protocol over SSL/TLS

git:// protocol over SSL/TLS

[Sergey Sharybin]

Hello everyone!

Quick question is, is it possible to use git:// protocol over
SSL/TLS/other secure transport?

Or the recommended way to do secure anonymous checkout is to simply
use https:// ?

Thanks in advance!

-- 
With best regards, Sergey Sharybin

Re: git:// protocol over SSL/TLS

[Andreas Schwab]

Sergey Sharybin <sergey.vfx@gmail.com> writes:

> Quick question is, is it possible to use git:// protocol over
> SSL/TLS/other secure transport?

The git protocol itself performs no encryption or authentication by
design.  This is the job of the transport protocol.

> Or the recommended way to do secure anonymous checkout is to simply
> use https:// ?

Yes.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git:// protocol over SSL/TLS

[Konstantin Khomoutov]

On Fri, 27 Dec 2013 18:59:00 +0600
Sergey Sharybin <sergey.vfx@gmail.com> wrote:

> Quick question is, is it possible to use git:// protocol over
> SSL/TLS/other secure transport?

The Git protocol does not implement it itself but you can channel it
over a TLS tunnel (via stunnel for instance).  Unfortunately, this
means a specialized software and setup on both ends so if the question
was about a general client using stock Git then the answer is no, it's
impossible.

> Or the recommended way to do secure anonymous checkout is to simply
> use https:// ?

Yes, but it will only be secure if you've managed to verify the
server's certificate and do trust its issuer (or a CA higher up the
cert's trust chain) -- people tend to confuse "encrypted" with
"secure" which is not at all the same thing.

Re: git:// protocol over SSL/TLS

[Sergey Sharybin]

Hi,

On Fri, Dec 27, 2013 at 7:36 PM, Konstantin Khomoutov
<flatworm@users.sourceforge.net> wrote:
>
> The Git protocol does not implement it itself but you can channel it
> over a TLS tunnel (via stunnel for instance).  Unfortunately, this
> means a specialized software and setup on both ends so if the question
> was about a general client using stock Git then the answer is no, it's
> impossible.

Ok, got it.

> Yes, but it will only be secure if you've managed to verify the
> server's certificate and do trust its issuer (or a CA higher up the
> cert's trust chain) -- people tend to confuse "encrypted" with
> "secure" which is not at all the same thing.

We've got CA-signed certificate atm and it's about to be also
EV-signed for our server (git.blender.org). So this is not gonna to be
an issue. Cloning over https:// works fine, but we wanted to be sure
all the bits are secure.

So guess we just need to recommend using https:// protocol instead of
git:// for our users?

-- 
With best regards, Sergey Sharybin

Re: git:// protocol over SSL/TLS

[Andreas Schwab]

Sergey Sharybin <sergey.vfx@gmail.com> writes:

> So guess we just need to recommend using https:// protocol instead of
> git:// for our users?

Given how easy it is to verify the integrity of a git repository out of
band there isn't really much of added security by using TLS for
transport.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git:// protocol over SSL/TLS

[Konstantin Khomoutov]

On Fri, 27 Dec 2013 19:58:19 +0600
Sergey Sharybin <sergey.vfx@gmail.com> wrote:

[...]
> > Yes, but it will only be secure if you've managed to verify the
> > server's certificate and do trust its issuer (or a CA higher up the
> > cert's trust chain) -- people tend to confuse "encrypted" with
> > "secure" which is not at all the same thing.
> 
> We've got CA-signed certificate atm and it's about to be also
> EV-signed for our server (git.blender.org). So this is not gonna to be
> an issue. Cloning over https:// works fine, but we wanted to be sure
> all the bits are secure.

This setup sounds to be just the right thing.

> So guess we just need to recommend using https:// protocol instead of
> git:// for our users?

I think yes.  HTTP[S] once was dumb and slow but now it should be
comparable in speed to git:// as essentially using this protocol (which
became "smart" [1]) means spawning a git server process once per fetch/push
session and making the client and server Git processes communicate all by
themselves, so HTTP is there for request routing, authentication and
session setup while data transfer is carried out by Git processes
themselves [2].

1. http://git-scm.com/blog/2010/03/04/smart-http.html
2. https://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html

Re: git:// protocol over SSL/TLS

[Konstantin Khomoutov]

On Fri, 27 Dec 2013 15:12:07 +0100
Andreas Schwab <schwab@linux-m68k.org> wrote:

> > So guess we just need to recommend using https:// protocol instead
> > of git:// for our users?
> 
> Given how easy it is to verify the integrity of a git repository out
> of band there isn't really much of added security by using TLS for
> transport.

If the devs employ signed tags then yes but otherwise you'd have to
have some reference repository to compare with.  Sure they target for a
more no-brainer setup. ;-)

Re: git:// protocol over SSL/TLS

[Sergey Sharybin]

Our sysadmns are mainly worried about possible MITM which might give
users completely wrong repo.

For sure users might simply compare hash of HEAD from https'ed site
with repo browser with what they've got in the checkout. But that's an
extra step which we'd like to avoid without security harm :)

On Fri, Dec 27, 2013 at 8:12 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Sergey Sharybin <sergey.vfx@gmail.com> writes:
>
>> So guess we just need to recommend using https:// protocol instead of
>> git:// for our users?
>
> Given how easy it is to verify the integrity of a git repository out of
> band there isn't really much of added security by using TLS for
> transport.
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."



-- 
With best regards, Sergey Sharybin

Re: git:// protocol over SSL/TLS

[Matthieu Moy]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Sergey Sharybin <sergey.vfx@gmail.com> writes:
>
>> So guess we just need to recommend using https:// protocol instead of
>> git:// for our users?
>
> Given how easy it is to verify the integrity of a git repository out of
> band there isn't really much of added security by using TLS for
> transport.

You can verify integrity after the fact, but not guarantee
confidentiality ... so it again depends on the definition of "security".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

RE: git:// protocol over SSL/TLS

[Pyeron, Jason J CTR (US)]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

> -----Original Message-----
> From: Andreas Schwab
> Sent: Friday, December 27, 2013 9:12 AM
> 
> Sergey Sharybin <sergey.vfx@gmail.com> writes:
> 
> > So guess we just need to recommend using https:// protocol instead of
> > git:// for our users?
> 
> Given how easy it is to verify the integrity of a git repository out of
> band there isn't really much of added security by using TLS for
> transport.

I have to say, using encryption (TLS, etc) is not just for assurance of the communicating parties, but also to prevent a compromise of confidentiality.

Jason Pyeron
(please do not add me to the cc)

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]

Re: git:// protocol over SSL/TLS

[Sergey Sharybin]

Security in this case is about being sure everyone gets exactly the
same repository as stored on the server, without any modifications to
the sources cased by MITM.

As for "smart" http, this seems pretty much cool.However, we're
currently using lighthttpd, so it might be an issue. We'll check on
whether "smart" http is used there, and if not guess it wouldn't be a
big deal to switch to apache.

On Fri, Dec 27, 2013 at 8:20 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Sergey Sharybin <sergey.vfx@gmail.com> writes:
>>
>>> So guess we just need to recommend using https:// protocol instead of
>>> git:// for our users?
>>
>> Given how easy it is to verify the integrity of a git repository out of
>> band there isn't really much of added security by using TLS for
>> transport.
>
> You can verify integrity after the fact, but not guarantee
> confidentiality ... so it again depends on the definition of "security".
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/



-- 
With best regards, Sergey Sharybin

Re: git:// protocol over SSL/TLS

[Andreas Schwab]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> You can verify integrity after the fact, but not guarantee
> confidentiality ... so it again depends on the definition of "security".

Since the OP is talking about anonymous access there is no need for
confidentiality in this case.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git:// protocol over SSL/TLS

[Konstantin Khomoutov]

On Fri, 27 Dec 2013 20:25:16 +0600
Sergey Sharybin <sergey.vfx@gmail.com> wrote:

> Security in this case is about being sure everyone gets exactly the
> same repository as stored on the server, without any modifications to
> the sources cased by MITM.
> 
> As for "smart" http, this seems pretty much cool.However, we're
> currently using lighthttpd, so it might be an issue. We'll check on
> whether "smart" http is used there, and if not guess it wouldn't be a
> big deal to switch to apache.

The web server software has nothing to do with HTTP[S] used by Git being
"smart", I think, it just has to be set up properly.

As discussed in an earlier thread here, a good indication of the
dumb version of the protocol being in use is no display of the
fetching progress on the client while doing `git clone` because this
information (like "compressing objects ..." etc) is sent by the
server-side Git process which is only there if HTTP[S] "was smart".
Otherwise the client just GETs packs of objects, traverses them, GETs
more and so on, so batches of HTTP GET requests correlating to clone
sessions in the web server logs should also be indicative of the
problem.

Re: git:// protocol over SSL/TLS

[Sergey Sharybin]

>> As for "smart" http, this seems pretty much cool.However, we're
>> currently using lighthttpd, so it might be an issue. We'll check on
>> whether "smart" http is used there, and if not guess it wouldn't be a
>> big deal to switch to apache.
>
> The web server software has nothing to do with HTTP[S] used by Git being
> "smart", I think, it just has to be set up properly.

Misunderstood git doc then which says "it has to be Apache, currently
- other CGI servers don't work, last I checked".

> As discussed in an earlier thread here, a good indication of the
> dumb version of the protocol being in use is no display of the
> fetching progress on the client while doing `git clone` because this
> information (like "compressing objects ..." etc) is sent by the
> server-side Git process which is only there if HTTP[S] "was smart".
> Otherwise the client just GETs packs of objects, traverses them, GETs
> more and so on, so batches of HTTP GET requests correlating to clone
> sessions in the web server logs should also be indicative of the
> problem.

Just to verify, if i see messages like "Receiving objects:   1%
(7289/705777), 1.72 MiB | 340.00 KiB/s" it means server is "smart" ?



-- 
With best regards, Sergey Sharybin

Re: git:// protocol over SSL/TLS

[Konstantin Khomoutov]

On Fri, 27 Dec 2013 20:47:54 +0600
Sergey Sharybin <sergey.vfx@gmail.com> wrote:

[...]
> > As discussed in an earlier thread here, a good indication of the
> > dumb version of the protocol being in use is no display of the
> > fetching progress on the client while doing `git clone` because this
> > information (like "compressing objects ..." etc) is sent by the
> > server-side Git process which is only there if HTTP[S] "was smart".
> > Otherwise the client just GETs packs of objects, traverses them,
> > GETs more and so on, so batches of HTTP GET requests correlating to
> > clone sessions in the web server logs should also be indicative of
> > the problem.
> 
> Just to verify, if i see messages like "Receiving objects:   1%
> (7289/705777), 1.72 MiB | 340.00 KiB/s" it means server is "smart" ?

I would say yes, because your Git knows the precise number of objects to
receive.  Unfortunately, I won't swear by this as this was a long time
ago I have seen cloning using the dumb protocol.

By the way, here [1] is that discussion.

1. http://thread.gmane.org/gmane.comp.version-control.git/238933/focus=238946

Re: git:// protocol over SSL/TLS

[Bernhard R. Link]

* Sergey Sharybin <sergey.vfx@gmail.com> [131227 15:25]:
> Security in this case is about being sure everyone gets exactly the
> same repository as stored on the server, without any modifications to
> the sources cased by MITM.

Note that ssl (and thus https) only helps here against a resource-less
man-in-the-middle. Getting catch-all CA-signed certificates is said to
no longer available to everyone as easily as it was some years ago, but
unless you allow only one private CA (and even there clients often fail)
you still should assume everyone resourceful enough to still be able to
do MITM.

        Bernhard R. Link

Re: git:// protocol over SSL/TLS

[Junio C Hamano]

Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:

> On Fri, 27 Dec 2013 18:59:00 +0600
> Sergey Sharybin <sergey.vfx@gmail.com> wrote:
>
>> Quick question is, is it possible to use git:// protocol over
>> SSL/TLS/other secure transport?
>
> The Git protocol does not implement it itself but you can channel it
> over a TLS tunnel (via stunnel for instance).  Unfortunately, this
> means a specialized software and setup on both ends so if the question
> was about a general client using stock Git then the answer is no, it's
> impossible.

Hmph, I somehow had an impression that you wouldn't need anything
more complex than a simple helper that uses git-remote-ext on the
client side. On the remote end, you'd need to have something that
terminates the incoming SSL/TLS and plugs it to your git daemon.

>
>> Or the recommended way to do secure anonymous checkout is to simply
>> use https:// ?
>
> Yes, but it will only be secure if you've managed to verify the
> server's certificate and do trust its issuer (or a CA higher up the
> cert's trust chain) -- people tend to confuse "encrypted" with
> "secure" which is not at all the same thing.

Re: git:// protocol over SSL/TLS

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

On Fri, Dec 27, 2013 at 08:25:16PM +0600, Sergey Sharybin wrote:
> Security in this case is about being sure everyone gets exactly the
> same repository as stored on the server, without any modifications to
> the sources cased by MITM.

Besides security, HTTPS is more likely to work across different
firewalls and proxies, since "odd" ports like 9418 are often blocked and
HTTPS usually isn't subject to the weirdness of proxies (since they
can't inspect it or modify it).

> As for "smart" http, this seems pretty much cool.However, we're
> currently using lighthttpd, so it might be an issue. We'll check on
> whether "smart" http is used there, and if not guess it wouldn't be a
> big deal to switch to apache.

You can use Lighttpd if you like.  See
Documentation/git-http-backend.txt (or git http-backend --help).

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: git:// protocol over SSL/TLS

[Jeff King]

On Fri, Dec 27, 2013 at 08:47:54PM +0600, Sergey Sharybin wrote:

> > The web server software has nothing to do with HTTP[S] used by Git being
> > "smart", I think, it just has to be set up properly.
> 
> Misunderstood git doc then which says "it has to be Apache, currently
> - other CGI servers don't work, last I checked".

Do you happen to remember where you saw that claim? If the manual in
git's Documentation/ directory says that, I'd like to fix it.

I added sample lighttpd config to "git help http-backend" a while back.
I tested it at the time, but I do not currently run a lighttpd git
server at all.

-Peff

Re: git:// protocol over SSL/TLS

[Ilari Liusvaara]

On Fri, Dec 27, 2013 at 02:21:31PM -0800, Junio C Hamano wrote:
> Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:
> >
> > The Git protocol does not implement it itself but you can channel it
> > over a TLS tunnel (via stunnel for instance).  Unfortunately, this
> > means a specialized software and setup on both ends so if the question
> > was about a general client using stock Git then the answer is no, it's
> > impossible.
> 
> Hmph, I somehow had an impression that you wouldn't need anything
> more complex than a simple helper that uses git-remote-ext on the
> client side. On the remote end, you'd need to have something that
> terminates the incoming SSL/TLS and plugs it to your git daemon.

If you have some tool that can do cleartext I/O from stdin/stdout
and establishes ciphertext connection itself, you can use it with
git-remote-ext. It was written for cases exactly like that.

To do git:// inside, use the %G pseudo-argument.

-Ilari

Re: git:// protocol over SSL/TLS

[Sergey Sharybin]

Yeah, i understand this. We can not protect self from every single
possible attack..

On Fri, Dec 27, 2013 at 10:26 PM, Bernhard R. Link
<brl+git@mail.brlink.eu> wrote:
> * Sergey Sharybin <sergey.vfx@gmail.com> [131227 15:25]:
>> Security in this case is about being sure everyone gets exactly the
>> same repository as stored on the server, without any modifications to
>> the sources cased by MITM.
>
> Note that ssl (and thus https) only helps here against a resource-less
> man-in-the-middle. Getting catch-all CA-signed certificates is said to
> no longer available to everyone as easily as it was some years ago, but
> unless you allow only one private CA (and even there clients often fail)
> you still should assume everyone resourceful enough to still be able to
> do MITM.
>
>         Bernhard R. Link



-- 
With best regards, Sergey Sharybin