\Hal Finney\
12/08/08, 23:25
[I feel a little uncomfortable replying with such a wide distribution!]
Getting browsers, or OpenID installations, to check CRLs or use OCSP to
check for freshness is likely to be slow going. At this point I think
the momentum still favors fixing the remaining DNS systems that are
vulnerable to cache poisoning. This turnkey-MITM bug makes OpenSSL bad
certs far more exploitable, as Dan Kaminsky pointed out in his report.
OpenID is just one example of many where this is going to keep happening
as long as DNS is unpatched.
I thought of one possible mitigation that can protect OpenID end users
against remote web sites which have not patched their DNS. OpenID
providers who used weak OpenSSL certs would have to change their URLs
so that their old X.509 CA certs on their old URLs no longer work on the
new ones. This will require all of their clients (users who log in with
their OpenID credentials) to change their identifiers. DNS based MITMs
will not be able to forge messages related to the new identifiers.
Customers can be alerted to this requirement as soon as they log in to
a web site (relying party) whose DNS is NOT hacked; the redirection to
the OpenID provider will give opportunity to notify the customer of the
name change. Making this change may be somewhat inconvenient, but since
OpenID is a relatively new standard, at least it is easier than would
be the case with a more established protocol.
In the other direction of attack, the end user's DNS is poisoned and
he gets redirected to a bogus site in place of the OpenID provider;
that site is then able to provide a valid SSL certificate due to the
OpenSSL weakness, thereby stealing whatever authentication credentials
the user normally sends to his OpenID provider. This is one instance of
the general attack where a user is DNS-misdirected to a bogus copy of
a secure site which unfortunately used weak OpenSSL based certs.
Again, I see fixing the DNS as the path of least resistance here,
especially so since the end user is the one bearing most of the risk,
typically DNS is provided by an ISP or some other agency with a formal
legal relationship, and there is the possibility of liability on the
part of the lax DNS provider. Hopefully we will continue to see rapid
uptake of the DNS fix over the next few weeks.
That still leaves weak-cert OpenID users vulnerable to DNS-unpatched
service providers (OpenID relying parties), and that is where my proposed
mitigation above comes in. By renaming its URLs, an OpenID provider who
had the misfortune to create a weak OpenSSL cert (through no fault of
its own) can save its end users considerable potential grief.
Hal Finney
Getting browsers, or OpenID installations, to check CRLs or use OCSP to
check for freshness is likely to be slow going. At this point I think
the momentum still favors fixing the remaining DNS systems that are
vulnerable to cache poisoning. This turnkey-MITM bug makes OpenSSL bad
certs far more exploitable, as Dan Kaminsky pointed out in his report.
OpenID is just one example of many where this is going to keep happening
as long as DNS is unpatched.
I thought of one possible mitigation that can protect OpenID end users
against remote web sites which have not patched their DNS. OpenID
providers who used weak OpenSSL certs would have to change their URLs
so that their old X.509 CA certs on their old URLs no longer work on the
new ones. This will require all of their clients (users who log in with
their OpenID credentials) to change their identifiers. DNS based MITMs
will not be able to forge messages related to the new identifiers.
Customers can be alerted to this requirement as soon as they log in to
a web site (relying party) whose DNS is NOT hacked; the redirection to
the OpenID provider will give opportunity to notify the customer of the
name change. Making this change may be somewhat inconvenient, but since
OpenID is a relatively new standard, at least it is easier than would
be the case with a more established protocol.
In the other direction of attack, the end user's DNS is poisoned and
he gets redirected to a bogus site in place of the OpenID provider;
that site is then able to provide a valid SSL certificate due to the
OpenSSL weakness, thereby stealing whatever authentication credentials
the user normally sends to his OpenID provider. This is one instance of
the general attack where a user is DNS-misdirected to a bogus copy of
a secure site which unfortunately used weak OpenSSL based certs.
Again, I see fixing the DNS as the path of least resistance here,
especially so since the end user is the one bearing most of the risk,
typically DNS is provided by an ISP or some other agency with a formal
legal relationship, and there is the possibility of liability on the
part of the lax DNS provider. Hopefully we will continue to see rapid
uptake of the DNS fix over the next few weeks.
That still leaves weak-cert OpenID users vulnerable to DNS-unpatched
service providers (OpenID relying parties), and that is where my proposed
mitigation above comes in. By renaming its URLs, an OpenID provider who
had the misfortune to create a weak OpenSSL cert (through no fault of
its own) can save its end users considerable potential grief.
Hal Finney