

DigiNotar root CA trust removal follow-up - lawnchair_larry
https://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up/

======
guelo
DigiNotar's complete collapse is intriguing. Doing a little Googling I noticed
that they just got acquired 8 months ago
[http://www.vasco.com/company/press_room/news_archive/2011/ac...](http://www.vasco.com/company/press_room/news_archive/2011/acquisition_diginotar.aspx)
That investment is not looking very good for Vasco right now.

It would be interesting to know the backstory here. I wouldn't be surprised if
something about the acquisition caused all the engineers to jump ship. Their
one press release seems to be begging the Dutch government to provide staff
[http://www.sacbee.com/2011/09/02/3881380/vasco-offers-
dutch-...](http://www.sacbee.com/2011/09/02/3881380/vasco-offers-dutch-
government.html)

~~~
alastairpat
They have put out a statement[1], although it's in Dutch. Assuming Google's
translation conveys the gist and tone of it, they seem more irritated that the
browser vendors are removing the root certificates than anything else.

[1]
[http://www.diginotar.nl/Actueel/tabid/264/articleType/Articl...](http://www.diginotar.nl/Actueel/tabid/264/articleType/ArticleView/articleId/327/Default.aspx)

~~~
Michiel
This:

"Gebruikers van SSL certificaten kunnen afhankelijk van de desbetreffende
browserleverancier geconfronteerd worden met een mededeling dat het
certificaat niet vertrouwd wordt. Dit is in 99,9% van de gevallen onjuist, het
certificaat kan wel worden vertrouwd. Dit kan handmatig door de gebruiker zelf
worden aangegeven in de browser (hiervoor kunt u terecht op de FAQ op onze
website)."

Translates (roughly) to this:

Depending on the browsers a user of SSL certificates may be confronted with a
message stating the certificate is not trusted. In 99.9% of the cases this is
not correct, the certificate can be trusted. The user can do this manually
using his browser (see our FAQ).

\---

Given the situation I don't think that is the right message. I think people
should not be told that 99.9% of certificates can be trusted even though their
computer says no.

~~~
stingraycharles
That's terrible that they're saying that. You would expect a CA to be the last
person to try to educate others to ignore those warnings. It kind of
undermines their whole reason of existence.

~~~
marshray
One explanation is that they just don't understand that.

Another is that they don't give a flip about their CA business at this point
because it's just a liability to them that they wish would just go away.

If they're going to have any customer left after this it's going to be gov.nl,
who seems to prefer having a pwned CA to re-rooting their whole PKI setup.

------
SoftwareMaven
Would Mozilla (or any browser vendor) really remove them if they had 20% of
the cert market? That will be an interesting test.

~~~
jmtame
There are 3 major CAs: VeriSign (47% share), GoDaddy (23%), Comodo (15%). So
would they remove VeriSign or GoDaddy? I really doubt that, those CAs hold way
too much of the market. I guess the question is: would those big CAs make the
same mistake?

Relevant quote: "This is a nightmare scenario. You have to trust the companies
selling these certificates and if we can't, then all bets are off." —Mikko
Hyppönen, head of research at F-Secure

~~~
burgerbrain
Not only will they make mistakes, they already have.

~~~
Skalman
I think only Comodo has had a (known) breach
([http://en.wikipedia.org/wiki/Comodo_Group#Iran_SSL_certifica...](http://en.wikipedia.org/wiki/Comodo_Group#Iran_SSL_certificate_controversy)),
but it's not at all the same as with Diginotar - they informed vendors
quickly, and had a list of false certificates available.

~~~
lawnchair_larry
Symantec, who owns Verisign, has also been breached pretty badly in the past
(Aurora), which they failed to disclose. No known issues with their certs, but
still.

------
nikcub
DigiNotar should never have been a top-level CA. They should have been a
third-party CA underneath Verisign or somebody similar, with only a right to
sign and verify certain certificates.

This is how most banks are setup.

There are far, far too many trusted top-level cert CA's now. The list was 3-4
long years ago, and was designed with third-party CA's just for this reason.
Today you have a huge list and it changes every month

~~~
tptacek
You probably know something about certificates I don't, but as I understand
the code that handles this stuff, your certificate either has CA=YES or CA=NO
in its basicConstraints; if it's CA=YES, you're a CA full stop.

It's the combination of having that bit -- err, DER boolean -- set _and_
chaining to browser root cert that makes you a CA.

There isn't a provision in the scheme for them to do less than be able to sign
Google, which is why the CA system is so brittle and broken.

What is the bank setup that you're thinking about? I didn't think that
BankOfAmerica.com could sign its own certs for CNs under BankOfAmerica.com.
Our customers include large banks and they bitch about having to work with
Verisign just like everyone else.

~~~
nikcub
My experience is from 10 years ago, where I set this up for a startup I worked
at. This was the situation: we had built a platform for trade finance. It was
like eBay but for trade paper. eg. somebody is exporting $80M worth of oil,
and they need a bank to finance it. We had 500+ banks from around the world on
the platform, and they would all bid for the business.

Because we were dealing with hundreds of millions of dollars worth of
commitments, we needed a certificate architecture that would verify the
seller, the buyer, and for each of those parties to verify the site.

I went to Verisign and asked them for the best solution, and this is what they
setup:

\- we had a Verisign terminal setup in the office. This was a normal computer,
but locked down to only run Verisign software. It was a flavor of UNIX

\- the terminal had a smart-card reader on it, and a private net connection
that went only back to Verisign.

\- the authentication to login to the computer was two passwords, both with
secure tokens, and two smart cards

\- when you login, you do the ID shuffle, which involved two people who had
background checks conducted on them etc.

\- we generate a certificate, which is then signed using a sub-CA certificate
that Verisign issues to us

\- Our certificate thus acted as a CA, but it was authorized by Verisign, so
the certs that we signed would then check out using the built-in browser CA
certs

This cost us hundreds of thousands of dollars to setup, and cost us hundreds
of dollars for each cert we signed. When I did the due dilligence on the
solution, I visited 3 london-based banks who had implemented the same system.
The selling point was that we could act as a CA, but without really being a
CA.

Verisign's sales pitch was that you could never become the root CA because of
the stringent policies that had to be put in place (isolated networks, key
generation, etc.), but for the fraction of the cost, we could sign certs using
our cert which would be verified up the chain to the root CA which was
Verisign

I can't stress how secure this whole procedure was. The root CA store was the
holy grail - nobody that did't have the infrastructure or procedures like
Verisign would get anywhere near it. I now read stories 10 years later of
dodgy dutch companies with no budgets being given root CA privileges, and I am
just blown away.

If these guys needed a solution to sign certs, they should have been setup
with what we had, and what the other banks had, not just given placement in
the root cert store. Verisign would check and double-check everything we did,
and would frequently revert certs we signed where they suspected something was
wrong.

With this story it seems there was a completely amateur operation given
privileges to sign certs as part of a root CA.

I have 163 root CA certs on my OS X machine. 10 years ago I am certain the
number was 4 or 5

note: this was so long ago that I probably have some of my terminology mixed
up, but what we bought was the right to sign certs as a sub-CA of Verisign, a
privileged root CA. I also got a very cool tour of Verisign which is another
story.

~~~
tptacek
So the only thing that kept your startup from being able to mint a certificate
for *.GOOGLE.COM was the physical security of a single Unix box?

The setup you describe is actually worse than what happened with Diginotar.
There's a public record of Diginotar being added to the browser roots,
complete with audit statements tying PwC to attestations that Diginotar was
ready to be a CA. Nobody in hindsight agrees that a good decision was made
there, but at least we know it was made.

There is no way to account for Verisign signing CA=YES keys for private
companies as a convenience; we can only trust Verisign when it says "anything
we do with our private key we do with security measures adequate to the task
of protecting the entire Internet". Well, I don't want to pin the safety of
the entire Internet on Verisign's ability to secure a Unix box they don't even
have physical custody over.

Diginotar isn't what upsets me about the browser CA situation. Subordinate CAs
are.

~~~
dopo
The way I read his tale, it sounds like VeriSign may have kept the signing
keys for his intermediate CA, and their onsite secure terminal just submitted
CSRs back to VeriSign and got the signed certificates back. VeriSign was then
in a position to enforce the policy that no certs get signed for anything
outside of the domains that should be signed.

~~~
tptacek
I thought so too, but then I read "can't be a root CA because of stringent
policies, isolated networks, key generation" and felt he was writing about the
weird machine they put on their prem.

------
rwg
Mozilla's Gervase Markham posted a more detailed (and, frankly, more damning)
blog entry about the DigiNotar fiasco:

<http://blog.gerv.net/2011/09/diginotar-compromise/>

------
crististm
Nobody seems to ask why should I trust DigiNotar or Verisign or whatever? I do
not know them myself to trust them in the first place. So why should I trust
them through Mozilla? Or Google? I don't know enough to trust them either...
The whole pyramid trust scheme is broken.

~~~
bzbarsky
If you don't trust your browser, then you've already lost, since your browser
ipso facto sees the unencrypted form of all your web traffic, both incoming
and outgoing. Not only that, but it's running native code on your machine!

~~~
crististm
I agree. That's why I go mostly with open software. If I care enough I'll go
and get my hands dirty with code.

However I trust open source because people _I know_ told me they are trust-
able not because of a higher authority. I trust Amazon because friends of mine
are satisfied customers and not because Verisign says so.

~~~
bzbarsky
Sure. But one important point here: Verisign doesn't tell you to trust Amazon.

What Verisign can tell you is that you can trust that the server you're
talking to right now is in fact affiliated with Amazon (in the case of EV
certs) or corresponds to the hostname in your URL bar (in the case of regular
certs). As long as no certificates got stolen, no one mis-issues certificates,
etc....

