DigiNotar Damage Disclosure (with full list of issued certs)
blog.torproject.org
blog.torproject.org
It seems likely that Diginotar will be going out of business shortly, and rightly so, but I don't think this should stop there. Their lack of communication is very troubling. Not sure what their contractual obligations are, but when supplying trusted SSL certs trust seems pretty important, so maybe it's possible to sue for damages since that trust was obviously broken?
Frankly, I'm hoping for a lot more than just damages.
Root certs for services provided to the Dutch public were compromised as they were distributed through DigiNotar. The Dutch government has entirely different root certificates and it is where they are currently handing out certificates from to fix various different services that were using the DigiNotar certs.
VASCO expects the impact of the breach of DigiNotar’s SSL and EVSSL business
to be minimal. Through the first six months of 2011, revenue from the SSL
and EVSSL business was less than Euro 100,000. VASCO does not expect that
the DigiNotar security incident will have a significant impact on the
company’s future revenue or business plans.
The CA system is broked. Everyone's known it for awhile, but man, it's still tough to look straight in the eyes at its brokenness like this.
We should, as well, be running the hell away from VASCO. At a minimum, their due diligence during the acquisition of DigiNotar was lacking. To the extent as the parent company they inherently have responsibility, they have also failed. I don't care if the acquisition is recent; in security, that's no excuse.
Their citation of the monetary figure as reason to consider the matter "minimal" could be read as a further example of their contempt and/or disregard for the responsibility they shouldered with the DigiNotar acquisition.
TL/DR: Stop saying "DigiNotar", and start saying (or also say) "VASCO".
The most egregious certs issued were for *.*.com and *.*.org
Diginotar is looking worse and worse with every revelation, which is probably why they're attempting the silent treatment. This article says "their audit trail is incomplete." Frankly, I think this should be approaching criminality, though I don't think the law has caught up to that. It's an egregious shitting-on-the-internet by Diginotar, though.
If you put two spaces at the beginning of the line, HN will ignore *asterisks*, switch to monospace, and won't wrap.Now, when you think about that, remember: the DNSSEC trust model starts with an entity that can sign anything under .COM. You can't not have that entity in DNSSEC. Now you understand one reason I think DNSSEC sucks.
*.*Tell me what you'd personally do to deal with a rumored breach or misuse of .COM?
Remember: under DNSSEC, Libya would have been BIT.LY's CA.
True, but at least it says that prominently on the tin.
Please understand this: you can stop trusting every HTTPS/SSL CA today, and, as you visit HTTPS sites, accept their keys individually.
There is absolutely no reason whatsoever for anyone to settle on this point, either with negligent corporations or with governments.
My point is the advantage here is that the name "BIT.LY" itself clearly says who you are trusting to certify that name: You are trusting ".LY". If you do not trust ".LY", you can go about your day ignoring "∗.LY" sites, and your ability to separately trust "∗.NO" is unaffected.
The fact that governments ultimately control most of these trust domains is unfortunate, but it is still nice to be able to have different trust domains. If I want to actually see the unedited propaganda of the Libyan government, then I sure as hell do trust the Libyan government the most to deliver that; conversely, I trust the US Government the most to certify that I'm actually browsing whitehouse.gov.
Such a model allows me to see when I am browsing the Libyan-government-guaranteed part of the Internet - I know that any lies I read are Libyan government lies, and if my pockets are fleeced they will be fleeced with Libyan government complicity or incompetence.
And sure, it'd be great if governments didn't have a monopoly - if there was, say, a Google-guaranteed part of the Internet too. This isn't too crucial, though: ultimately, all corporations are answerable to at least one government, that can compel the corporation to act in the interest of that government. By trusting Verisign I'm already trusting the US Government - it's just hidden.
Allowing seperate, clearly dilineated trust domains that are obvious to the user is a good idea, because it would facilitate competition between the trust anchors of those domains. If a trust domain built a reputation for highly trustable, carefully-validated certificates, it could charge a premium. A ".CH" domain as the online equivalent of a Swiss bank account? (probably not literally .CH of course, given their reputation regarding crypto).
Having those trust domains associated with governments is also reasonable: the citizens that government is answerable to can punish conspiracies and cock-ups, and all corporations are ultimately answerable to a government, so by trusting a corporation you are really trusting a government anyway.
(By the way, I am not a spear-carrier for DNSSEC - I would just like to be able to restrict the domains that a CA is able to vouch for).
If you dislike the CA model that HTTPS/SSL has, you should have your spear pointed at DNSSEC.
Like I said upthread, we probably agree regarding the current HTTPS/SSL PKI.
Remember: With or without DNSSEC Libya sets falsified MX records for bit.ly, buys a certificate (without any hacking), because after all, a valid SSL certificate for domain.example means that someone verified that you indeed receive mail for webmaster@domain.example, and also suddenly has a certificate for Bit.ly. This has been critized by Kaminsky and other researchers for ages now.
I know you love SSL. In fact, I like SSL too. But please stop advertising the CA system along with it, because it is horribly broken.
If the implication of this a claim that DNSSEC is worse than the current TLS/SSL security model with CAs, that claim is obviously false: having one entity that can sign anything under .COM is better than having three hundred of them.
If that claim is not intended, what do you suggest would be a better approach than DNSSEC?
The resolver software that ultimately makes the trust decision --- examining the RRSIG records in the response and deciding what to display or do as a result --- is running on computers under end-user control. If the end-user, or whoever maintains your browser or other software for them, decides that a particular key has probably been compromised and should not be trusted, no RFC can force their software to treat that key as valid simply because it has a valid DS from its parent zone. You can have a DNSSEC blacklist just as we have openssl-blacklist and openssh-blacklist. You can make your resolver do whatever you want.
Now, this is considerably more work than clicking around your browser's Preferences UI to delete DigiNotar's keys, but it's not as if every user has to do it themself.
However, I appreciate the information about what the DNSSEC quasi-standards say you should program your resolver to do.
In one corner, we have PKI protocol whose trust roots are configurable, so much so that every mainstream browser has point-and-click UI to change them. It so happens that this protocol is also the de facto standard with 15+ years of deployment history.
In the other corner, we have a PKI protocol that, instead of providing configurable trust, hardcodes trust into DNS names. Instead making point-and-click configuration changes, to alter the PKI roots in this scheme you'd have to "violate" the standards of one of the core Internet protocols by building and deploying a noncompliant DNS resolver.
Kragen, why on earth do you prefer the second solution to the first?
First, the existing PKI already hardcodes trust into DNS names. If Libya's registry decides vb.ly is immoral and should be redirected to a server serving up a placeholder page, Violet Blue can't make her site continue working. And they can almost certainly even obtain an X.509 certificate proving that they really do own vb.ly, so that you still get the placeholder page instead of a TLS error page even if you visit the site over https.
Second, the existing PKI grants every CA power over the entire namespace, instead of merely over the names it was established to verify. That means I can't get my intranet site to authenticate properly without granting my company the authority to MITM every site in the world.
As a result of this idiocy, recovering from trust root compromises seems to have gone from being a once-in-a-lifetime catastrophe to a yearly, even monthly catastrophe, to the point that intelligent people think it's important to have a point-and-click UI to recover from it.
The current configuration of the SSL PKI grants every CA power over the entire namespace. But that's not intrinsic to the SSL trust model.
We are zero lines of code away from a key-continuity trust model where no CA's are required for vigilant and technically qualified users. Some people call this "TOFU".
We are zero lines of code away from a cert-pinning model that uses installed based of millions of people to detect bogus certs, regardless of whether Verisign has complied with some government order to sign them.
We are tens --- literally tens --- of lines of code away from a model that cordons off parts of the CN space to specific CAs or notary servers. Don't want Thawte to have a say in whether a cert belongs to EFF.ORG? Don't want to have to depend on key continuity or cert pinning to enforce that? This level of sophistication is almost but not quite a UI feature away from completion.
None of these ideas are trivially implemented with DNSSEC. The entire design of DNSSEC militates against some of them.
Meanwhile: DNSSEC does not exist. Applications are not ready for DNSSEC. Many of them will require new revisions to function properly in a post-DNSSEC world. DNSSEC the way people-who-hate-CA's conceive of DNSSEC requires every user to run a full caching resolver on their desktop. How many people in Iran do that today? Having never been deployed "in the large", nobody knows whether DNSSEC even works.
By any reckoning, we are far more lines of code away from a working DNSSEC trust model than we are from any reasonable improvement to the HTTPS/TLS trust model, which is far more adaptable than DNSSEC (the SSL/TLS PKI has no other dependencies other than SSL/TLS trust, unlike DNSSEC, which also has to make the whole Internet work).
So I'm asking you again: why would you rather deploy DNSSEC than fix HTTPS/TLS?
Please don't say "because I don't trust all the CAs in my browser configuration" again.
As an attacker, why would you choose to limit the valid-until date on certificates you generate to a very small value? You might expect people to notice they're being MitM'd fairly fast, and the breach to be uncovered and your certs distrusted quickly, but that's not really a good reason to deliberately limit yourself.
The only sensible answer I can think of is that maybe there is some internal auditing that generating very short-duration certificates gets around?
Anyone got any better ideas?
*.*.com
*.*.org
With governments able to issue certs, as onedognight notes, there's no option of a commercial death sentence. As experiences with RIM/India and Microsoft / Google and China show, at least some governments would be able to apply sufficient pressure on software producers to be able to at least make governmental root revocation not automatic in all circumstances.
http://www.livehacking.com/2011/04/25/honest-achmeds-used-ca...
It /is/ possible to use TLS to make a genuinely good secure web. Unfortunately at the moment there isn't a strong enough economic reason to fix the current certification structure -- while fundamentally broken, it isn't broken enough in practice yet.
Something like an large ISP-level compromise of banking services using mis-issued certificates would probably incur some action.
That's been one of the key themes in Bruce Schneier's work since Applied Cryptography. In that book he laid the foundations for strong crypto. In his subsequent works, he's shown that strong crypto, inappropriately applied, isn't secure, and that security bogeymen, particularly those against which we take countermeasures which are both ineffective and expensive (and not just in financial terms) are themselves more potent risks than the real threats we face.
The real tragedy is in crippling ourselves and spending treasure fighting the phantoms while ignoring real threats and dangers.
Extended Validation CA","unknown","unknown",".SahebeDonyayeDigital.com","CN=.SahebeDonyayeDigital.com,SN=PK000229200006592,OU=Elme Bikaran,L=Tehran,O=Daneshmande Bi nazir,C=IR" "2011-07-10 22:08:31","585a8ee9017a326d21bd19dce9d9777d","DigiNotar
Extended Validation CA","unknown","unknown",".RamzShekaneBozorg.com","CN=.RamzShekaneBozorg.com,SN=PK000229200006593,OU=Sare Toro Ham Mishkanam,L=Tehran,O=Hameye Ramzaro Mishkanam,C=IR" "2011-07-10 22:11:59","aa239bf9fe84b25444be0799f40c9f67","DigiNotar
Extended Validation CA","unknown","unknown",".JanamFadayeRahbar.com","CN=.JanamFadayeRahbar.com,SN=PK000229200006594,OU=Sarbaze Gomnam,L=Tehran,O=Ke Jano Janan Toyi,C=IR"
Thankfully it seems someone already translated in the comments:
--- Translation one ---
Sahebeh Donya => Possessor of the World e.g. God.
Sarbazeh Gomnam => Unknown Soldier
Elme Bikaran => Science/Knowledge of the idle/unemployed
Daneshmande Bi nazir => Peerless Scientist
RamzShekaneBozorg => Great Cryptanalyst
Toro Ham Mishkanam => I will breakTOR too
Hameye Ramzaro Mishkanam => Will break all cyphers
---
--- Translation Two ---
Sahebeh Donya => Possessor of the World e.g. God.
Sarbazeh Gomnam => Unknown Soldier
Elme Bikaran => Science/Knowledge of the idle/unemployed
Daneshmande Bi nazir => Peerless Scientist
RamzShekaneBozorg => Great Cryptanalyst
Toro Ham Mishkanam => I will breakTOR too
Hameye Ramzaro Mishkanam => Will break all cyphers
[edited for formatting]
"The most egregious certs issued were for [asterisk].[asterisk].com and [asterisk].[asterisk].org"
I didn't know double wildcard certs were possible. This would be extremely helpful for us if that was. Anyone know?
(Just to be extra clear, we would like one cert that covers a.b.example.org as well as d.e.example.org, and hopefully also still works for a.example.org)
edit: We currently have a *.example.org cert, and while some browsers think that is valid for a.b.example.org, most do not.
=> that list is not necessarily a full list (and, given the reportedly incomplete audit trail, we may never know how long the full list is)
https://svn.torproject.org/svn/projects/misc/diginotar/rogue...
I'm on Ubuntu Linux and have applied the recent updates... but how can I be sure ?