Re: git and https

[Henrique de Moraes Holschuh <hmh@debian.org>]

On Mon, May 25, 2015, at 09:09, Rebecca N. Palmer wrote:
> While we're on the subject of git security...should we stop recommending 
> that non-account-holders use git:// (most efficient, but insecure 
> against MITM unless you manually check the commit number) in preference 
> to https:// (at least some security)? 
> https://wiki.debian.org/Alioth/Git#Accessing_repositories

When you are in a position to actually mandate the full certificate
validation (i.e. enforce pin and validation on the client, and control
the server certificate), you would get one security benefit out of
HTTPS/TLS for git transport:

* Data must be modified at rest at either endpoint, it cannot be
corrupted while in transit.

You cannot even get that much benefit out of the typical web browser
https/TLS use, because either the user will just say "yes" to the
security exception dialog, or because it is not too difficult to get a
fraudulent certificate that can be used for MITM from a shady or
otherwise crappy/compromised CA that could be anywhere in the world,
etc.

git as a https client is not really different from the typical web
https/TLS use, except that it doesn't give you a dialog to shoot
yourself in the foot and say "ignore security exception" -- instead it
gives you command line parameters or environment variables to do so. 
However, it will still trust all "system CAs" equally, etc. unless
specifically configured to do something else.

You must always keep in mind that https and TLS _cannot_ protect you
against data tampering on the repositories themselves. For this, you
need signed tags and signed commits, which will protect the data at rest
(i.e. stored on both the remote and the local repositories).  Once you
have that, it doesn't matter that much if you use the git protocol or
http, or https as far as security goes, as you can (and should) verify
the result of the transfer instead.

> Any suggestions for persuading upstreams to care about these issues? 

If upstream signs tags and commits (i.e. if every branch always have a
signed tag or signed commit as the tip), I'd recommend that you don't
pester them about https.  Chances are they know what they're doing.

If upstream won't even sign release tags, try to talk to them about the
several instances of data tampering that several projects have been
through, and the need to have signatures on code repositories.

Pointing them to http://mikegerwitz.com/papers/git-horror-story might,
or might not help.  That text goes a bit overboard (on purpose), so it
might come across as needless paranoia to many... especially to anyone
that cannot even be bothered to sign tags in the first place :-)

But pestering upstream about https for git clone/fetch ?  That's
knocking on the wrong door.

> Mine has no https on the repository (though they do on the release 
> tarballs), no signed anything, and have not responded to me pointing out 
> that this is a security hole: 
> https://bugs.freedesktop.org/show_bug.cgi?id=89682

https for git access is not what you should be asking out of
freedesktop.org, IMO.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <hmh@debian.org>