Many thanks to the Tor folks for this disclosure, at least they (and other browser providers) are taking responsibility where Diginotar would not.
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?
From the DigiNotar press release [1] on the matter:
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.
I refrained from making this comment, before, but I guess I will now.
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".
What in the world must DigiNotar's business plan for the future include? How could anyone trust them again? How is it possible that root-level certs were being issued and they've got no warning systems, no logging to determine what actually happened? And remember, we only really know about it now because someone caught the DigiNotar-issued SSL cert floating out in the wild and put it up on Pastebin! As rhizome noted, it borders criminality (if you think about it, does it even border?). These folks told users "Users of SSL certificates can depending on the browser vendor be confronted with a statement that the certificate is not trusted. This is in 99.9% of the cases incorrect, the certificate can be trusted" & their site is full of old defacement tags (on both of these, see http://isc.sans.org/diary/DigiNotar+breach+-+the+story+so+fa... - also worth reading).
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.
The whole CA trust model is a complete mess.
I suggest interested people to google for the work from moxie marlinspike (@moxie__),
e.g., presentation from last BH (http://bit.ly/rbqMCq) and convergence (http://convergence.io/).
As a Dutch citizen, I am ashamed our own government's CA was compromised. And I'm a bit angry, because this hardly concerns just us but the entire secure web.
Frankly, I'm hoping for a lot more than just damages.
No, the Dutch root certificates were not compromised, insofar as I am aware.
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.
The most egregious certs issued were for *.*.com and *.*.org
Why is that even possible? Does it ever make sense for that to exist? If the browsers currently accept that, I wouldn't be surprised if they stop accepting that since it almost certainly means someone got ahold of certs they shouldn't have.
There is no reason that should have to be possible; it is straightforward for a browser to reject any "wildcard" certificate, and even easier to reject a cert that wants to claim all of ".com".
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.
> Remember: under DNSSEC, Libya would have been BIT.LY's CA.
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.
I don't know you, so please don't take too much offense to this, but isn't that sentiment simply batshit crazy? "Sure, DNSSEC literally bakes an implicit trust in world governments into the core security model of the entire Internet, but at least it's up front about it!"
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.
Absent manual distribution of keys, it is always the host's choice who their users must trust to verify their identity - the equivalent statement currently is "Why should anybody's choice of CA determine whether their users can trust SSL?".
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).
"Why should anyone's choice of CA determine trust" is not equivalent to "why should any site's choice of top level domain determine trust". Users control CAs. They do not control TLDs.
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.
It's also a LOT easier to recover from a key breach - you expire the old *.com certificate, and publish a new one under the root. No problem. The root key, of course, must be VERY carefully guarded - but since updates are infrequent, this can happen on an isolated system with no network connection (or even more paranoid systems, such as secret sharing schemes...)
You can recover from a breach like Diginotar's instantly; just remove their cert from your browser. You have no control over .COM's recovery from a breach.
its much worse than that, there are an unknown amount of intermediate CAs that also have this abillity. Several CAs sell these certs freely. So not only can one of the 300 CAs get compromised and totally destroy ssl security, so can a large amount of people you have _no information about at all_.
> Now, when you think about that, remember: the DNSSEC trust model starts with an entity that can sign anything under .COM.
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?
Thanks! I thought that post was silly, and it doesn't address my point. You'd do the same thing with a compromised .COM cert that you'd do with a compromised Verisign or Thawte cert, whatever that might be, because the vast majority of .COM sites are certified by one of those CAs already.
No, this is simply wrong. Individual resolvers do not get to decide whether to trust or not trust zone signatures. Signatures in DNSSEC inherently chain to the root. You are shackled to one trust hierarchy for all time. This is in stark contrast to X.509 CAs; the "300 central CA" model we have today is a mere browser configuration setting, and one virtually anyone can change.
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.
HN eats asterisks, so for everybody else in tl;dr-land: "x.x.com" and "x.x.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.
I don't know if this has been covered in one of the other threads (no obvious searches showed it up):
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?
If you're running Windows, you need to disable this root CA immediately, as you are now vulnerable to having arbitrary code run on your machine as SYSTEM if someone spoofs Windows Update.
Was just logging into the e-service portal DigiD which previously had a Government cert verified by DigiNotar. Now it's verified by Getronics PinkRoccade, a big dutch IT-services company belonging to former state-owned telco KPN.
The fact that Honest Achmed's Used Cars & Ceritficates would, if issued a root cert, be as able as any other certificate authority to issue a cert for any entity including:
*.*.com
*.*.org
... is like saying that you'll accept a US Passport issued by any country in the world, including, say, North Korea or Iran. While the crypto behind SSL/TLS is strong, the trust model is very clearly very broken.
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.
Let's be clear: the SSL/TLS protocol specifies no certification structure. This structure was built by the members of CAB in the relatively distant past.
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.
It's not sufficient to defend crypto in theory without considering how it's used in practice and what real-life threats exist as a result.
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.
"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.
It doesn't really matter if there are any other certificates we don't know about. If you don't have the Diginotar root certs block you have a problem, if you do have them blocked it's not relevant whatever else they issued.
Is there an AdBlock like community collected list of "safe" certificates that I should have in my system? Till date, I have removed COMODO, DigiNotar, but I suspect there are more.
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?