Comments on: The DigiNotar Hack, Black Tulips, Rogue Certificates and what You´re not Being Told about PKI and Risk

By: Joerg Resch

Joerg Resch — Thu, 15 Sep 2011 10:15:12 +0000

Thanks, Robert.
I think we shouldn´t look at us humans to be the weakest link. We are more kind of the reason for security needs Typical human behavior should be part of the security design, not one of it´s risks.
Joerg

By: robert

robert — Wed, 14 Sep 2011 18:36:34 +0000

Aren't humans almost every-time the weakest link ? Whatever scheme is created there will always be a weak spot.
I hope that a combination of CA, DNSsec and DANE will prove a better alternative for the current situation. That would create three parallel checks. And somehow a second DNS check to confirm the validity of the main DNS server might also be a good thing. (I think)

Robert

By: Joerg

Joerg — Fri, 09 Sep 2011 17:43:25 +0000

Thanks for your comment, Frank.
Yes, the presentation of Moxie Marlinspike is very interesting, and Giovanni´s blog entry as well. I left the following message there:

I still believe that convergence is a first step into the right direction. A small step technically, a big step regarding CA business models.
Let´s have one more look at the DigiNotar case. Some hacker penetrated their whole infrastructure and issued over 500 rogue certificates. DigiNotar did not disclose this “incident” and therefore those rogue certificates were fully trusted ones. The hacker seems to live in Iran and support the regime there. Maybe more kind of self-employed than being a paid “digital soldier”. Nevertheless, Iran on the one hand wants to control communication of the political opposition and on the other hand would love to strike back as a revenge for the SCADA attack against their atomic program. We are facing a period with a high amount of “rogue energy”.
SSL, DNSSEC and whatever else we currently do for Information security and privacy on the Internet is not designed to withstand this kind of attacks.
Trust relationships need to be based on “crowd intelligence” and they need to be agile also in a way that trust levels appropriate to the protected process can be defined.

Notaries for the Convergence system are not existing yet. The more participate, the better Convergence will be. The opposite to the CA system we have now: The more CAs the higher the risk.

By: Frank Brückner

Frank Brückner — Fri, 09 Sep 2011 15:02:50 +0000

Hmmm, is convergence really the solution ? I installed it in a test environment. There are 2 notaries configured: "notary.thoughtcrime.org" and "notary2.thoughtcrime.org". Why should I trust them more than Comodo or DigiNotar ?

There is exactly 1 CA where I know a little how they (and their Web-of-trust) operates. And that's CAcert. But they are not pre-installed in the browsers.

BTW: It is worth to look at http://www.youtube.com/watch?v=Z7Wl2FW2TcA and http://giovanni.bajo.it/2011/09/is-convergence-re… .

Frank

By: Joerg

Joerg — Thu, 08 Sep 2011 17:57:36 +0000

Hi, Yes, that´s the solution. And it is already invented: http://convergence.io/index.html . It´s called Convergence and currently works as a browser plugin which lets you decide yourself which CAs to trust. If we add the upcoming DNS Security Extensions to this new kind of distributed trust, then we´re much closer to something more future-proof. Joerg

By: Joerg

Joerg — Thu, 08 Sep 2011 17:29:19 +0000

Dear Peter,
thanks for your comment. Yes indeed, issuing certificates may be even more profitable than printing money, because you don´t need to buy paper. And yes, a fundamental weakness of the entire SSL PKI system lies in the fact, that _any_ CA can corrupt the whole infrastructure. On the other side, if the authorization to issue a certificate for a certain domain is limited to a certain CA, then the owner of that one domain should do a prayer every day that his certificate provider is a good one.
Joerg

By: @netsociology

@netsociology — Thu, 08 Sep 2011 10:23:49 +0000

"Wouldn´t it be better if the trust decisions are left to the users, without any influence?"

Of course – if the user is able to make a good decision. But who is? Is this a model for the average user? One should be skeptical.

By: peter bachman

peter bachman — Thu, 08 Sep 2011 00:05:37 +0000

I've been thinking about how to solve this ever since I read the EFF Observatory report regarding CAs and their complex multiple cross certified trust relationships.

It's a multi-trillion dollar hang over from the dot com boom when the CAs decided to engineer their own approach to X.509v3 without a corresponding link to the verified identity of the certificate issuers in the X.500 Directory, i.e. self signed roots or "zombie roots" stored in browsers. If the CA is "too big to fail" then there's yet another problem, which won't be resolved by removing them from a trusted list for browsers.

Not surprisingly, if one goes back and reads the actual documentation on X.509v3 the problem becomes clear. The certificate "subject" identity is established in the X.500 Directory, to support and verify the same subject attribute in the certificate issued by the CA. It would be pretty simple to determine that DigiNotar would not be authoritative for *.google.com, or in the case of the forged Comodo certificates earlier. Note there is a difference between a trusted certificate, falsely issued, or forged, and a stolen certificate.

The certificate is an independent security object, portable, but the identity for the issuance of that is in the Directory, which case it can be listed under the PKICA object.

If identity is verified in the Directory, and some funding for infrastructure is found similar to ICANN, then it's not too late. It still won't excuse sloppy security by a CA if they don't report a breach, especially when they see the OCSP requests, but it would be pretty simple to figure out who is responsible for *.google.com and query that CA to determine if the certificate is genuine. It's only part of the puzzle, but an important part that should be present. Right now the end user would is forced to look inside the certificate, and then add the OCSP server CRL endpoint to their browser configuration. I actually had Verisign refuse a certificate for ietf.org the other day.