An insecurity in OpenID, not many dead

Back in May it was realised that, thanks to an ill-advised change to some random number generation code, for over 18 months Debian systems had been generating crypto keys chosen from a set of 32,768 possibilities, rather than from billions and billions. Initial interest centred around the weakness of SSH keys, but in practice lots of different applications were at risk (see long list here).

In particular, SSL certificates (as used to identify https websites) might contain one of these weak keys — and so it would be possible for an attacker to successfully impersonate a secure website. Of course the attacker would need to persuade you to mistakenly visit their site — but it just so happens that one of the more devastating attacks on DNS has recently been discovered; so that’s not as unlikely as it must have seemed back in May.

Anyway, my old friend Ben Laurie (who is with Google these days) and I have been trawling the Internet to determine how many certificates there are containing these weak keys — and there’s a lot: around 1.5% of the certs we’ve examined.

But more of that another day! because earlier this week, Ben spotted that one of the weak certs was for Sun’s “OpenID” website, and that two more OpenID sites were weak as well (by weak we mean that a database lookup could reveal the private key!)

OpenID, for those who are unfamiliar with it, is a scheme for allowing you to prove your identity to site A (viz: provide your user name and password) and then use that identity on site B. There’s a queue of people offering the first bit, but rather less offering the second : because it means you rely on someone else’s due diligence in knowing who their users are — where “who” is a hard sort of thing to get your head around in an online environment.

The problem that Ben and I have identified (advisory here), is that an attacker can poison a DNS cache so it serves up the wrong IP address for openid.sun.com. Then, even if the victim is really cautious and uses https and checks the cert, their credentials can be phished. Thereafter, anyone who trusts Sun as an identity provider could be very disappointed. There’s other attacks as well, but you’ve probably got the general idea by now.

In principle Sun should make a replacement certificate and that should be it (and so they have — read Robin Wilton’s comments here). Except that they need to put the old certificate onto a Certificate Revocation List (CRL) because otherwise it will still be trusted from now until it expires (a fair while off). Sadly, many web browsers, and most of the OpenID codebases haven’t bothered with CRLs (or they don’t enable their checking by default so it’s as if it wasn’t there for most users).

One has to conclude that Sun (and the other two providers) should not be trusted by anyone for quite a while to come. But does that matter ? Since OpenID didn’t promise all that much anyway, does a serious flaw (which does require a certain amount of work to construct an attack) make any difference? At present this looks like the modern equivalent of a small earthquake in Chile.

Additional: Sun’s PR department tell me that the dud certificate has indeed been revoked with Verisign and placed onto the CRL. Hence any system that checks the CRL cannot now be fooled.

7 thoughts on “An insecurity in OpenID, not many dead

  1. I’m not sure there’s anything we could or should have done in OpenID that would have prevented such an attack. The two mechanisms that OpenID uses to verify the identity of a provider (connecting to it in the first place and, optionally, SSL) have been defeated in two separate attacks; what else could we have stood on?

  2. @Paul You’re right that the attack wasn’t preventable: OpenID relies on certificate integrity and this failed. However, without universal use of CRLs you can’t stop people continuing to rely on the certs until they expire — and CRLs are not widely enough used.

    @Bernard Credentica does have a blacklisting scheme that doesn’t depend on CRLs. But I would not have characterised this as the main justification for (or feature of) the technology!

  3. Yeah. I was skeptical to start. I’m either intrinsically paranoid, I assume that planning will always work as poorly as possible (a linear model in a curvilinear environment has interesting implications, and I don’t believe in bivalue logic), or I think most people are stupid. Then again, I used a three-value statement behind a two-value intro.
    –Glenn
    –Blog is on WordPress which appears to be down. I hope I didn’t get spoofed somehow.

  4. I giggled at the penultimate paragraph. I thought Robin Williams had something funny to say about certificates.

  5. @Tim – I’m sure he has… if only I were as funny ;^)

    @Richard – it’s a bit harsh to suggest that people “shouldn’t trust Sun”; don’t you mean that they shouldn’t trust authentication assertions from Sun’s OpenID Provider? (And if the latter…. does that actually change the OpenID trust model…?)

Leave a Reply

Your email address will not be published. Required fields are marked *