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