Security Advisory (08-AUG-2008) (CVE-2008-3280)
==============================================
Ben Laurie of Google's Applied Security team, while working with an
external researcher, Dr. Richard Clayton of the Computer Laboratory,
Cambridge University, found that various OpenID Providers (OPs) had
TLS Server Certificates that used weak keys, as a result of the Debian
Predictable Random Number Generator (CVE-2008-0166).

In combination with the DNS Cache Poisoning issue (CVE-2008-1447) and
the fact that almost all SSL/TLS implementations do not consult CRLs
(currently an untracked issue), this means that it is impossible to
rely on these OPs.

Attack Description
------------------

In order to mount an attack against a vulnerable OP, the attacker
first finds the private key corresponding to the weak TLS
certificate. He then sets up a website masquerading as the original
OP, both for the OpenID protocol and also for HTTP/HTTPS.

Then he poisons the DNS cache of the victim to make it appear that his
server is the true OpenID Provider.

There are two cases, one is where the victim is a user trying to
identify themselves, in which case, even if they use HTTPS to "ensure"
that the site they are visiting is indeed their provider, they will be
unable to detect the substitution and will give their login
credentials to the attacker.

The second case is where the victim is the Relying Party (RP). In this
case, even if the RP uses TLS to connect to the OP, as is recommended
for higher assurance, he will not be defended, as the vast majority of
OpenID implementations do not check CRLs, and will, therefore, accept
the malicious site as the true OP.

Mitigation
----------

Mitigation is surprisingly hard. In theory the vulnerable site should
revoke their weak certificate and issue a new one.

However, since the CRLs will almost certainly not be checked, this
means the site will still be vulnerable to attack for the lifetime of
the certificate (and perhaps beyond, depending on user
behaviour). Note that shutting down the site DOES NOT prevent the
attack.

Therefore mitigation falls to other parties.

1. Browsers must check CRLs by default.

2. OpenID libraries must check CRLs.

3. DNS caching resolvers must be patched against the poisoning attack.

4. Until either 1 and 2 or 3 have been done, OpenID cannot be trusted
  for any OP that cannot demonstrate it has never had a weak
  certificate.

Discussion
----------

Normally, when security problems are encountered with a single piece
of software, the responsible thing to do is to is to wait until fixes
are available before making any announcement. However, as a number of
examples in the past have demonstrated, this approach does not work
particularly well when many different pieces of software are involved
because it is necessary to coordinate a simultaneous release of the
fixes, whilst hoping that the very large number of people involved
will cooperate in keeping the vulnerability secret.

In the present situation, the fixes will involve considerable
development work in adding CRL handling to a great many pieces of
openID code. This is a far from trivial amount of work.

The fixes will also involve changes to browser preferences to ensure
that CRLs are checked by default -- which many vendors have resisted
for years. We are extremely pessimistic that a security vulnerability
in OpenID will be seen as sufficiently important to change the browser
vendors minds.

Hence, we see no value in delaying this announcement; and by making
the details public as soon as possible, we believe that individuals
who rely on OpenID will be better able to take their own individual
steps to avoid relying upon the flawed certificates we have
identified.

OpenID is at heart quite a weak protocol, when used in its most
general form[1], and consequently there is very limited reliance upon
its security. This means that the consequences of the combination of
attacks that are now possible is nothing like as serious as might
otherwise have been the case.

However, it does give an insight into the type of security disaster
that may occur in the future if we do not start to take CRLs
seriously, but merely stick them onto "to-do" lists or disable them in
the name of tiny performance improvements.

Affected Sites
--------------

There is no central registry of OpenID systems, and so we cannot be
sure that we have identified all of the weak certificates that are
currently being served. The list of those we have found so far is:

openid.sun.com
www.xopenid.net 
openid.net.nz

Notes
-----

[1] There are ways of using OpenID that are significantly more secure
   than the commonly deployed scheme, I shall describe those in a
   separate article.