XPost: linux.debian.bugs.dist

Control: tags -1 patch

Scott Kitterman <[email protected]> writes:

On January 8, 2016 12:26:24 PM EST, Russ Allbery <[email protected]> wrote:

Scott Kitterman <[email protected]> writes:

As is currently being discussed on #debian-devel, the git:// protocol
is insecure, but is what is normally used in Vcs-git fields in Debian
packages.

For git, it would be far better to used https://, but I don't think
policy is completely clear that is OK since it says to use the
"version control system's conventional syntax". For git, that's
arguably git:// even though it's a security risk.

Please see the attached patch. Although the diff is slightly noisy,
the patch only adds one word.

I would rather add a new sentence saying that ideally the URL should
use a secure transport mechanism. Right now, with this rephrasing, it
sort of implies that if there's no encrypted transport, you shouldn't
use this field. It used to be that serving Git over HTTPS was a huge
pain and disabled a bunch of features, so some folks may just not have
bothered to ever set that up.

Sounds good to me. My proposal was an attempt at a minimal change. I
think what you're suggesting is better.

Here's a proposed diff for this. I avoided using the ambiguous term
"secure" in favor of "confidentiality," which I think is the security
property we're aiming for here. ("Integrity protection" is even more desirable, but confuses matters since the Git protocol does arguably
provide that even over git:// and Git repositories can provide that other
ways, such as with signed tags.)

Seconds?

--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -962,6 +962,10 @@ repository where the Debian source package is developed.

More than one different VCS may be specified for the same package.

+For both fields, any URLs given should use a scheme that provides +confidentiality (``https``, for example, rather than ``http`` or ``git``)
+if the VCS repository supports it.
+
.. _s-f-Package-List:

``Package-List``

--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On Wed, Aug 23 2017, Russ Allbery wrote:

--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -962,6 +962,10 @@ repository where the Debian source package is developed.

More than one different VCS may be specified for the same package.

+For both fields, any URLs given should use a scheme that provides +confidentiality (``https``, for example, rather than ``http`` or ``git``) +if the VCS repository supports it.
+
.. _s-f-Package-List:

``Package-List``

Seconded, but I think the integrity protection is a more important
reason to avoid the git protocol or http, so if we can come up with a
further change to reflect that it would be better.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAlmfPZ0ACgkQaVt65L8G YkBZDRAAhyCY0z2qE/WJPMP2dD6r5Dbcooe8FkrP240vBvbYxYEE3qti/Cp3+elF wSdqbTGw9RsLqgCOdjK2IQR5F+jXqduSL7yLvV2/99rL7mZAcVDnMHhUHtO8oPCx GwQLFROGejBXziIFV88rA5FgRxfO31vz+MTHXUI03nU+gCynpHucE5ki97C+qcn2 Sz3JCs4IS3+yA3maZlP4vOBVPgS/fibS8fDacwNtrZGo62EulSIUBc4IwZJNDsLb 9UJbae+U0maGVx3NBokIXoQrj6PY7F64DIAvf68hnSbxxmgJ19DvvjsVi4yHEHUe g8v/NdAI4JIpk87kLeUXz/cGge7U6u15X1eB27/cLUCOwIFXKMtbfqhyHeo+35DE eSZweDkIWnO7OGHLgk5gmQt3Hdq0XLQ8D8/+q8/hjEeXgavdG/6UHWhzov6mOqzy t5f2HSDjQj2Xzp6TqS6hbKLp6wgZlsmQ2zLeMhQcYFMugch61M1kV3tGgEWIkZ4J eHmfQVL1q+4+i3O7nlBOV0EAAqsWj1XjvodP8Foi6G8Cqbmyz4sVqnkyFK6KOTpe PA72Qi6SOdWLuZSdcUhSEDZdA8ImTXa9PJ+Nx21PxdcjD4UmH5JEIuoAJfXZ7Kiq y8D18qqmZDaPQ4uSo+AleYIbmN/d2AKCEBoRQDvNkpXvKqS+L0o=dGPz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

Sean Whitton <[email protected]> writes:

On Wed, Aug 23 2017, Russ Allbery wrote:

--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -962,6 +962,10 @@ repository where the Debian source package is developed.

More than one different VCS may be specified for the same package.

+For both fields, any URLs given should use a scheme that provides
+confidentiality (``https``, for example, rather than ``http`` or ``git``) >> +if the VCS repository supports it.
+
.. _s-f-Package-List:

``Package-List``

Seconded, but I think the integrity protection is a more important
reason to avoid the git protocol or http, so if we can come up with a
further change to reflect that it would be better.

Maybe I should just say:

a scheme that provides confidentiality and integrity protection

I think I was over-thinking it.

(That said, my understanding is that you don't get any meaningful
integrity protection for Git from using https over http.)

--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

Henrique de Moraes Holschuh <[email protected]> writes:

On Thu, 24 Aug 2017, Sean Whitton wrote:

Seconded, but I think the integrity protection is a more important
reason to avoid the git protocol or http, so if we can come up with a
further change to reflect that it would be better.

Attacking the integrity of the messages in transit requires active MITM attacks for all three protocols (http, https, git).

https *without* strong certificate validation has no defense against
active MITM, i.e. it does *not* protect message integrity against
attacks.

And since all of the required PKI for https to do strong certificate validation is out-of-band, we have to assume naive https use.

So, no, this is not about integrity. It is, at most, about privacy
against passive eavesdropers. If you want integrity, a lot more is
needed.

Right, exactly.

That said, the *scheme* still offers "integrity protection" in the
technical protocol sense (it protects against the tampering of messages
between the two endpoints of the protocol scheme), so we can say confidentiality and integrity protection in the Policy language. People
just shouldn't assume this provides any meaningful integrity protection in
the semantic sense.

--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On Thu, 24 Aug 2017, Sean Whitton wrote:

Seconded, but I think the integrity protection is a more important
reason to avoid the git protocol or http, so if we can come up with a
further change to reflect that it would be better.

Attacking the integrity of the messages in transit requires active MITM
attacks for all three protocols (http, https, git).

https *without* strong certificate validation has no defense against
active MITM, i.e. it does *not* protect message integrity against
attacks.

And since all of the required PKI for https to do strong certificate
validation is out-of-band, we have to assume naive https use.

So, no, this is not about integrity. It is, at most, about privacy
against passive eavesdropers. If you want integrity, a lot more is
needed.

--
Henrique Holschuh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On Wed, Aug 23, 2017 at 09:20:39PM -0700, Russ Allbery wrote:

--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -962,6 +962,10 @@ repository where the Debian source package is developed.

More than one different VCS may be specified for the same package.

+For both fields, any URLs given should use a scheme that provides +confidentiality (``https``, for example, rather than ``http`` or ``git``) +if the VCS repository supports it.
+

seconded, though I wouldnt mind a rewording to "…a scheme with better confidentiallity…" ot some such. but then, the important bit is that we recommend
https here…


--
cheers,
Holger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBWZ/qNgkauFYGmqocAQrsYg//fQEV/gQtacQoWx4wA4c0JwNDHRUEXNiT vbvYFYNz2tU/cuM27v1DBJxknKzV0nH7E+VVQ2SwXcAswjKiB7vgG98e1Vz6qm7H LB48utMUuVZCU9Ye8qfOdPxNwl8jIvfL7m2ZG/ui0j8oH3AYOOGEtoWYAHKiHGff yFbIFb6xEc7sIXZkKY887suDp2Dx+yxBldWnj76wv0sZh8QdujUd3vbFRa17qMWF EnZV32dDzMsekg+HU6ga4GRE2uqWmjIlRkiPHjujcHjuOqq8ElYnhL/uz4kILfpm MP4nLPnOc77QSNFhRYGTZ2RkIVA7juFXWQbJ59pLac7ZG3NJ2ueOXqmFr9walTWh nkyy0xfB+aXVT0It3bFglEFg3vX/2S68rIflvbtbSULABFJ/mI7bGef2LsV6+aty hLe1QaH89H0S67wuswxoDpVxPoI3ggf4ezwRp0b0Ov0qC9eQMyY/BEgeIITwXpRX NeSyiIAGwDgY1QhxeRv/NfI4tI+5UgU178RwHBhsLt+yGs4YCRWa17MpWXC7r1R0 JzfR5E5U3rQ8pZzGiKWYLI5OkzDaYRqXJ/s36hB9EFhoxR5K+z3JRC2i5cnz2dD7 6UHFXrXJO3h3YgA8DNSeStGXFmIzXojhONEQ9TV7lK4EdccA7sqrFIjXS0i00X5t
brseDphnvK8=
=3S3m
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

Russ Allbery wrote:

Sean Whitton <[email protected]> writes:

On Wed, Aug 23 2017, Russ Allbery wrote:

--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -962,6 +962,10 @@ repository where the Debian source package is developed.

More than one different VCS may be specified for the same package.

+For both fields, any URLs given should use a scheme that provides
+confidentiality (``https``, for example, rather than ``http`` or ``git``) >>> +if the VCS repository supports it.
+
.. _s-f-Package-List:

``Package-List``

[...]

Maybe I should just say:

a scheme that provides confidentiality and integrity protection

Seconded.

I think I was over-thinking it.

(That said, my understanding is that you don't get any meaningful
integrity protection for Git from using https over http.)

As discussed elsewhere in this thread, it depends on how much you
trust (a) ca-certificates, versus (b) DNS.

The ideal is to use signed tags and check them. (Or even better, to
work with git upstream to get push certs distributed properly and
check those.)

It would be nice to get something like chromium's certificate pinning
into curl, but that's a separate topic.

Thanks,
Jonathan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

Jonathan Nieder <[email protected]> writes:

Russ Allbery wrote:

(That said, my understanding is that you don't get any meaningful
integrity protection for Git from using https over http.)

As discussed elsewhere in this thread, it depends on how much you
trust (a) ca-certificates, versus (b) DNS.

FWIW, we're talking about integrity protection at different levels here,
which has made this a bit confusing. You're talking about authentication
of the remote server so that you don't get valid commits (in the sense
that they fit into the Git hash tree) that aren't present in the real
remote server. I was talking about integrity protection at the wire
protocol level (detection of bit flips in transit, that sort of thing),
which Git will generally do for you regardless of transport by checking
the hashes of objects, although I'm not sure if it does a full integrity
check on all remote packs.

Protocol-level integrity protection doesn't help if you negotiate that
protocol with the wrong peer, obviously, and preventing that is rather
outside the scope of the text we're fiddling with here.

But this is all picking nits -- HTTPS provides both confidentiality and integrity protection as wire protocol features, so we can just say that
the protocol should provide those things, regardless of the somewhat
pedantic point about whether that integrity protection is meaningful for
Git.

--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

Jonathan Nieder wrote:

Russ Allbery wrote:

On Wed, Aug 23 2017, Russ Allbery wrote:

--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -962,6 +962,10 @@ repository where the Debian source package is developed.

More than one different VCS may be specified for the same package. >>>>
+For both fields, any URLs given should use a scheme that provides
+confidentiality (``https``, for example, rather than ``http`` or ``git``) >>>> +if the VCS repository supports it.
+
.. _s-f-Package-List:

[...]

Maybe I should just say:

a scheme that provides confidentiality and integrity protection

Seconded.

I think I was over-thinking it.

(That said, my understanding is that you don't get any meaningful
integrity protection for Git from using https over http.)

As discussed elsewhere in this thread, it depends on how much you
trust (a) ca-certificates, versus (b) DNS.

Correction: even if you trust DNS, you also have to trust IP
infrastructure to ensure your traffic goes to the intended destination
without a MITM modifying it. That means that even with trustworthy
DNS (e.g. using dnssec), if your ISP is compromised then you have
neither meaningful confidentiality protection nor meaningful integrity protection over http, beyond what your version control system provides
at the application level.

A good VPN can improve on that, depending on the destination of your
traffic. But given all the above, I have to say, https really does
seem like a meaningful improvement.

All that said, the other points still apply:

The ideal is to use signed tags and check them. (Or even better, to
work with git upstream to get push certs distributed properly and
check those.)

These two approaches can protect integrity but do not help with confidentiality.

It would be nice to get something like chromium's certificate pinning
into curl, but that's a separate topic.

Something like this (or a revamping of ca-certificates) is needed for confidentiality in the presence of a MITM.

And I agree with you that policy doesn't need to get into these details.

Thanks,
Jonathan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

Jonathan Nieder <[email protected]> writes:

C. You have transport-level integrity protection, e.g. by using a
protocol like https:// or ssh:// with proper PKI.

I think it's worth being honest with ourselves here that the proper PKI
part is not really happening with the Vcs-Git field (or Vcs-Browser for
that matter) in normal usage in the context of Debian packages and random remote hosts.

The bar to the attacker is not zero when https with normal public CAs is
in use, but it's not very high.

I'm fine with including integrity protection in the protocol description anyway, but hopefully no one will think that it implies that https is
providing strong authentication of the Git server here. There's non-zero authentication, but it's pretty weak.

--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

Russ Allbery wrote:

Jonathan Nieder <[email protected]> writes:

Russ Allbery wrote:

(That said, my understanding is that you don't get any meaningful
integrity protection for Git from using https over http.)

As discussed elsewhere in this thread, it depends on how much you
trust (a) ca-certificates, versus (b) DNS.

FWIW, we're talking about integrity protection at different levels here, which has made this a bit confusing. You're talking about authentication
of the remote server so that you don't get valid commits (in the sense
that they fit into the Git hash tree) that aren't present in the real
remote server. I was talking about integrity protection at the wire
protocol level (detection of bit flips in transit, that sort of thing),
which Git will generally do for you regardless of transport by checking
the hashes of objects, although I'm not sure if it does a full integrity check on all remote packs.

I replied privately in more detail (since this is mostly off-topic for
policy), but it's probably useful to clarify a few things publicly,
too.

Indeed, you're right that Git's application-level protocol protects
against cosmic rays and single-bit flips for all objects transfered.
In protocols like git:// and the CGI-based http:// support, this is
guaranteed by the way the protocol works. If there are any holes in
this protection (e.g. the support for non-dynamic protocols like
ftp:// and static http:// used to have such a bug) then we consider
that a serious bug and would want to know about it so it can be fixed.
Feel free to contact me at [email protected] for more details.

By integrity I was referring to something different: protection
against *malicious* manipulation of the response, by a MITM or other
hostile actor. Git does not guarantee this unless one of the
following holds:

A. You have learned the name of the commit or tag you are interested
in in a reliable way out-of-band. That is, if you check out the
revision to be built by SHA-1 instead of by ref name, then Git
intends to guarantee that what you check out is reliably
determined by that SHA-1.

B. You use signed tags or push certs to verify that you are checking
out what you intend. E.g. you can do this by using "git tag -v"
to verify that the code you are checking out was (1) signed by
someone you trust and (2) actually refers to the version you want.
Make sure to pay attention to the output to avoid "replay" attacks
(i.e. trying to pass off an old vulnerable tagged version of a
package for a modern fixed version). Or

C. You have transport-level integrity protection, e.g. by using a
protocol like https:// or ssh:// with proper PKI.

If people are expecting Git to guarantee that the code you fetch is
what you intended to fetch without (A), (B), or (C), then we are doing
users a dangerous misservice. I am concerned about where that
expectation comes from and want to do what I can to improve
documentation to avoid that. Feel free to contact me at [email protected] to help.

Protocol-level integrity protection doesn't help if you negotiate that protocol with the wrong peer, obviously, and preventing that is rather outside the scope of the text we're fiddling with here.

I disagree: one of the main goals of HTTPS and the basis for its
support for confidentiality and integrity is avoiding communicating
with the wrong peer.

But this is all picking nits -- HTTPS provides both confidentiality and integrity protection as wire protocol features, so we can just say that
the protocol should provide those things, regardless of the somewhat
pedantic point about whether that integrity protection is meaningful for
Git.

Agreed.

Thanks,
Jonathan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

Russ Allbery wrote:

Jonathan Nieder <[email protected]> writes:

C. You have transport-level integrity protection, e.g. by using a
protocol like https:// or ssh:// with proper PKI.

I think it's worth being honest with ourselves here that the proper PKI
part is not really happening with the Vcs-Git field (or Vcs-Browser for
that matter) in normal usage in the context of Debian packages and random remote hosts.

The bar to the attacker is not zero when https with normal public CAs is
in use, but it's not very high.

There's no point in continuing to discuss this here. I'll respond
privately in case you want to pursue it.

I'm fine with including integrity protection in the protocol description anyway, but hopefully no one will think that it implies that https is providing strong authentication of the Git server here. There's non-zero authentication, but it's pretty weak.

Without authentication, you don't have confidentiality either. That's
how this comes up in the policy language: I don't understand why https
would be better or worse at providing confidentiality versus integrity.

One kind of authentication is that HTTPS protocol gives you some
assurance that the peer who first responded to is the same as the peer
for the rest of the connection. That's enough to deter an unreliable
MITM or a passive MITM.

Jonathan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)