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

Re: HTTPS everywhere!

On Mon, 2014-06-16 at 18:25 +0000, Luca Filipozzi wrote: 
> But I don't expect that to be anywhere close to sufficient for other distros to
> include the Debian CA (by which you probably mean the SPI CA) into their
> certificate stores.
I didn't mean their Mozilla/NSS cert stores, if you were talking about

But it should be possible for any distro (that wants to have this) to
add some package where people can retrieve such keys/certs/etc. in a
secure way and add it to their browsers or whatever...

> I'd expect them to ask us to follow processes similar to
> Mozilla's (https://wiki.mozilla.org/CA:How_to_apply).
Well the main process that you need to do for being included in Mozilla
is giving them some big money transfer and everything's fine then.
Sure there is a pro forma policy, noone can really check whether the CAs
follow these in the real life,... and Mozilla doesn't even remove CAs
for which the public knows for sure that they didn't follow the
policies, were to incompetent to be secure, maliciously forged
certificates or are proven to be untrustworthy (just take the case
around turktrust)...
And that's the same for CA's like CNNIC, where one really can imagine
that they're untrustworthy...

>   It's not clear to me
> that either SPI or Debian are prepared to do that.  Maybe we should go with
> cacert.org... but they failed to step through the process and they're purpose
> built for CA management.
Na... CAcert is really not that secure... and 2 (or was it 3)? People
can assert an identity... and it's not that difficult to get so many
people to gether.

> From my perspective, HTTPS Everywhere and Archive Security are not the same.
Actually I don't really understand what was meant with HTTPS Everywhere
(I rather think about it as what the plugin for Firefox from EFF having
the same name does).

Archive Security is for me: Only use PKI trust hierarchies which root in
something that is Debian controlled (ideally having the people who
actually control the key in some country which doesn't have national
security letters and gag orders).

GANDI in turn seems to be France based(?) but at least they have offices
in the US... and GANDI itself is ultimately signed by AddTrust External
CA Root, which belong to Comodo IIRC, which is - surprise - US-based...
So any time any agent can send an national security letter instructing
them to forge any cert used by Debian... + gag order.

> I want to provide our end users, some of whom are not sufficiently technical to
> decipher SSL warnings/errors with the opportunity to have secure communications
> (to the extent that we can, anyway).
Well https with X.509 has inherent problems which we won't be able to
But I don't think that the typical Debian user is not capable of
understanding the systems/ideas behind CAs, hierarchical trust and e.g.
importing CAs to their browsers.

Providing security to people who don't understand security is IMHO
generally a illusion... if someone wants to communicate securely, than
he/she must read at least a bit into the stuff behind to understand
what's actually going on, what's possible and what is not.

Otherwise you have users whom you sell security but tell them to ignore
that "this is untrusted" warning, download the cert (via an untrusted
path), import it... and then things "are" secure.

(And it's not much better if people download a Debian install image from
a server that is https secured with a cert from any of the >150 CAs that
Mozilla includes...)

If we'd use however our own CA (which we control), then people who
really care (and have the knowledge that is anyway necessary to have
security) *can* have really secure communications with Debian's

And software like apt-listbugs *can* securely communicate with the
BTS... (if it only trusts that Debian CA, and not the system wide

> I rely on the GPG web of trust for
> Archive Security.  If tools need to be improved, then that's where we (or
> "them") should focus energies (and I seem to recall seeing an apt update,
> recently).
Well... agreed... but having more and more "web services" enabled,.. I
have some concerns whether we introduce holes by that.
E.g. if much development takes place on Alioth via git... but that git
accesses are secured via GANDI https (which is ultimately under the
control of our "friends" from Langley and Fort Meade),... than no one
will bother to attack your GPG and rather try to break in there.


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

Reply to: