Re: [RFC 0/2] Git-over-TLS (gits://) client side support

[Ilari Liusvaara <ilari.liusvaara@elisanet.fi>]

On Wed, Jan 13, 2010 at 05:17:11PM +0100, Andreas Krey wrote:
> On Wed, 13 Jan 2010 16:47:47 +0000, Ilari Liusvaara wrote:
> 
> If you don't want public read access then you need to wedge a script
> between stunnel and git itself that checks whether authentication is
> present, yes.

That would violate layering badly. You need to decode the request
first before you can authorize. And the git daemon does that.
 
> > And besides: Gits:// uses certificates as keypairs,
> 
> My gripe with this is that I would expect gits: to be the same
> as git: except that there is SSL underneath. git: does not have
> authentication, so there should be none in gits: except what
> SSL provides.

All authentication in gits:// is at TLS (SSL) level or even lower.

> (And the auth via unix domain sockets would be
> usable for plain git: as well; there is no reason to encrypt
> local traffic?)

In fact, git-remote-gits has unencrypted mode (should be compatible
with git-daemon). The reason its there is mainly for Unix domain
sockets support and more advanced IPv6 support (interface indexes and
numeric addresses actually work).

> (Is the unix auth via unix domain sockets part of GnuTLS?)

No, that server-only feature is part of the OS itself. In fact, it
needs no client-side support.

> That's another story. I think that it would be possible nowadays
> to implement gits:// (in both ways) via core.gitproxy and a server-side
> wrapper program (stunnel or else), but that has the disadvantage of
> being unable to just provide a clone url without installing special
> software besides git.

GIT_PROXY abuse? There are even better ways: smart transport remote
helpers (in next I think). Git can actually dispatch those (and yes,
that's exactly what this uses).

And gits:// client is also buildable selfstanding. That would require
new client software, but its still nicer than GIT_PROXY abuse.

Another problem with GIT_PROXY abuse: How to deal with potentially
multiple custom protocols. Remote helpers can deal with that nicely.

> ...
> > The authentication support for smart-http seems pretty bad (making the
> > old mistake of not binding authentications).
> 
> Mind to explain 'binding authentications'?

Actually, that was little badly choosen term and not the true problem,
but the basic problem is that one peer has to trust the the other peer's
authentication for security of its own authentication.

In how authentications used by gits:// are designed, even if client doesn't
detect trying to authenticate with attacker, the attacker doesn't get any
replayable credentials without breaking crypto keys (as opposed to just
passwords). This holds true even for password authentication (PAKE-type
scheme is used).

HTTP basic auth can be trivially sniffed if attacker can become other end
of the encrypted link (crypto is by far the strongest link...). Digest auth
is harder, but its essentially brute force against password (as opposed to
trying to break a key).


-Ilari