[gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Sebastian Pipping]

Hi!


For the current Gentoo Git setup I found these methods working for
accessing a repository, betagarden in this case:

  git://anongit.gentoo.org/proj/betagarden.git
 (git://git.gentoo.org/proj/betagarden.git)
 (git://git.overlays.gentoo.org/proj/betagarden.git)

  http://anongit.gentoo.org/git/proj/betagarden.git

 (http://cgit.gentooexperimental.org/proj/betagarden.git)

  git+ssh://git@git.gentoo.org/proj/betagarden.git
 (git+ssh://git@git.overlays.gentoo.org/proj/betagarden.git)

Those without braces are the ones announced at the repository's page [1].

My concerns about the current set of supported ways of transfer are:

 * There does not seem to be support for https://.  Please add it.

 * Why do we serve Git over git:// and http:// if those are vulnerable
   to man-in-the-middle attacks (before having waterproof GPG
   protection for whole repositories in place)?
   Especially with ebuilds run by root, we cannot afford MITM.


So I would like to propose that

 * support for Git access through https:// is activated,

 * Git access through http:// and git:// is deactivated, and

 * the URLs on gitweb.gentoo.org and the Layman registry are
   updated accordingly.  (Happy to help with the latter.)


Thanks for your consideration.

Best,



Sebastian


[1] https://gitweb.gentoo.org/proj/betagarden.git/

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

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

Despite of all you're talking about is right from paranoid point of view, I'd, 
anyway, say "DO NOT DO THAT", because you propose to revoke the right of 
choice from the users.

It is user's decision, which protocol to use to fetch the sources. Although, 
you're, of course, free to make layman to fetch "official" repos from https, 
but not http/git protocols by default.

Moreover, there are some times where it is impossible to fetch sources via 
"secure" way, but you need it right here and right now.





В письме от Вс, 29 марта 2015 18:41:33 пользователь Sebastian Pipping написал:
> Hi!
> 
> 
> For the current Gentoo Git setup I found these methods working for
> accessing a repository, betagarden in this case:
> 
>   git://anongit.gentoo.org/proj/betagarden.git
>  (git://git.gentoo.org/proj/betagarden.git)
>  (git://git.overlays.gentoo.org/proj/betagarden.git)
> 
>   http://anongit.gentoo.org/git/proj/betagarden.git
> 
>  (http://cgit.gentooexperimental.org/proj/betagarden.git)
> 
>   git+ssh://git@git.gentoo.org/proj/betagarden.git
>  (git+ssh://git@git.overlays.gentoo.org/proj/betagarden.git)
> 
> Those without braces are the ones announced at the repository's page [1].
> 
> My concerns about the current set of supported ways of transfer are:
> 
>  * There does not seem to be support for https://.  Please add it.
> 
>  * Why do we serve Git over git:// and http:// if those are vulnerable
>    to man-in-the-middle attacks (before having waterproof GPG
>    protection for whole repositories in place)?
>    Especially with ebuilds run by root, we cannot afford MITM.
> 
> 
> So I would like to propose that
> 
>  * support for Git access through https:// is activated,
> 
>  * Git access through http:// and git:// is deactivated, and
> 
>  * the URLs on gitweb.gentoo.org and the Layman registry are
>    updated accordingly.  (Happy to help with the latter.)
> 
> 
> Thanks for your consideration.
> 
> Best,
> 
> 
> 
> Sebastian
> 
> 
> [1] https://gitweb.gentoo.org/proj/betagarden.git/

-- 
Best regards,
mva

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Andrew Savchenko]

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

On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
> So I would like to propose that
> 
>  * support for Git access through https:// is activated,
> 
>  * Git access through http:// and git:// is deactivated, and

Some people have https blocked. http:// and git:// must be
available read-only.

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Sebastian Pipping]

On 29.03.2015 19:39, Andrew Savchenko wrote:
> On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
>> So I would like to propose that
>> 
>> * support for Git access through https:// is activated,
>> 
>> * Git access through http:// and git:// is deactivated, and
> 
> Some people have https blocked. http:// and git:// must be 
> available read-only.

They would not do online banking over http, right?  Why would they run
code with root privileges from http?

Best,



Sebastian

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Diamond]

On Sun, 29 Mar 2015 18:41:33 +0200
Sebastian Pipping <sping@gentoo.org> wrote:

> Hi!
> 
> 
> For the current Gentoo Git setup I found these methods working for
> accessing a repository, betagarden in this case:
> 
>   git://anongit.gentoo.org/proj/betagarden.git
>  (git://git.gentoo.org/proj/betagarden.git)
>  (git://git.overlays.gentoo.org/proj/betagarden.git)
> 
>   http://anongit.gentoo.org/git/proj/betagarden.git
> 
>  (http://cgit.gentooexperimental.org/proj/betagarden.git)
> 
>   git+ssh://git@git.gentoo.org/proj/betagarden.git
>  (git+ssh://git@git.overlays.gentoo.org/proj/betagarden.git)
> 
> Those without braces are the ones announced at the repository's page
> [1].
> 
> My concerns about the current set of supported ways of transfer are:
> 
>  * There does not seem to be support for https://.  Please add it.
> 
>  * Why do we serve Git over git:// and http:// if those are vulnerable
>    to man-in-the-middle attacks (before having waterproof GPG
>    protection for whole repositories in place)?
>    Especially with ebuilds run by root, we cannot afford MITM.
> 
> 
> So I would like to propose that
> 
>  * support for Git access through https:// is activated,
> 
>  * Git access through http:// and git:// is deactivated, and
> 
>  * the URLs on gitweb.gentoo.org and the Layman registry are
>    updated accordingly.  (Happy to help with the latter.)
> 
> 
> Thanks for your consideration.
> 
> Best,
> 
> 
> 
> Sebastian
> 
> 
> [1] https://gitweb.gentoo.org/proj/betagarden.git/
> 
> 
Doesn't git:// uses SSH wich is secure? I think that was on github.

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Sebastian Pipping]

On 29.03.2015 19:56, Diamond wrote:
> Doesn't git:// uses SSH wich is secure? I think that was on github.

git:// is "the git protocol" [1] "with absolutely no authentication" and
no encryption.

GitHub does not support git:// but only secure protocols (HTTPS, SSH),
see [2].

Best,



Sebastian


[1]
http://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#The-Git-Protocol
[2] https://help.github.com/articles/which-remote-url-should-i-use/

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Andrew Savchenko]

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

On Sun, 29 Mar 2015 19:52:38 +0200 Sebastian Pipping wrote:
> On 29.03.2015 19:39, Andrew Savchenko wrote:
> > On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
> >> So I would like to propose that
> >> 
> >> * support for Git access through https:// is activated,
> >> 
> >> * Git access through http:// and git:// is deactivated, and
> > 
> > Some people have https blocked. http:// and git:// must be 
> > available read-only.
> 
> They would not do online banking over http, right?  Why would they run
> code with root privileges from http?

Gentoo tree access is not even near on the same security scale as
online banking.

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

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

> 
> They would not do online banking over http, right?  Why would they run
> code with root privileges from http?

1) Actually, they will :(
2) Because they can't review what bank received via insecure channel, while 
they can review what they're themselves received via http/git.

-- 
Best regards,
mva

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/29/2015 06:41 PM, Sebastian Pipping wrote:
> Hi!
> 

...

> 
> * Why do we serve Git over git:// and http:// if those are
> vulnerable to man-in-the-middle attacks (before having waterproof
> GPG protection for whole repositories in place)?

<pedant>OpenPGP (GPG is just one implementation)</pedant>, but indeed,
that is what the gentoo-keys project is about. There is experimental
support for OpenPGP verification in portage already using gkeys.
Currently the focus is on getting developer's keys up to GLEP63 specs,
i currently see 36 good Gentoo developer keys. The scheme is also
flexible enough to allow for overlays.

> Especially with ebuilds run by root, we cannot afford MITM.
> 
> 
> So I would like to propose that
> 
> * support for Git access through https:// is activated,

https is not a good protection against MITM when factoring in global
PKIX CA setup, nor would it protect with regards to server compromise.
So the only viable way to secure ebuild repositories is proper OpenPGP
usage.


- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJVGD9LAAoJEP7VAChXwav6VmsIALlhZ1g1GXYAL/ZkP+vi1L0H
MLKfYcxkMgZNwEfykmRP4DvafNPDDhWT0gvFfD+vG4zucI7liQSUnzK8SbVtzz3l
o/cCELtOvjq6pMnefizwxoG0IyJmu07Tu2kUPo3Qyw1I5IqHqaqFWDB/Noe5Rvuy
rbXgWqMgg6rcYxOhUHN4YQFtw1xEgWW4CS8Smri2jjSRaizgQ2sw+Iji/ej4XUyW
JvWdZfGfHuzTX/uWPr7ptyi9foVvTkc9Hko2t97XS/bNZvtECRNceZBOTGgHftgD
nCopTHBY42G69B+z07qctdI2AH2ozskI1+42rE2k6vJLNfFcY5loidsWDPiG3a8=
=9GQH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

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

> Doesn't git:// uses SSH wich is secure? I think that was on github.
git+ssh:// — does. git:// — does not. It is just git-daemon listening on 
separate port and serving plaintext, readonly (by default) access.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

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

> <pedant>OpenPGP (GPG is just one implementation)</pedant>, but indeed,
> that is what the gentoo-keys project is about. There is experimental
> support for OpenPGP verification in portage already using gkeys.
> Currently the focus is on getting developer's keys up to GLEP63 specs,
> i currently see 36 good Gentoo developer keys. The scheme is also
> flexible enough to allow for overlays.
> 
> 
> https is not a good protection against MITM when factoring in global
> PKIX CA setup, nor would it protect with regards to server compromise.
> So the only viable way to secure ebuild repositories is proper OpenPGP
> usage.

I'd double that pedant paranoid! :)

-- 
Best regards,
mva

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

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

> GitHub does not support git:// but only secure protocols (HTTPS, SSH),
GitHub DO (!) support git://

$ git clone git://github.com/msva/mva-overlay.git
Cloning into 'mva-overlay'...
remote: Counting objects: 10435, done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 10435 (delta 11), reused 0 (delta 0), pack-reused 10393
Receiving objects: 100% (10435/10435), 2.99 MiB | 758.00 KiB/s, done.
Resolving deltas: 100% (5132/5132), done.
Checking connectivity... done.


> see [2].

"shoud-i-use" != "do not support"

-- 
Best regards,
mva

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Rich Freeman]

On Sun, Mar 29, 2015 at 1:52 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> On 29.03.2015 19:39, Andrew Savchenko wrote:
>> On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
>>> So I would like to propose that
>>>
>>> * support for Git access through https:// is activated,
>>>
>>> * Git access through http:// and git:// is deactivated, and
>>
>> Some people have https blocked. http:// and git:// must be
>> available read-only.
>
> They would not do online banking over http, right?  Why would they run
> code with root privileges from http?
>

I don't see the point in disabling it.  Certainly we should support
ssl though.  If people want to obtain their code over http they should
be permitted to do so.  Even without using ssl it is easy to just
check that your commit hash is correct and it becomes as tamper-proof
as sha1 (tell me again why the scm of the future is still using
sha1?).

-- 
Rich

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

[Hanno Böck]

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

On Sun, 29 Mar 2015 23:35:54 +0600
"Vadim A. Misbakh-Soloviov" <mva@mva.name> wrote:

> Despite of all you're talking about is right from paranoid point of
> view, I'd, anyway, say "DO NOT DO THAT", because you propose to
> revoke the right of choice from the users.

A "right of choice" from the user only makes sense if there is a
reasonable choice.

Just to take this to the extreme: Should we add a heartbleed-enabled
version of openssl back to the portage tree? It's the choice of the
user if they want to have heartbleed enabled, right?

If there is no disadvantage for the more secure protocols then there is
no need for a choice.

> Moreover, there are some times where it is impossible to fetch
> sources via "secure" way, but you need it right here and right now.

This has been said before, also in the thread about the webpage. Can
you say what times that would be?
Basically these days it's not possible to use the mainstream internet
without https (you can't search google or log into facebook without
https).
I'd really like to hear of any real world situation where this is an
issue.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks

[Duncan]

Andrew Savchenko posted on Sun, 29 Mar 2015 21:04:52 +0300 as excerpted:

> On Sun, 29 Mar 2015 19:52:38 +0200 Sebastian Pipping wrote:
>> On 29.03.2015 19:39, Andrew Savchenko wrote:
>> > On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
>> >> So I would like to propose that
>> >> 
>> >> * support for Git access through https:// is activated,
>> >> 
>> >> * Git access through http:// and git:// is deactivated, and
>> > 
>> > Some people have https blocked. http:// and git:// must be available
>> > read-only.
>> 
>> They would not do online banking over http, right?  Why would they run
>> code with root privileges from http?
> 
> Gentoo tree access is not even near on the same security scale as online
> banking.

The point is, if the gentoo tree is compromised and you install from it, 
everything you run including that online banking is now effectively 
compromised, so it most certainly *IS* at the same security scale as that 
online banking.  Weakest link in the chain and all that...

Unless of course you use something non-gentoo for that banking, or, I 
suppose, only do updates over "trusted" wireline connections (you trust 
your ISP, your gentoo mirror and its ISP, and all backbone connections in 
between), but do online banking over public wifi with unverified and 
untrusted hotspots...


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks

[Andrew Savchenko]

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

On Mon, 30 Mar 2015 05:37:01 +0000 (UTC) Duncan wrote:
> Andrew Savchenko posted on Sun, 29 Mar 2015 21:04:52 +0300 as excerpted:
> 
> > On Sun, 29 Mar 2015 19:52:38 +0200 Sebastian Pipping wrote:
> >> On 29.03.2015 19:39, Andrew Savchenko wrote:
> >> > On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
> >> >> So I would like to propose that
> >> >> 
> >> >> * support for Git access through https:// is activated,
> >> >> 
> >> >> * Git access through http:// and git:// is deactivated, and
> >> > 
> >> > Some people have https blocked. http:// and git:// must be available
> >> > read-only.
> >> 
> >> They would not do online banking over http, right?  Why would they run
> >> code with root privileges from http?
> > 
> > Gentoo tree access is not even near on the same security scale as online
> > banking.
> 
> The point is, if the gentoo tree is compromised and you install from it, 
> everything you run including that online banking is now effectively 
> compromised, so it most certainly *IS* at the same security scale as that 
> online banking.  Weakest link in the chain and all that...

The Gentoo tree is not verified anyway: mirrors distribute it via
http, rsync and ftp. And using https for that will create a
tremendous stress on mirror's CPUs, so this is a bad approach.
Not to mention that https itself is very hapless protocol with tons
of vulnerabilities (all SSL versions are affected and most TLS
implementations).

A proper solution will be to use cryptographic verification of
downloaded files. Right now we have signed manifests and manifests
can be used to verify all other data (ebuilds, distfiles, patches
and so on). This is much more reliable solution, since it allows to
verify data integrity even for compromised data channels or any
infrastructure part not related to keys distribution or signing.

What we really need is a tool to do such verification. This is work
in progress now afaik.

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks

[Diamond]

On Mon, 30 Mar 2015 11:57:45 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:

> The Gentoo tree is not verified anyway: mirrors distribute it via
> http, rsync and ftp. And using https for that will create a
> tremendous stress on mirror's CPUs, so this is a bad approach.
> Not to mention that https itself is very hapless protocol with tons
> of vulnerabilities (all SSL versions are affected and most TLS
> implementations).
> 
> A proper solution will be to use cryptographic verification of
> downloaded files.

We should probably distinguish security of reading from Gentoo mirror
and writing to it. But for paranoid ones we probably should add the
option to read from https:// or other secured protocols too.

Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks

[Vadim A. Misbakh-Soloviov]

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

Yes, we should add possibilities, but not revoke them from user.
That is a Gentoo Philosophy.
We shouldn't enforce users to anything that, as we think, is better for them.
Even about security.

And yes, we even shouldn't forbid them to install heartbleaded openssl 
(thankfully, users is free to do that themselves from local overlays).

-- 
Best regards,
mva

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks

[Thomas Kahle]

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

On 30/03/15 10:57, Andrew Savchenko wrote:
> And using https for that will create a
> tremendous stress on mirror's CPUs, so this is a bad approach.
> Not to mention that https itself is very hapless protocol with tons
> of vulnerabilities (all SSL versions are affected and most TLS
> implementations).

This is spreading FUD.

-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 536 bytes --]

Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks

[Chí-Thanh Christopher Nguyễn]

Thomas Kahle schrieb:
> On 30/03/15 10:57, Andrew Savchenko wrote:
>> And using https for that will create a
>> tremendous stress on mirror's CPUs, so this is a bad approach.
>> Not to mention that https itself is very hapless protocol with tons
>> of vulnerabilities (all SSL versions are affected and most TLS
>> implementations).
> This is spreading FUD.
>

As far as I know this is correct.
All SSL protocol versions including v3 have known vulnerabilities.
In addition, a number implementations of TLS 1.0 and 1.1 have been found 
susceptible to the Poodle and/or FREAK attacks.

That the https protocol is hapless is maybe a pessimistic view on the 
situation. But if all were fine, why some organizations think they need 
certificate pinning again?


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks

[Hanno Böck]

On Wed, 01 Apr 2015 14:59:01 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> As far as I know this is correct.
> All SSL protocol versions including v3 have known vulnerabilities.

Yeah, but this is a pointless statement in the discussion. Nobody says
we should deploy https via sslv3. Of course if people want https they
mean "https as in 2015 https", not "https as in 199x https".

> In addition, a number implementations of TLS 1.0 and 1.1 have been
> found susceptible to the Poodle and/or FREAK attacks.

Implementation bugs that can be fixed (and are fixed).

FREAK is only an issue if you have crazy configured servers (again,
https as in 199x), POODLE TLS is only affecting some crappy proprietary
load balancers (and erlang, but nobody has proposed to use an erlang
https server).

People want to deploy pgp sigs (which is - to be clear - a good idea I
fully support). I personally found countless minor security issues in
gpg lately. Should that stop us from using pgp sigs? of course not.


And the claims about https being a performance / cpu stress horror is
also completely exaggerated. https performance is mostly a non-issue
and based on urban legends rather than benchmarks.


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42