Weekly Edition
Return to the Security page
| |||||||||||||
Certificate fraud: Protection against future "DigiNotars" (The H)
The H looks at a proposal from Google to protect against rogue or compromised certificate authorities. "[Google product manager Ian] Fette said that after that affair, other companies asked Google for a way to protect themselves against bogus certificates. As there are numerous CAs, the possibility that similar illegitimate certificates could be issued remains, explained the developer. However, Fette said that embedding the certification policy for all potential parties into browsers doesn't scale, and that he and his colleagues, Chris Evans and Chris Palmer, therefore advocate the dynamic pinning of public keys." The article goes on to look at the proposal and some complaints about it, along with an alternative based on DNSSEC.
(Log in to post comments)
Certificate fraud: Protection against future "DigiNotars" (The H) Posted Nov 17, 2011 21:54 UTC (Thu) by bjartur (guest, #67801) [Link]
Finally!
Now, if the Diginotar fiasco repeats itself, browsers can be told to ignore the genuine certificate. And overtrust in self-signed certificates can now become an even greater problem.
I'm beginning to see that encryption should be considered best-effort for others than activists who show up in key signing parties until cryptographic authentication becomes mainstream. Which it is in fact becoming in my country, with banks distributing hardware cryptographic authentication chips on debit cards.
The DANE solution is better Posted Nov 18, 2011 1:27 UTC (Fri) by Thue (subscriber, #14277) [Link]
The DANE solution of specifying the certificate in DNSSEC is better, because it also works the first time you visit a site.
That would of course require the ISPs to support DNSSEC, unless you run your own verifying resolver locally (which you should anyway).
The DANE solution is better Posted Nov 18, 2011 17:43 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Plenty of people don't like DNSSEC, and especially don't like DANE. It remains to be seen whether they can exert influence to get it killed off, or stalled indefinitely.
For the CAs a successful global PKI alternative means they're in serious trouble. Compared to the current situation where they effectively print money DANE means fighting one another for a handful of residual business in applications that aren't Internet connected.
For someone like OpenDNS it's much worse. Every aspect of OpenDNS's business depends on the lack of security in DNS. From injecting advertising to protecting people from spoof attacks, it all stops making sense with widespread deployment of DNSSEC.
So expect half-kludges to get a lot of positive feedback from such people. A real solution is not in their interests.
The DANE solution is better Posted Nov 18, 2011 18:45 UTC (Fri) by nybble41 (subscriber, #55106) [Link]
> For the CAs a successful global PKI alternative means they're in serious trouble. Compared to the current situation where they effectively print money DANE means fighting one another for a handful of residual business in applications that aren't Internet connected.
There is still a place for CAs on the public Internet, even with DNSSEC and DANE. Sure, no one will need them for the cheaper sort of certificate that only confirms that you control the domain name, but for more sensitive sites there is value in having a certificate that confirms your actual (legal) identity. That certificate, signed by one or more CAs, can then be registered with DNSSEC, guaranteeing that no other CAs can issue false certificates for your domain.
This probably will mean that browsers won't bother shipping any but the most trustworthy CA roots. There won't be as much pressure to ship the others, since you get the basic domain validation for free. There should be some difference in the UI to indicate whether the certificate merely matches the domain, or was signed by one or more trusted CAs.
The DANE solution is better Posted Nov 18, 2011 20:41 UTC (Fri) by smcv (subscriber, #53363) [Link]
> signed by one or more trusted CAs
IMO, one of the biggest problems with the CA model is that certificates can't be signed by more than one CA - you can't usefully use a particular CA to issue (say) a web server's certificate until most of your users' browsers trust it, which means the established CAs are basically the only option.
Monkeysphere would solve this, if non-geeks ever use it. DANE would also solve this, AIUI.
The DANE solution is better Posted Nov 20, 2011 2:37 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Actually, you CAN do this. You can submit a CSR (Certificate Signing Request) to several CAs without any problems.
The DANE solution is better Posted Nov 20, 2011 6:10 UTC (Sun) by nybble41 (subscriber, #55106) [Link]
Yes, but how would you include the extra signatures in SSL/TLS? As I understand it, the protocol only allows for a single issuer and signature. Getting signatures from multiple CAs is the easy part; we'd still need updates to the authentication protocol and the client software (UIs).
The fact that sites are forced to choose a *single* CA, which in turn *must* be recognized by all the major web browsers, is a major security flaw in the current system. It means that browsers have to be more lenient than they really should be when approving root certificates, since each CA is a point of failure not only for the security of the system as a whole but also for the operation of any site which depends it for validation. Multiple CAs per site would spread out the risk on both sides, allowing browsers to raise their standards without breaking large portions of the secure Web, meaning that the root certificates can be limited to organizations that are actually *trusted* for real-world identification, rather than ones that simply have not been proved *untrustworthy* (yet).
The DANE solution is better Posted Nov 20, 2011 10:29 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
I don't think it really helps.
Suppose you operate a site, foo.example. Under the present regime, you buy a cert from one of a dozen or more major SSL certificate companies (yes there are many more root CAs, but lots are effectively duplicates, and some are special purpose, even though they're authorised to issue certificates for any domain technically, operationally they were never supposed to)
Under your revised regime, you can now buy one of those certs (which will actually work in people's browsers, without one your site might as well not exist for the general public) and in addition, optionally, other certs that don't work because no browser will trust them. Why would you do the latter?
You might think "Ah, the browser vendors will differentiate on SSL acceptance". But that won't happen because it's a race to the bottom. For users security is just an annoyance, and the browser which accepts the most CAs is the "best" browser because it is least annoying.
Under DNSSEC + DANE, every web browser can tell you whether this is the genuine foo.example and refuse to connect if not, leaving only the much more familiar and easily understood problem of "Do I trust foo.example?". And if the people running the example TLD are incompetent or criminal, we have an easily explainable problem, "Don't trust .example" instead of having to rush to retro-fit software deployed to hundreds of millions of machines.
The DANE solution is better Posted Nov 20, 2011 21:06 UTC (Sun) by nybble41 (subscriber, #55106) [Link]
> Under your revised regime, you can now buy one of those certs (which will actually work in people's browsers, without one your site might as well not exist for the general public) and in addition, optionally, other certs that don't work because no browser will trust them. Why would you do the latter?
First, this is intended to work in addition to DNSSEC/DANE, so it's not really true that "your site might as well not exist"--the certificate provides real-world identify verification for your domain, nothing more. Anyone who already knows that they have the correct domain name doesn't need the certificate.
Because of this, browsers won't have as much pressure to include every possible CA in the list of built-in roots. If your site's CA isn't among the browser's root, it's not the end of the world--you still have DANE, so your users just need to be more careful about which domain they're connecting to.
As a result, if you want identify verification (to protect against phishing, etc.), you'll need at least one CA which is acceptable to all the major browsers, assuming there is such a CA. Having more than one CA allows you to maintain that protection even if one of the CAs loses its trusted status, an important point given the heightened standards.
On the flip side, with basic privacy and domain authentication provided by DANE, CA certification should be more competitive, and probably less expensive.
|
|||||||||||||