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

Sat Jul 5 18:11:42 UTC 2014
Mark Mielke <mark.mielke at gmail.com>

I might be misunderstanding this thread... but if package signing and/or
message digest are not being applied to SRPM, I also agree this is a

On Sat, Jul 5, 2014 at 10:58 AM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Sat, Jul 5, 2014 at 8:23 AM, Karanbir Singh <mail-lists at karan.org>
> wrote:
> > On 07/05/2014 05:08 AM, Nico Kadel-Garcia wrote:
> >> Thanks. But Karanbir, "commit" is not the problem I'm referring to.
> >> It's the ability to substitute a trojaned, fake repository in between
> >> you and the client, to commit a "man-in-the-m8iddle" attack Valid SSL
> >
> > what about git.centos.org's ssl cert looks invalid ? Also, if you are
> > doubting SSL as a transport, we've all got bigger problems.
> Today? *Nothing*. It's not git.centos.org, itself, that I'm worried
> about.  The proper use of private/public key pairs, such as SSH and
> SSL private keys, can help protect the central repository from
> improper access, and I assume that you folks are also doing code
> review before pulls are accepted into the primary repositories.

Yes. SSL and SSH *can* provide privacy in transit and authentication of the
source and destination (often only the destination). But it doesn't protect
the content at the source or the target or at transit points, and
authentication of the destination host isn't as useful or as well
scrutinized as many people believe.

In the case of SSL... the recent "Heartbleed" exploit clearly demonstrates
that SSL is not as invulnerable as people have been lead to believe. But,
SSL has long had known issues and been circumvented. Edward Snowden changed
our suspicions to beliefs that the US government was dabbling in this
practice including potentially intercepting the SSL traffic directed
towards large companies that I won't name here.

In the case of SSH... how many of you actually look up the SSH public key
through a secondary channel (not SSH to the server!), before you accept the
SSH public key as valid into your ~/.ssh/known_hosts file? I know I'm as
guilty as probably all of you, and I generally do not.

More on this:

> It's man-in-the-middle attacks for remote software downloaders. They'e
> vulnerable to trojaned repositories. placed *in between* their local
> client and git.centos.org. And SSL itself is vulnerable to forged keys
> using stolen signature authorities, whether local to a remote
> environment or such as the stolen "GlobalSign" keys. There are even
> environments that put proxies in front of *incoming* traffic, locally,
> to slap a new internal and internally signed SSL key on it, and
> *deliberately* do man-in-the-middle monitoring at the proxy. There are
> others that block most external HTTP/HTTPS and route only a few
> allowed external websites through an internal DNS address at the
> proxy: they've effectively insisted on being a man-in-the-middle for
> their own internal monitoring and traffic control reasons, and they
> can wind up using internally signed keys. They certainly can't use
> *your* keys for that!!!!

Our company is looking into exactly these technologies. Both HTTPS and SSH
transparent proxies. Once deployed, I won't be able to SSH from work out to
a machine on the Internet without my session being "in the clear" and under
the complete control of the proxy machine. The intent of this is supposedly
to prevent data exfiltration but what it amounts to is that the company
wants the ability to monitor all traffic in and out, and to be able to do a
sort of "deep packet inspection" or even manipulation that would allow them
to better filter the content and in the case of SSH, the ability to disable
the use of port forwarding over SSH as a tunnel. They are real. Yes, a
person worried about such a thing could check the signature of the server
and the signature would probably not match... but for SSH, do you check the
signature? And for SSL, what happens if they also intercept or manipulate
the certificate lookups?

The point here is that HTTPS and SSH provide an amount of privacy and
security. It does not make *any* guarantee about the authenticity of the
content. It is sort of like having a rare painting be transported in a
security truck, and presuming that because the painting arrives in a
security truck, the painting must still be the original. The only way to
determine if the painting is the original is to actually check the painting
itself. How it arrives is irrelevant.

In a less extreme case, it just needs somebody to "hack into" one of the
CentOS distribution points and replace the source and the .metadata with
something of their own. Or it could just be a disgruntled or
financially-rewarded volunteer who quietly replaces a server package.
Without signatures, it can be difficult to detect this sort of thing.

Now, Git itself provides some of these protections... I'm only learning
about CentOS 7 and git.centos.org, but I suspect a capability availability
here is to use the Git SHA-1 commit identifiers as a means of
authenticating content... but this wouldn't be good enough for files
produced or distributed outside of Git...

Anyways... I just wanted to add support to the argument that signatures of
some sort are desirable and that SSH and SSL are not on their own

Mark Mielke <mark.mielke at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140705/52abf22b/attachment-0007.html>