[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: HTTPS everywhere!

On Sun, 2014-06-22 at 14:21 +1000, Russell Stuart wrote: 
> Sure, but you are no longer discussing a PKI system here.  If you are
> going to abandon X.509 PKI
Well first of all,... PKI is just "public key infrastructure" and not
necessarily means X.509.

> , why not just use OpenPGP and just have
> apt-listbugs ensure whatever is downloaded is signed by our keyring.  It
> has the major advantage that it works across mirrors..
Well first, AFAIK, there are no mirrors for the BTS... and then securing
something like BTS with OpenPGP is quite difficult.
You'd have to sign each single message, and you'd have to build up
cryptographically signed indexes (all with valid-from/through
information to counter blocking/downgrade attacks), that give a chain of
which messages have been reported per bug... and the same for all the
bugs per package,... and the same for all packages available... and the
same for any search results made by arbitrary queries.

I don't think this is easy to do... given the nature of a bug reporting
system (i.e. that it's non distributed) I think some session
encrypting/signing like TLS does is *the* way to go here.

Anyway... apt-listbugs was just a good example of where we could use a
"Debian CA" to really secure things, which is not possible with a CA not
controlled by us.
I'd still use such "Debian CA" for any other webservice that we
provide... and even though there is RFC6091, it's (AFAIK) only
implemented by mod_gnutls and no single browser supports it.... so for
all these webservices we're definitely bound to something X.509 based.

> But I guess it depends on what you want to secure.  Perhaps were we
> depart is I don't see huge value in securing the web site.
Well first of all, security *is* usually a matter of black and white.

I mean some two years ago, people would have probably agreed in calling
me paranoid... but at least since the whole NSA scandal everyone could
really know, that even the tiniest and most obscure attack vectors are
massively used.
So just saying "we have secure APT and secure our package
building/distribution infrastructure" is not enough - attackers will
simply try to find some other place.
Sure, we never can really protect against everything, but this doesn't
mean we shouldn't try the best.

So if an attacker doesn't find an easy way to directly attack Debian or
secure APT or some maintainer - he'll probably try to attack
indirectly... via services used by DDs,... alioth, paste.debian.net, the
BTS and so on.

Imagine that some developers exchange code via alioth, one of it's https
protected services (e.g. some repo access) or paste.debian.net.
Currently it's at least much more likely to successfully attack these
services by certificate forgery - so even if it sounds perhaps
cumbersome that's the way a powerful attacker would go next.

And we know that this is done... not only by the NSA, but even by "less
capable" guys, like Iranians that forged Google Mail certs and so on.

Given that these services are used more and more for development, I
think it's more and more important to secure them as far as possible.

> > Actually one could even go a step further,... IIRC, some domain/CA
> > combinations are hardcoded in browsers like Chrome/Firefox... if that
> > infrastructure is already in place, we could probably easily add a patch
> > so that our debian.org/net are only accepted with certs from the "Debian
> > CA".
> So you want to introduce pinning.
Ah ... now I see what you meant with pinning :D

> Some browsers do that already.  For
> example, Chrome pins Google's certs.  Probably would not hurt. It's just
> a question of whether securing the web site is really worth the effort.
See above.
And pinning would only be necessary for access patterns where we cannot
simply just trust the "Debian CA"... e.g. apt-listbugs could simply just
use "Debian CA" - not possible of course with any browser.

> > Don't understand what you talk about... AFAICS you can't download any
> > netinst images via https at all.
> Hmm.  You are right.  The situation is worse than I thought.
Well I wouldn't say it's worse... if it was secured with https... it
would just be an illusion of security, since the main problem is still
whether you trust your downloading OS.
If you do, and if you have then a more or less direct trust path to the
OpenPGP used to sign the images, you're still fine.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: