[CentOS-devel] Back on CentOS-devel to get some git.centos.org improvements

On Sun, Jul 6, 2014 at 10:06 AM, Karanbir Singh <mail-lists at karan.org>
wrote:

> On 07/06/2014 11:11 AM, Nico Kadel-Garcia wrote:
> > First note: in many environments, MITM is how things work normally. In
> > others, the routers and proxies and DNS are *not* secured or easily
> > re-implemented to be secure, for many, many different reasons. No
> > matter how careful you are with git.centos.org itself, it's going to
> > be vulnerable to trojaned intermediate repositories being substituted
> > because no one at CentOS or Red Hat has enough control over the
> > Internet to fix these.
>
> You are repeatedly saying this, but failing to actually quantify it.
>
> your gpg key is pretty much null routed once someone can MITM the
> content anyway, and i also assume you realise that a gpg sign is still
> with the same sort of code/key as an ssl connection is.
>


It's may be the same classification of cryptographic functions... but it is
not the same. With SSL/SSH you are, at least in theory, authenticating the
origin host. This makes no promise about the origin content.

A PGP-signed tag makes a promise about the content but does *not* make a
promise about the origin host.

So, they are not the same.

In the case of git.centos.org, somebody who manipulates the repositories
could likely fake the repository content being consistent, but would have a
more difficult time faking a signature where the public key is stored
elsewhere that git.centos.org (such as one of the PGP key servers). The
SSL/SSH for git.centos.org would continue to pass, but the signature would
not.

The other case already mentioned was the case that the content has an
intermediate resting point. That is, I clone from git.centos.org, and then
I publish to somebody else. How do they know which content is authentic...
mine or git.centos.org? Being able to point to the signed tag shows
cryptographically who signed the content and this could be an important
differentiator in determining which source is the "real" source.

Now:

>
> the bottom line is that unless you can get an authoritative manner of
> initial keyexchange, that you can absolutely trust, nothing else down
> the line is going to be any more secure than the initial handover. I'm
> happy to setup a keysign and keyexchange event at every dojo we run, but
> even that is likely to only reach a small fraction of the entire userbase.
>
> So the only way to get the originating gpg key ( that you'd verify
> against ) is over ssl on the internet, which also implies that having
> git.centos.org behind the same leave lof trust puts us no worse off.
>
>
I think you may be dismissing the two scenarios... 1) git.centos.org gets
compromised, 2) intermediate resting point. Both of these require the
*content* to be signed. You are only providing authentication of the
original source which does not address either of these points effectively.

So, I don't think it is correct that the "bottom line" is as you state
above. The real "bottom line" is that SSL/SSH only authenticates the source
host. It provides *no* guarantee for the source content.

If you authenticated the content, you wouldn't actually need to
authenticate the source host. This is how Bittorrent works in general. It
doesn't matter how the bytes get from point A to point B, as long as the
final result has the correct *content*. SSL/SSH do not guarantee the
correct *content* so it is rather ineffective as a means of authenticating
the content. It's saying "trust me... I'm git.centos.org... what could go
wrong?"


-- 
Mark Mielke <mark.mielke at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140706/6ba518ee/attachment-0003.html>