Re: git and https

2015-05-30 Thread Paul Wise 
On Fri, May 29, 2015 at 8:21 PM, Riley Baird wrote:

> If having to manually add a CA annoys the Ubuntu developers that
> much, then surely they could just include the Debian CA certificate to
> Ubuntu's default?

Steve answered the Ubuntu part, but there is also the "etc" people;
there are myriad operating systems, people who discover our website
for the first time probably are using a browser that only trusts mafia
certs.

> Anyway, I don't see the point in using both mafia CAs and non-mafia
> CAs. If you get the mafia CAs, you'll still be paying the extortion
> money regardless of whether or not you use the non-mafia CAs.

The point would be that people who don't trust the mafia CAs can pin
*.debian.org domains to a Debian CA (verified via OpenPGP
web-of-trust, say) by specifying a specific subdomain of each service,
debca.www.debian.org or pin.www.debian.org or non-mafia.debian.org for
eg.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gitrj9dews+ex-pkcett9mul489jkgffmwpsnph1i...@mail.gmail.com

Re: git and https

2015-05-30 Thread Henrique de Moraes Holschuh 
On Fri, 29 May 2015, Russ Allbery wrote:
> Philipp Kern  writes:
> > Perfect is the enemy of good. Debian is already paying the protection
> > money at this point and TBH I don't understand the resistance to add
> > and promote the https:// variant of it. We can still switch to Let's
> > Encrypt once it is available.
> 
> I don't object to promoting https.  I do think we should be careful about
> what claims we make about MITM protection, since I believe https without

There is also traffic analysis.  This is something that https and TLS in
general *cannot fix*, depending on just what you are trying to hide. And git
won't make it any easier for TLS to resist traffic analysis, either.

It won't leak passords or other such low-level details, but trying to hide
high level details such as the fact that it is a git session, or which
repository you are working on out of a *known* set?  Don't bet your life on
it.

> certificate pinning does not provide real MITM protection.  It does,
> however, raise the bar against casual eavesdropping if you're already
> having to pay the CA cartel for other reasons, and that's worthwhile.

That's correct, and for the *specific* case of git over https, most of the
typical collateral damage of enabling https is not relevant: git is already
quite hard to scale on the server side, and its network bandwidth usage is
not relevant so making it impossible to cache is not going to matter.

There is, however, the minor detail that you will be more vulnerable to
being remotely exploited by a rogue server, rogue client or MITM attacker.

This is no theory: we have fixed issues in openssl that would allow exactly
that to happen.  It is also likely to happen again because TLS is such an
utter nightmare to implement safely.

OTOH, it would only matter when attacking the TLS layer of a git connection
would let an attacker into a system partition that makes no other use of
TLS/https other than git-over-https... thus it is only a "minor detail".

-- 
  "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 Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150530183614.ga30...@khazad-dum.debian.net

Re: git and https

2015-05-30 Thread Riley Baird 
> > > > > > If we can use a Debian-specific CA, we can do cert pinning, since 
> > > > > > we're
> > > > > > then assuming we have some control over the client.  I was assuming 
> > > > > > a
> > > > > > general client where we'd have to play nice with the normal CA 
> > > > > > roots.
> 
> > > > > Then we would constantly get complaints from Ubuntu/etc
> > > > > developers/users about why Debian uses invalid certs, as we did before
> > > > > Debian moved to mafia certs. Unfortunately I don't think it is
> > > > > possible to use both mafia CAs and non-mafia CAs without adding say a
> > > > > lot of non-mafia subdomains, like non-mafia.www.debian.org.
> 
> > > > If having to manually add a CA annoys the Ubuntu developers that
> > > > much, then surely they could just include the Debian CA certificate to
> > > > Ubuntu's default?
> 
> > > It is my understanding that no, Ubuntu could not, because Ubuntu ships
> > > firefox; and one of the things that's disallowed by Mozilla when using the
> > > firefox trademark is extending the set of trusted CAs (for actually rather
> > > good reason).
> 
> > I just looked at the Ubuntu ca-certificates package in vivid, and it
> > ships the SPI certificate:
> > /usr/share/ca-certificates/spi-inc.org/spi-cacert-2008.crt
> 
> Yes, because that's the ca-certificates package from Debian.  But the
> firefox package does not trust those certificates.
> 
> > Does Firefox in Ubuntu use this certificate, or does it only accept
> > certificates in /usr/share/ca-certificates/mozilla?
> 
> Firefox doesn't use any certificates from the ca-certificates package.  It
> uses the CAs that are bundled in the upstream source.

Ah, okay. Thanks for letting me know.


pgpedegzUm3jf.pgp
Description: PGP signature

Re: git and https

2015-05-29 Thread Steve Langasek 
On Sat, May 30, 2015 at 11:52:02AM +1000, Riley Baird wrote:
> > > > > If we can use a Debian-specific CA, we can do cert pinning, since 
> > > > > we're
> > > > > then assuming we have some control over the client.  I was assuming a
> > > > > general client where we'd have to play nice with the normal CA roots.

> > > > Then we would constantly get complaints from Ubuntu/etc
> > > > developers/users about why Debian uses invalid certs, as we did before
> > > > Debian moved to mafia certs. Unfortunately I don't think it is
> > > > possible to use both mafia CAs and non-mafia CAs without adding say a
> > > > lot of non-mafia subdomains, like non-mafia.www.debian.org.

> > > If having to manually add a CA annoys the Ubuntu developers that
> > > much, then surely they could just include the Debian CA certificate to
> > > Ubuntu's default?

> > It is my understanding that no, Ubuntu could not, because Ubuntu ships
> > firefox; and one of the things that's disallowed by Mozilla when using the
> > firefox trademark is extending the set of trusted CAs (for actually rather
> > good reason).

> I just looked at the Ubuntu ca-certificates package in vivid, and it
> ships the SPI certificate:
> /usr/share/ca-certificates/spi-inc.org/spi-cacert-2008.crt

Yes, because that's the ca-certificates package from Debian.  But the
firefox package does not trust those certificates.

> Does Firefox in Ubuntu use this certificate, or does it only accept
> certificates in /usr/share/ca-certificates/mozilla?

Firefox doesn't use any certificates from the ca-certificates package.  It
uses the CAs that are bundled in the upstream source.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: git and https

2015-05-29 Thread Riley Baird 
> > > > If we can use a Debian-specific CA, we can do cert pinning, since we're
> > > > then assuming we have some control over the client.  I was assuming a
> > > > general client where we'd have to play nice with the normal CA roots.
> 
> > > Then we would constantly get complaints from Ubuntu/etc
> > > developers/users about why Debian uses invalid certs, as we did before
> > > Debian moved to mafia certs. Unfortunately I don't think it is
> > > possible to use both mafia CAs and non-mafia CAs without adding say a
> > > lot of non-mafia subdomains, like non-mafia.www.debian.org.
> 
> > If having to manually add a CA annoys the Ubuntu developers that
> > much, then surely they could just include the Debian CA certificate to
> > Ubuntu's default?
> 
> It is my understanding that no, Ubuntu could not, because Ubuntu ships
> firefox; and one of the things that's disallowed by Mozilla when using the
> firefox trademark is extending the set of trusted CAs (for actually rather
> good reason).

I just looked at the Ubuntu ca-certificates package in vivid, and it
ships the SPI certificate:
/usr/share/ca-certificates/spi-inc.org/spi-cacert-2008.crt

Does Firefox in Ubuntu use this certificate, or does it only accept
certificates in /usr/share/ca-certificates/mozilla?


pgpk4tADfXSCP.pgp
Description: PGP signature

Re: git and https

2015-05-29 Thread Russ Allbery 
Philipp Kern  writes:

> Perfect is the enemy of good. Debian is already paying the protection
> money at this point and TBH I don't understand the resistance to add
> and promote the https:// variant of it. We can still switch to Let's
> Encrypt once it is available.

I don't object to promoting https.  I do think we should be careful about
what claims we make about MITM protection, since I believe https without
certificate pinning does not provide real MITM protection.  It does,
however, raise the bar against casual eavesdropping if you're already
having to pay the CA cartel for other reasons, and that's worthwhile.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87617bjbxw@hope.eyrie.org

Re: git and https

2015-05-29 Thread Philipp Kern 
On Thu, May 28, 2015 at 04:40:52PM -0700, Russ Allbery wrote:
> I'm fine with locking the doors.  I'm not fine with paying protection
> money to a Mafia goon who claims they'll lock your windows, and sort of
> sometimes does.  It's the extortion component that pisses me off about
> HTTPS.

Perfect is the enemy of good. Debian is already paying the protection
money at this point and TBH I don't understand the resistance to add
and promote the https:// variant of it. We can still switch to Let's
Encrypt once it is available.

If there had been a standard for client-side pinning in the system libs
that could be preloaded that would've been awesome as well. But alas,
Chrome does it but nothing else. Let's hope that there will be
Let's Encrypt ease of use for the client-side as well at some point.
Something that takes care of the pesky details for you and then could
be adjusted to check TLSA et al securely instead.

At work we encrypt everything these days. Even Debian packages. It
raises the bar even if it's obviously not perfect security in any way in
this specific case. Of course with the sponsorship of bandwidth for the
mirror network it does not make much sense there…

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: git and https

2015-05-29 Thread Steve Langasek 
On Fri, May 29, 2015 at 10:21:09PM +1000, Riley Baird wrote:
> On Fri, 29 May 2015 13:55:31 +0800
> Paul Wise  wrote:

> > > If we can use a Debian-specific CA, we can do cert pinning, since we're
> > > then assuming we have some control over the client.  I was assuming a
> > > general client where we'd have to play nice with the normal CA roots.

> > Then we would constantly get complaints from Ubuntu/etc
> > developers/users about why Debian uses invalid certs, as we did before
> > Debian moved to mafia certs. Unfortunately I don't think it is
> > possible to use both mafia CAs and non-mafia CAs without adding say a
> > lot of non-mafia subdomains, like non-mafia.www.debian.org.

> If having to manually add a CA annoys the Ubuntu developers that
> much, then surely they could just include the Debian CA certificate to
> Ubuntu's default?

It is my understanding that no, Ubuntu could not, because Ubuntu ships
firefox; and one of the things that's disallowed by Mozilla when using the
firefox trademark is extending the set of trusted CAs (for actually rather
good reason).

Even if this were permissible to do while shipping firefox, it's not
something that Ubuntu would entertain lightly.  You can make a case that
because Ubuntu derives much of its code from Debian, Debian is already
"ultimately trusted" and there is no reason that this should not extend to
inclusion of a CA.  However, CAs are tricky things with lots of
poorly-understood requirements around their management, and I don't think
Ubuntu would want to enable such a CA without some additional assurances
about the kinds of CA-specific things that don't obviously fall out from
Debian's already excellent archive management practices.  The only thing
worse than trusting one exploitable CA regime in your OS is trusting *two*
exploitable CA regimes in your OS.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: git and https

2015-05-29 Thread Russell Stuart 
On Fri, 2015-05-29 at 22:21 +1000, Riley Baird wrote:
> > LetsEncrypt will save us!
> 
> I just looked that up. What a wonderful idea!

I don't know how you missed it.  My tongue has been hanging out for a
year now.  Finally, sanity prevails.

A https cert is supposed to certify www.someone.com is the person who
controls the servers managing www.someone.com.  Traditionally, the
certifiers have relied on business names, trademarks, directors names -
all sorts of things that have one thing in common - they don't actually
prove you control www.someone.com.  The more things unrelated to whether
you controlled www.someone.com they asked you to prove, the more they
charged for the certificate.  If you wanted an example of marketing
triumphing over engineering, the CA system is it.

LetsEncrypt is a pure embodiment of the "you control it you own it"
principle.

They could do better.  A lot better.  For example they could insist you
control www.someone.com for a while - say repeatedly confirm over a
month.  This would thwart the guy who took over www.hotmail.com for a
while [0].  And they could allow people to register an interest in
someon.com or someon.co, so if someone registered a cert with it they
would know.

Regardless, when LetsEncrypt works we will have made a step forward.



[0] 
http://news.cnet.com/Good-Samaritan-squashes-Hotmail-lapse/2100-1023_3-234907.html
Fortunately for Microsoft it was a Linux nutter.  When he couldn't
access his hotmail account he diagnosed it, registered the domain,
and then gave it back to Microsoft.



signature.asc
Description: This is a digitally signed message part

Re: git and https

2015-05-29 Thread Riley Baird 
On Fri, 29 May 2015 13:55:31 +0800
Paul Wise  wrote:
> On Fri, May 29, 2015 at 7:40 AM, Russ Allbery wrote:
> 
> > I'm fine with locking the doors.  I'm not fine with paying protection
> > money to a Mafia goon who claims they'll lock your windows, and sort of
> > sometimes does.  It's the extortion component that pisses me off about
> > HTTPS.
> 
> LetsEncrypt will save us!

I just looked that up. What a wonderful idea!

> > If we can use a Debian-specific CA, we can do cert pinning, since we're
> > then assuming we have some control over the client.  I was assuming a
> > general client where we'd have to play nice with the normal CA roots.
> 
> Then we would constantly get complaints from Ubuntu/etc
> developers/users about why Debian uses invalid certs, as we did before
> Debian moved to mafia certs. Unfortunately I don't think it is
> possible to use both mafia CAs and non-mafia CAs without adding say a
> lot of non-mafia subdomains, like non-mafia.www.debian.org.

If having to manually add a CA annoys the Ubuntu developers that
much, then surely they could just include the Debian CA certificate to
Ubuntu's default?

Anyway, I don't see the point in using both mafia CAs and non-mafia
CAs. If you get the mafia CAs, you'll still be paying the extortion
money regardless of whether or not you use the non-mafia CAs.


pgpA630kssrel.pgp
Description: PGP signature

Re: git and https

2015-05-28 Thread Paul Wise 
On Fri, May 29, 2015 at 7:40 AM, Russ Allbery wrote:

> I'm fine with locking the doors.  I'm not fine with paying protection
> money to a Mafia goon who claims they'll lock your windows, and sort of
> sometimes does.  It's the extortion component that pisses me off about
> HTTPS.

LetsEncrypt will save us!

> If we can use a Debian-specific CA, we can do cert pinning, since we're
> then assuming we have some control over the client.  I was assuming a
> general client where we'd have to play nice with the normal CA roots.

Then we would constantly get complaints from Ubuntu/etc
developers/users about why Debian uses invalid certs, as we did before
Debian moved to mafia certs. Unfortunately I don't think it is
possible to use both mafia CAs and non-mafia CAs without adding say a
lot of non-mafia subdomains, like non-mafia.www.debian.org.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6hwjhs3mhehesnkyeijp_yemfp6qpiiucc-rbpyx3t...@mail.gmail.com

Re: git and https

2015-05-28 Thread Russ Allbery 
Clint Byrum  writes:
> Excerpts from Russ Allbery's message of 2015-05-27 22:23:02 -0700:

>> If you aren't doing certificate pinning, I don't think you can really say
>> this with a straight face.

> The word is "avoids", it is not "eliminates". What ever happened to
> defense in depth? There's no such thing as a perfect solution, but we
> can at least lock the doors, right?

I'm fine with locking the doors.  I'm not fine with paying protection
money to a Mafia goon who claims they'll lock your windows, and sort of
sometimes does.  It's the extortion component that pisses me off about
HTTPS.

> In the specific case where we'd recommend using https:// instead of
> git:// _for Debian's git services_, the cost noted above would not apply
> for any Debian users because in theory we can use the Debian-specific
> CA.

If we can use a Debian-specific CA, we can do cert pinning, since we're
then assuming we have some control over the client.  I was assuming a
general client where we'd have to play nice with the normal CA roots.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oal4xocb@hope.eyrie.org

Re: git and https

2015-05-28 Thread Clint Byrum 
Excerpts from Russ Allbery's message of 2015-05-27 22:23:02 -0700:
> Josh Triplett  writes:
> 
> > https:// avoids MITM;
> 
> If you aren't doing certificate pinning, I don't think you can really say
> this with a straight face.
> 

The word is "avoids", it is not "eliminates". What ever happened to
defense in depth? There's no such thing as a perfect solution, but we
can at least lock the doors, right?

> It makes MITM moderately harder, at the cost of giving money to a bunch of
> exploitative clowns who have no concept of what security means.
> 

In the specific case where we'd recommend using https:// instead of git://
_for Debian's git services_, the cost noted above would not apply for
any Debian users because in theory we can use the Debian-specific CA.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1432852719-sup-2...@fewbar.com

Re: git and https

2015-05-28 Thread Tollef Fog Heen 
]] Russ Allbery 

> Also, for people coming from Debian hosts talking to the Debian
> infrastructure, at least in theory we *could* do certificate pinning,
> which transforms HTTPS into a worthwhile security protocol.  It's not
> exactly trivial to work out the UI and integration problems, and it
> doesn't help for people not coming from a Debian system (at least as
> much), but it might be worth considering.

HTTPS already has various ways to do cert pinning via standard protocol
headers (and preloading), so if git were enhanced to support those, we
could use them (and possibly ship the pinning info in git/a supporting
package).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87h9qwqvpi@xoog.err.no

Re: git and https

2015-05-28 Thread Jeremy Stanley 
On 2015-05-28 09:33:35 +0200 (+0200), Roland Mas wrote:
> I understand that behemoths such as Iceweasel may take some time
> to move, but maybe Git could be made to use the TLSA records in
> DNSSEC? Postfix does make use of them, and SSH uses their SSHFP
> cousins, so it's not completely an abstract idea.

Pick your poison. I'm a fan of DANE (RFC 6698, DNSSEC+TLSA) for this
as well, but there are plenty of people hanging their hopes on HPKP
(RFC 7469, key pinning) along with CT (RFC 6962, certificate
transparency). If you rely on DNSSEC then you're trusting the
governments with control over jurisdictions where the DNS root keys
are managed not to MitM you by fabricating signed resolution chains
down to a TLSA record with the cert they want you to see. It all
depends on which tinfoil hat you find most comfortable.
-- 
Jeremy Stanley


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150528155421.go2...@yuggoth.org

Re: git and https

2015-05-28 Thread Russ Allbery 
Roland Mas  writes:

>   I understand that behemoths such as Iceweasel may take some time to
> move, but maybe Git could be made to use the TLSA records in DNSSEC?
> Postfix does make use of them, and SSH uses their SSHFP cousins, so it's
> not completely an abstract idea.

> Roland,
> who spent some time DNSSECing his infrastructure and hoping it'll be
> worth it in due time.

Yeah, that would be really cool.

Also, for people coming from Debian hosts talking to the Debian
infrastructure, at least in theory we *could* do certificate pinning,
which transforms HTTPS into a worthwhile security protocol.  It's not
exactly trivial to work out the UI and integration problems, and it
doesn't help for people not coming from a Debian system (at least as
much), but it might be worth considering.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zj4ozoqq@hope.eyrie.org

Re: git and https

2015-05-28 Thread Wouter Verhelst 
On Thu, May 28, 2015 at 10:30:58AM +0200, Tollef Fog Heen wrote:
> ]] Wouter Verhelst 
> 
> > - Most importantly, you need to configure your webserver and SSL library
> >   so it disables outdated protocol versions, enables newer secure
> >   protocol versions (doing so in a way that older proprietary clients
> >   who don't speak those newer versions yet and make up the majority of
> >   your target audience aren't excluded), and a whole bunch of other
> >   things.
> 
> We should make sure the defaults shipped here are up to date with latest
> security practices, IMO.  And yes, I think we should update those in
> security updates too.
> 
> [...]
> 
> > In contrast, gpg just requires you to generate a key, and configure git
> > to use it. That's it. Yes, preferably you'd get that key signed by
> > someone else so you're part of the web of trust, but that isn't a
> > prerequisite (that is, you can start signing today, and worry about
> > getting your key added to the WoT later). Explaining how to do that can
> > be done in a fairly short web page.
> 
> You mean, apart from telling it to use sha256 for sigs, etc?

And telling it to use a large enough key using the correct encryption
algorythm. That's something more easily documented than doing the SSL
stuff, though. The advantage of gpg is that people are less likely to
run 10-year-old versions that require a trade-off between "do it safely"
and "make sure everyone who cares can use it".

(less of a problem for git as opposed to random websites, I suppose, but
still)

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150528084853.ga26...@grep.be

Re: git and https

2015-05-28 Thread Tollef Fog Heen 
]] Wouter Verhelst 

> - Most importantly, you need to configure your webserver and SSL library
>   so it disables outdated protocol versions, enables newer secure
>   protocol versions (doing so in a way that older proprietary clients
>   who don't speak those newer versions yet and make up the majority of
>   your target audience aren't excluded), and a whole bunch of other
>   things.

We should make sure the defaults shipped here are up to date with latest
security practices, IMO.  And yes, I think we should update those in
security updates too.

[...]

> In contrast, gpg just requires you to generate a key, and configure git
> to use it. That's it. Yes, preferably you'd get that key signed by
> someone else so you're part of the web of trust, but that isn't a
> prerequisite (that is, you can start signing today, and worry about
> getting your key added to the WoT later). Explaining how to do that can
> be done in a fairly short web page.

You mean, apart from telling it to use sha256 for sigs, etc?  IIRC, the
defaults for GPG aren't very appropriate either.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87mw0pqf25@xoog.err.no

Re: git and https

2015-05-28 Thread Roland Mas 
Russ Allbery, 2015-05-27 22:23:02 -0700 :

> Josh Triplett  writes:
>
>> https:// avoids MITM;
>
> If you aren't doing certificate pinning, I don't think you can really say
> this with a straight face.
>
> It makes MITM moderately harder, at the cost of giving money to a bunch of
> exploitative clowns who have no concept of what security means.

  I understand that behemoths such as Iceweasel may take some time to
move, but maybe Git could be made to use the TLSA records in DNSSEC?
Postfix does make use of them, and SSH uses their SSHFP cousins, so it's
not completely an abstract idea.

Roland,
who spent some time DNSSECing his infrastructure and hoping it'll be
worth it in due time.
-- 
Roland Mas

Indépendant en informatique libre -- Free software freelance
http://www.gnurandal.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zj4pma0g@placard.fr.eu.org

Re: git and https

2015-05-28 Thread Wouter Verhelst 
On Wed, May 27, 2015 at 12:20:03PM +0100, Rebecca N. Palmer wrote:
> >Why? Which attack do you envision[...]that would
> >be thwarted by https but not by signed commits?
> I don't; I see https as easier and hence more likely to actually get used in
> practice.

Well, on that we disagree then, I suppose. Sure, https is easy to set
up. But setting it up *right*? Not so much.

- You need to get a certificate, which costs money.
- You need to ensure that the certificate is replaced every so often
  (preferably before its expiration date), which requires procedures to
  be set up
- Most importantly, you need to configure your webserver and SSL library
  so it disables outdated protocol versions, enables newer secure
  protocol versions (doing so in a way that older proprietary clients
  who don't speak those newer versions yet and make up the majority of
  your target audience aren't excluded), and a whole bunch of other
  things.

Especially the latter is a bit of a black art, that can't really be
taught and that you can only learn by doing, and failing a bunch of
times. The ssllabs website can help you a bit, mostly by telling you
when you're doing it wrong, but it doesn't give you the whole story.

In contrast, gpg just requires you to generate a key, and configure git
to use it. That's it. Yes, preferably you'd get that key signed by
someone else so you're part of the web of trust, but that isn't a
prerequisite (that is, you can start signing today, and worry about
getting your key added to the WoT later). Explaining how to do that can
be done in a fairly short web page.

How is any of that harder than the SSL stuff?

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


signature.asc
Description: Digital signature

Re: git and https

2015-05-27 Thread Russ Allbery 
Josh Triplett  writes:

> https:// avoids MITM;

If you aren't doing certificate pinning, I don't think you can really say
this with a straight face.

It makes MITM moderately harder, at the cost of giving money to a bunch of
exploitative clowns who have no concept of what security means.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87pp5l5l8p@hope.eyrie.org

Re: git and https

2015-05-27 Thread Dimitri John Ledkov 
On 27 May 2015 at 23:00,   wrote:
> On Wed, May 27, 2015 at 10:44:17PM +0100, Dimitri John Ledkov wrote:
>> On 27 May 2015 at 09:08, Wouter Verhelst  wrote:
>> > On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett 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
>> >>
>> >> https:// is actually just as efficient as git:// these days (other than 
>> >> the
>> >> minor overhead of TLS, which is worth it for security).
>> >
>> > Why? Which attack do you envision (other than the ridiculous "the NSA 
>> > would see
>> > that we're pushing!", which they can by just doing a git clone too) that 
>> > would
>> > be thwarted by https but not by signed commits?
>> >
>>
>> It fails The Dissident Test, hence we should use https or ssh for
>> cloning. And provide only those methods.
>>
>> Overall we should default to protect the privacy of DDs, contributors
>> and our users. I was pondering for some time if we should add that to
>> DFSG or maybe have a GR about it.
>
> The security of a program is orthogonal to its licensing; let's not mix
> the two.  I agree that we should push for TLS, but that's not a DFSG
> matter.

Dunno, it's blurry to me. Shall we remove telnet?! Shall we not?!
Server / client / both?! A lot of times I view lack of privacy as
RC-buggy. Anyway, we are digressing.

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/canbhlujh7jv549srljexzcyik4rsy1shcmzlh6exp2p3owd...@mail.gmail.com

Re: git and https

2015-05-27 Thread Dimitri John Ledkov 
On 27 May 2015 at 09:08, Wouter Verhelst  wrote:
> On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett 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
>>
>> https:// is actually just as efficient as git:// these days (other than the
>> minor overhead of TLS, which is worth it for security).
>
> Why? Which attack do you envision (other than the ridiculous "the NSA would 
> see
> that we're pushing!", which they can by just doing a git clone too) that would
> be thwarted by https but not by signed commits?
>

It fails The Dissident Test, hence we should use https or ssh for
cloning. And provide only those methods.

Overall we should default to protect the privacy of DDs, contributors
and our users. I was pondering for some time if we should add that to
DFSG or maybe have a GR about it.

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANBHLUgejgSnwJbAh01gEeULyV6iEOQp=tc8jrfc+zd8czd...@mail.gmail.com

Re: git and https

2015-05-27 Thread josh 
On Wed, May 27, 2015 at 10:44:17PM +0100, Dimitri John Ledkov wrote:
> On 27 May 2015 at 09:08, Wouter Verhelst  wrote:
> > On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett 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
> >>
> >> https:// is actually just as efficient as git:// these days (other than the
> >> minor overhead of TLS, which is worth it for security).
> >
> > Why? Which attack do you envision (other than the ridiculous "the NSA would 
> > see
> > that we're pushing!", which they can by just doing a git clone too) that 
> > would
> > be thwarted by https but not by signed commits?
> >
> 
> It fails The Dissident Test, hence we should use https or ssh for
> cloning. And provide only those methods.
> 
> Overall we should default to protect the privacy of DDs, contributors
> and our users. I was pondering for some time if we should add that to
> DFSG or maybe have a GR about it.

The security of a program is orthogonal to its licensing; let's not mix
the two.  I agree that we should push for TLS, but that's not a DFSG
matter.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150527220056.GA23152@cloud

Re: git and https

2015-05-27 Thread Josh Triplett 
On Wed, May 27, 2015 at 10:08:35AM +0200, Wouter Verhelst wrote:
> On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett 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
> > 
> > https:// is actually just as efficient as git:// these days (other than the
> > minor overhead of TLS, which is worth it for security).
> 
> Why? Which attack do you envision (other than the ridiculous "the NSA would 
> see
> that we're pushing!", which they can by just doing a git clone too) that would
> be thwarted by https but not by signed commits?

My comment was regarding https:// versus git:// , not https:// versus
"git:// plus signed commits".  Most repositories do not use signed
commits.  And even for those that do, how many people cloning the
repository actually check the key used for the signatures?

https:// avoids MITM; with git://, it'd be quite possible to MITM a git
clone and feed out subtly altered code (for instance, burying a rootkit
installer in the build system scripting).  And when you consider that
many people will pull but never push, and no *automatic* process checks
the identity of the key used to sign commits/tags, such alteration might
not be noticed very quickly, especially for repositories where the
developers (who do push) use ssh.

Beyond that, https:// also supports secure authentication, and https://
hides *which* repository and objects are being accessed (particularly
useful for large git hosting sites).

I hope to one day see a complete absence of unencrypted traffic.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150527160230.GA1068@jtriplet-mobl1

Re: git and https

2015-05-27 Thread Rebecca N. Palmer 

Why? Which attack do you envision[...]that would
be thwarted by https but not by signed commits?
I don't; I see https as easier and hence more likely to actually get 
used in practice.


Telling users to use the existing https:// instead of git:// is a simple 
change to the wiki; enabling https on a server that doesn't currently 
have it is...I don't know exactly, but I'm guessing along the lines of 
"get a certificate and change a few settings".  Using signed commits 
requires every committer to do so.


Also, for casual users (e.g. bug reporters being asked "does that still 
happen in latest git?" [0]), https gets checked automatically, while 
signatures are only checked on user request [1].


(Is there a git option for "check signatures on every pull"? 
commit.gpgSign appears to be "sign my own commits".)


[0] policy at e.g. http://nouveau.freedesktop.org/wiki/Bugs/
[1]
~$ git clone https://anonscm.debian.org/git/gnuk/gnuk/gnuk.git
Cloning into 'gnuk'...
remote: Counting objects: 10559, done.
remote: Compressing objects: 100% (2969/2969), done.
remote: Total 10559 (delta 7709), reused 10296 (delta 7519)
Receiving objects: 100% (10559/10559), 11.77 MiB | 299.00 KiB/s, done.
Resolving deltas: 100% (7709/7709), done.
Checking connectivity... done.
~$ cd gnuk
~/gnuk$ git checkout release/1.1.4
Note: checking out 'release/1.1.4'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at e7e8b9f... version 1.1.4
~/gnuk$ git tag -v release/1.1.4
object e7e8b9f5ca414a5c901f61b0f043c8da42414103
type commit
tag release/1.1.4
tagger NIIBE Yutaka  1418623147 +0900

version 1.1.4
gpg: Signature made Mon 15 Dec 2014 05:59:07 GMT using RSA key ID 4CA7BABE
gpg: Can't check signature: public key not found
error: could not verify the tag 'release/1.1.4'
~/gnuk$ git tag -v release/1.1.4 --keyring 
/usr/share/keyrings/debian-keyring.gpg

error: unknown option `keyring'
usage: [...]


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5565a863.4000...@zoho.com

Re: git and https

2015-05-27 Thread Chow Loong Jin 

On Wed, May 27, 2015 at 10:08:35AM +0200, Wouter Verhelst wrote:
> On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett 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
> > 
> > https:// is actually just as efficient as git:// these days (other than the
> > minor overhead of TLS, which is worth it for security).
> 
> Why? Which attack do you envision (other than the ridiculous "the NSA would 
> see
> that we're pushing!", which they can by just doing a git clone too) that would
> be thwarted by https but not by signed commits?

How about "the NSA would see that I'm cloning the repository of a bunch of
cracking tools?" Not sure how legal that is in the US, but I'm pretty certain
it's illegal in some region somewhere.

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Re: git and https

2015-05-27 Thread Wouter Verhelst 
On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett 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
> 
> https:// is actually just as efficient as git:// these days (other than the
> minor overhead of TLS, which is worth it for security).

Why? Which attack do you envision (other than the ridiculous "the NSA would see
that we're pushing!", which they can by just doing a git clone too) that would
be thwarted by https but not by signed commits?

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150527080835.ga20...@grep.be

Re: git and https

2015-05-25 Thread Josh Triplett 
> 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

https:// is actually just as efficient as git:// these days (other than the
minor overhead of TLS, which is worth it for security).  See "man
git-http-backend" for details on the "smart" HTTP protocol, which uses
the same protocol as git:// .

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150525183805.GA2452@x

Re: git and https

2015-05-25 Thread Henrique de Moraes Holschuh 
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 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1432573901.624401.277617881.5b46d...@webmail.messagingengine.com

git and https

2015-05-25 Thread Rebecca N. Palmer 
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


Any suggestions for persuading upstreams to care about these issues? 
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



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55631103.3020...@zoho.com