The state-level attack on the SSL CA security model

To my surprise, I did not see a mention in this community of the
latest proof of the complete failure of the SSL CA model to actually
do what it is supposed to: provide security, rather than a false sense
of security.

Essentially a state somewhere between Iraq and Pakistan snatched valid
certs for:
- mail.google.com
- www.google.com
- login.yahoo.com
- login.skype.com
- addons.mozilla.org
- login.live.com
- "global trustee"

https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion
http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
http://www.imperialviolet.org/2011/03/18/revocation.html (on epic
failure of cert revocation lists implementations in browsers, failing
open (!))
http://blog.mozilla.com/security/2011/03/22/firefox-blocking-fraudulent-certificates/
http://www.microsoft.com/technet/security/advisory/2524375.mspx

For over a week users of browsers, and the internet at large, were/was
not informed by COMODO that their security was compromised. "Why not"
is beyond many of us. Announcing this high and loud even before fixes
were available would not have exposed more users to threats, but less.
Conclusion: protecting people must not be a priority in the SSL CA
model.

In some places, failure of internet security means people die, and it
is high time to start serious work to replace this time-and-time again
proven flawed model with something that, at the very least, does not
fail this tragically.

DNSSEC is a good but insufficient start in this particular case.

Regards,
Martin

An argument against doing this prior to fixes being available is that miscreants who didn't know about this previously would be alerted to the possibility of using one of these certs (assuming they could get their hands on one) in conjunction with name resolution manipulation.

Note that announcing this prior to fixes would've dramatically increased the resale value of these certificates in the underground economy, making them much more attractive/lucrative.

> Announcing this high and loud even before fixes were available would not have exposed more users to threats, but less.

An argument against doing this prior to fixes being available is that miscreants who didn't know about this previously would be alerted to the possibility of using one of these certs (assuming they could get their hands on one) in conjunction with name resolution manipulation.

The fix here is to delete the compromised UID and revoke the certs, thats done immediately, then inform the public, no reason to wait after that. IF the speculations about a specific nation is true then there is a risk that people there run real (like physical) risks by using e.g. yahoo the last few days. They would have appreciated being informed.

Note that announcing this prior to fixes would've dramatically increased the resale value of these certificates in the underground economy, making them much more attractive/lucrative.

Why? Surely the value of stolen certs are higher if the public do not know that they exist.

/Joakim

A wider swathe of interested parties would know of their existence, and their existence would be officially confirmed, which would make them more valuable.

Unfortunately, the general public neither know, understand, or care about such things. They happily click 'I Understand the Risks' or whatever the button says in their browsers of choice to accept self-signed certificates all the time.

I don't know enough details of what actually transpired to have an actual opinion on the Comodo situation one way or another; but I can see both sides of the argument.

* Roland Dobbins:

A wider swathe of interested parties would know of their existence,
and their existence would be officially confirmed, which would make
them more valuable.

This is at odds with what happens in other contexts. Disclosure
devalues information.

To my surprise, I did not see a mention in this community of the
latest proof of the complete failure of the SSL CA model to actually
do what it is supposed to: provide security, rather than a false sense
of security.

This story strikes me as a success - the certs were revoked immediately, and it took a surprisingly short amount of time for security fixes to appear all over the place.

> In some places, failure of internet security means people die

Those people know that using highly visible services like gmail and skype is asking to be exposed...

I'd hardly call the fact that it required manual blacklist patches to every browser a "success". SSL is a failure if real revocation requires creating a patch for browsers and relying on users to install it.

Harald Koch <chk@pobox.com> writes:

It would have been much easier if certificate revocation actually worked
properly.

http://www.imperialviolet.org/2011/03/18/revocation.html

Tony.

The point is that the 'short amount of time' should have been zero (from
the time of the update of the CRL) which would have allowed an immediate
announcement of the revocation to the public, with sufficient details for
the public to make educated decisions about their internet usage.

But because the CRL publication did not facilitate that, due to whatever
deficiency there existed in the procotol or in browser implementations,
announcement had to be delayed, providing a small group of attackers a
larger window than necessary to compromise information.

if speculation is true, then all bets are off, and telling anyone
isn't necessarily going to help those under the thumb of the
speculated attacker....

just sayin!

(also, vote now, vote often for dane-wg to get it's work done...
dns-sec secured key fingerprints for ssl certs)

Which is especially funny since Comodo is citing the fact that they've
had no OCSP requests for the bad certs as evidence that they haven't
been used.

--Richard

I think this case is different, given the perception of the cert as a 'thing' to be bartered.

Isn't there any law that obliges company to disclose security breaches that involve consumer data?

I don't think SSL certs are consumer data, per se.

Back on original point - if the *actual effective* model of browser
security is browsers with an internal revoked cert list - then there's
a case to be made that a pre-announcement in private to the browser
vendors, enough time for them to spin patches, and then widespread
public discussion is the most responsible model approach. The public
knowing before their browser knows how to handle the bad cert isn't
helpful, unless you can effectively tell people how to get their
browser to actually go verify every cert.

To my surprise, I did not see a mention in this community of the
latest proof of the complete failure of the SSL CA model to actually
do what it is supposed to: provide security, rather than a false sense
of security.

This story strikes me as a success - the certs were revoked immediately, and
it took a surprisingly short amount of time for security fixes to appear all
over the place.

In some places, failure of internet security means people die

Those people know that using highly visible services like gmail and skype is
asking to be exposed...

This is definitively not true. There is no evidence of the active use
of these services (or circumvention systems to reach them) being used
as evidence or an indication that a particular target should be
detained, threatened or punished, in Iran in particular and actually
globally. I say this, because such evidence would actually reinforce
some security recommendations that I and other human rights groups
have made, so I'm always on the look out for it.

On the other hand, both gmail and Skype are used by many individuals
on the assumption that they are more secure than the alternatives
(non-SSL protected webmail or those with servers in local
jurisdictions; unencrypted instant messaging clients). You can argue
about whether these tools *are* more protective, but you certainly
can't say that these high-risk groups use them on the understanding
they can expect the same level of knowledge or retribution by their
adversaries than if these systems were openly surveillable.

A security breach like this makes the details of specific
communications readable, which also places people who do *not* use
these tools at far more risk also.

I'm personally not yet convinced that the attackers in this case were
the Iranian state; that's something that is incredibly hard to
ascertain, and I'm surprised Comodo were so quick to draw this
conclusion. Even if these attacks came from Iran, that could be for
false flag reasons, plus as others have pointed out, criminals have as
much interest in obtaining these certificates as the Iranian state --
although factions within the Iranian government could certainly be
potential clients. Other states might have an interest too. Just
because you have an organisation with CA authority within the reach of
a government doesn't mean you'd want to use those signing powers when
dealing with dissidents.

The arguments on NANOG about why non-disclosure in this case might
have been a good idea I think contribute to the debate.

Nonetheless, I'd strongly urge anyone not to assume that activists and
journalists at physical risk in states like Iran assume that risk by
using specific tools, or that major (if temporary) failures in the PKI
structure don't put them and their colleagues at far greater risk.

Best,

d.

Danny O'Brien,
Committee to Protect Journalists

* Roland Dobbins:

Disclosure devalues information.

I think this case is different, given the perception of the cert as
a 'thing' to be bartered.

Private keys have been traded openly for years. For instance, when
your browser tells you that a web site has been verified by "Equifax"
(exact phrasing in the UI may vary), it's just not true. Equifax has
sold its private key to someone else long ago, and chances are that
the key material has changed hands a couple of times since.

I can't see how a practice that is completely acceptable at the root
certificate level is a danger so significant that state-secret-like
treatment is called for once end-user certificates are involved.

No. In the case of a remote exploitable hole in the client OS I agree, then the user can do nothing and will benefit if there is a patch before the knowledge of the problem is spread. But in this case it is a security hole in the server side. IF users are informed they can avoid using the service and thus avoid the risk. (And if the risk is to be on the wrong end of a stick, at least I would appreciate a warning.)

So what about a general warning that secure communication with site X, Y and Z could be compromised? Maybe even a big warning on the sites themself to give a warning before you login? (It could be removed by a 'man in the middle', but it would spread the word.)

I wonder why that didn't happen..

/J

Again, I don't know enough about what happened to form an opinion one way or another. I'm just setting forth some reasons which spring to mind for not announcing this immediately, that's all.

What other choice does the public have? By locking them into the current trust model (for good or bad), the community has created this mess.

Is it far fetched to supplement the existing system with a reputation based model such as PGP? I apologize if this was discussed before.