Hitting the fan

The first glop hit yesterday with Gerry Beuchelt of Sun offering this advice to all users of the Sun OpenID IdM:

In order to limit the risk, we are advising the users of our OpenID@Work provider to make sure that they follow these guidelines, which might be useful for others, as well:

  • Make sure that you systems are fully patched.
  • Verify that the DNS server you use (usually provided by your ISP) is patched and not subject to DNS cache poisoning. You can verify this at Dan Kaminsky’s web site. If you find that your ISP has not down their job, complain. Loudly.
  • Use certificate revocation lists. These list contain the serial numbers of revoked certificates and they can be easily consumed by most modern browsers. For the SunPKI list, just point your browser to http://www.sun.com/pki/pkismica.crl and make sure that your browser refreshes it regularly. Other companies have their own CRLs (e.g. Verisigns are here).
  • Be extra careful when accessing your authentication web site: openid.sun.com can easily be mistaken for open1d.sun.com or openid.sun.com.uk.

What’s driving this is the now well known DNS poisening vulnerability that has gotten so much attention lately. When I read this I recalled the warnings that various security expert gave on OpenID’s reliance on the integrity of DNS. While Gerry’s advice is really good sound security for web browser in general, it is far beyond the capabilities of the vast majority of users.

The second glop hits today when Ben Laurie of Google points out the unfortunate convergence between the DNS vulnerability and the Debian private key generate problem:

Richard Clayton and I today released a security advisory showing how three independent vulnerabilities combine to make a rather scary mess, mitigated only by the fact that no-one protects anything very valuable with OpenID anyway. But just think how much worse it could have been (on which I shall write more soon)!

The third glop hits when Robert Wilton of Sun summarizes this all up far better than I ever could:

Well, I suppose the first thing to note is – in response to Ben and Richard’s alert, we took our OP offline, revoked the weak certificate and generated a strong replacement. However, as Ben pointed out, that doesn’t fix things… As long as someone else is in a position to route users to bogus OPs, where they might be fooled by the revoked, weak certificate, the problem persists.  A better solution to that part of the problem might centre around the more effective use of existing security mechanisms – such as Certificate Revocation Lists (CRLs) – by both clients and RPs. I suspect Ben will be writing about those aspects in more depth soon, so keep an eye on his blog, here.

The next point is that taking our own OP off the network doesn’t really fix anything, either. So we’re going to leave our OP where it is, and Sun employees will continue to be able to register and use it. We are going to increase the guidance we give those employees, about steps they can take to minimise the risk of phishing. Again, that will be a valuable R&D exercise in seeing whether a relatively tech-savvy user community can be educated to change its browsing habits for the better – not a bad pay-off if it works.

So what does this mean for OpenID? In reality probably very little. Security was never the driving factor for OpenID, convenience was. And as history shows again and again, convenience usually trumps security in the computer world.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s