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

Re: HTTPS everywhere!

On Tue, 2014-06-17 at 13:20 +0100, Simon McVittie wrote: 
> * my browser vendor doesn't trust this CA at all, and indeed my browser
>   will not let me access https sites secured with it, even though it
>   will let me  access an equally MITM-prone http version of the same
>   content
> * my browser vendor trusts this CA completely, and if it signs a
>   certificate that claims to be for paypal.com, my bank, my employer's
>   commercially confidential servers, a server with my private medical
>   information, etc. then that certificate is assumed to be genuine


* You have an "offline" certificate store, which people can choose
themselves whether and what they want to import from. Including certs
like e.g. a Debian CA.

Actually that's what I think ca-certificates should be... but under it's
current maintainer it's rather just a copy of the Mozilla bundle (which
makes me question the whole use of that package at all).
People must learn one truth: if they really want security (and I assume
this here now): noone else can/should tell them which CA to trust and
which not.
And especially just because Mozilla includes a certificate is absolutely
no sign for trustworthiness at all - for me it's rather the opposite.
Mozilla has shown at best very strange decisions on how they handle
failing CAs and which they include.
So in the end they most likely decide based on money - and of course on
some policy which however everyone can claim to fulfil,... again it's
just money that you need so that some other evaluating company (which
only visit you once and don't check you every second) says "oh yeah...
these guys fulfil your policy"

IMHO ca-certificates should have been an offline cert store with all
kinds of well known CAs... there should be not statement from the Debian
side, whether these CAs are good/evil or trustworthy... the only thing
Debian should assure is: if there's a root cert for "CAcert" in the
store... than it really belongs to those CAcert.org guys... if there's a
root cert for CERN in the store... than it's the one from the well known
LHC operator,... and not someone else.

> It should be possible to make a CA certificate that is only considered
> to be valid for the spi-inc.org and debian.org subtrees, and then trust
> the assertion that SPI control that certificate - but in widely-used
> applications, that isn't possible.
Well browsers generally fail here... as long as the system somehow works
and not too many people are cheated... no one complains.

But for scripts or things like apt-listbugs we could use that very
easily to only trust on CA.

> For less technical users who are only dimly aware of the existence of a
> thing called a certificate at all, giving SPI the technical capability
> to impersonate their bank seems an unacceptable risk.
Which is surely the reason why we won't get into the Mozilla store (well
I still bet that the actual reason is just money)... but to be honest:
the Mozialla store comes with >150 certs now (if I counted correctly)...
I'd rather entrust literally any DD with securing my online banking than
those CAs with not doing any forgery, be it intentional or because of

> If widely-deployed TLS implementations had the ability for a server to
> offer more than one certificate, there'd be no problem -
> https://security.debian.org/ could present a Gandi certificate, a SPI
> certificate and a cacert.org certificate, signed by different CAs but
> based on the same key material (and particularly paranoid browsers could
> insist on more than one being valid). That capability does not currently
> exist in practice, though.
I don't think that the SNI extensions allow for something like that
(since it's meant for some other problem)...maybe some other TLS
extension which noone bothers to implement? ^^
One "solution" is using different ports...

> [1] experts can maybe use things like Certificate Patrol, although CP
> suffers from the fact that most browsers do not warn about use of
> multiple certificates like it does
Well CP seems to be unmaintained and it has many issues (i.e. it loads
sites even if one clicks reject)... and especially because of what you
already mention:

> , which means large sites like Twitter
> assume they can deploy multiple certificates without any user-visible
> problems, which means CP has so many false positives on some sites that
> it approaches unusable


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

Reply to: