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. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature