OpenID/Debian PRNG/DNS Cache poisoning advisory
Ben Laurie
===============================================
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.
Gerald Beuchelt
faulty certificate with a new one. In addition we created an advisory
for our users that outlines some general precautions they should take:
http://blog.beuchelt.org/2008/08/07/Some+Security+Advice+For+Our+OpenID+Users.aspx).
While these measure cannot guarantee safety, they can help improving the
situation. In addition, Robin Wilton has documented what happened here:
http://blogs.sun.com/racingsnake/entry/one_factor_trust_multi_factor
We are continuing to monitor the situation and might make additional
changes to the service.
I would like to use this opportunity to thank Ben again for approaching
us upfront and working with us while preparing his advisory.
Best,
Gerald Beuchelt
> _______________________________________________
> general mailing list
> gen...@openid.net
> http://openid.net/mailman/listinfo/general
>
Eric Rescorla
Ben Laurie wrote:
> 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.
Isn't this a good argument for blacklisting the keys on the client
side?
-Ekr
Ben Laurie
<eddy...@startcom.org> wrote:
> This affects any web site and service provider of various natures. It's not
> exclusive for OpenID nor for any other protocol / standard / service! It may
> affect an OpenID provider if it uses a compromised key in combination with
> unpatched DNS servers. I don't understand why OpenID is singled out, since
> it can potentially affect any web site including Google's various services
> (if Google would have used Debian systems to create their private keys).
OpenID is "singled out" because I am not talking about a potential
problem but an actual problem.
We have spotted other actual problems in other services. Details will
be forthcoming at appropriate times.
Dave Korn
Isn't that exactly what "Browsers must check CRLs" means in this context
anyway? What alternative client-side blacklisting mechanism do you suggest?
cheers,
DaveK
--
Can't think of a witty .sigline today....
Eric Rescorla
It's easy to compute all the public keys that will be generated
by the broken PRNG. The clients could embed that list and refuse
to accept any certificate containing one of them. So, this
is distinct from CRLs in that it doesn't require knowing
which servers have which cert...
-Ekr
Ben Laurie
It also only fixes this single type of key compromise. Surely it is
time to stop ignoring CRLs before something more serious goes wrong?
Dick Hardt
>
> It also only fixes this single type of key compromise. Surely it is
> time to stop ignoring CRLs before something more serious goes wrong?
Clearly many implementors have chosen to *knowingly* ignore CRLs
despite the security implications, so my take away would be that the
current public key infrastructure is flawed.
-- Dick
Leichter, Jerry
| > Isn't this a good argument for blacklisting the keys on the client
| > side?
|
| Isn't that exactly what "Browsers must check CRLs" means in this
| context anyway? What alternative client-side blacklisting mechanism
| do you suggest?
explicitly check for them in the browser code, without reference to
any external CRL.
Of course, the browser itself may not see the bad key - it may see key
for something that *contains* a bad key. So such a check would not be
complete. Still, it couldn't hurt.
One could put similar checks everywhere that keys are used. Think of it
as the modern version of code that checks for and rejects DES weak and
semi-weak keys. The more code out there that does the check, the faster
bad keys will be driven out of use.
-- Jerry
Dave Korn
<scurries off to read CRL format in RFC>
Oh, you can't specify them solely by key, you have to have all the
associated metadata. That's annoying, yes, I understand your point now.
IIRC various of the vendors' sshd updates released in the immediate wake
of the Debian catastrophe do indeed block all the weak keys.
Peter Gutmann
>It's easy to compute all the public keys that will be generated
>by the broken PRNG. The clients could embed that list and refuse
>to accept any certificate containing one of them. So, this
>is distinct from CRLs in that it doesn't require knowing
>which servers have which cert...
You'd also end up with a rather large list for the client to carry around,
which would be especially problematic for lightweight clients. You'd need to
represent it as something like a Bloom filter to avoid this (given that most
users will just click OK on invalid certs, the small false positive rate
shouldn't have much effect either :-).
Peter.
Dan Kaminsky
Funnily enough I was just working on this -- and found that we'd end up
adding a couple megabytes to every browser. #DEFINE NONSTARTER. I am
curious about the feasibility of a large bloom filter that fails back to
online checking though. This has side effects but perhaps they can be
made statistically very unlikely, without blowing out the size of a browser.
Updating the filter could then be something we do on a 24 hour
autoupdate basis. Doing either this, or doing revocation checking over
DNS (seriously), is not necessarily a bad idea. We need to do better
than we've been.
Perry E. Metzger
"Ben Laurie" <be...@google.com> writes:
>> It's easy to compute all the public keys that will be generated
>> by the broken PRNG. The clients could embed that list and refuse
>> to accept any certificate containing one of them. So, this
>> is distinct from CRLs in that it doesn't require knowing
>> which servers have which cert...
>
> It also only fixes this single type of key compromise. Surely it is
> time to stop ignoring CRLs before something more serious goes wrong?
The problem is, the CRL mechanism itself is also dangerous. Sadly,
clients are required to keep on going if they can't reach a CRL
server. That means that if you DoSing the CRL servers or use DNS
attacks to effectively take them offline, you've also effectively
eliminated the certificate revocation.
I'm not going to tell you that paying attention to CRLs wouldn't be
better than what happens now, but it will not eliminate the
problem. It is too hard to "prove a negative" (that is, to prove to
yourself that no revocation exists.)
The kerberos style of having credentials expire very quickly is one
(somewhat less imperfect) way to deal with such things, but it is far
from perfect and it could not be done for the ad-hoc certificate
system https: depends on -- the infrastructure for refreshing all the
world's certs every eight hours doesn't exist, and if it did imagine
the chaos if it failed for a major CA one fine morning.
One also worries about what will happen in the UI when a certificate
has been revoked. If it just says "this cert has been revoked,
continue anyway?" the wrong thing will almost always happen.
Perry
--
Perry E. Metzger pe...@piermont.com
Eric Rescorla
Dan Kaminsky wrote:
> Eric Rescorla wrote:
> > It's easy to compute all the public keys that will be generated
> > by the broken PRNG. The clients could embed that list and refuse
> > to accept any certificate containing one of them. So, this
> > is distinct from CRLs in that it doesn't require knowing
> > which servers have which cert...
> Funnily enough I was just working on this -- and found that we'd end up
> adding a couple megabytes to every browser. #DEFINE NONSTARTER. I am
> curious about the feasibility of a large bloom filter that fails back to
> online checking though. This has side effects but perhaps they can be
> made statistically very unlikely, without blowing out the size of a browser.
Why do you say a couple of megabytes? 99% of the value would be
1024-bit RSA keys. There are ~32,000 such keys. If you devote an
80-bit hash to each one (which is easily large enough to give you a
vanishingly small false positive probability; you could probably get
away with 64 bits), that's 320KB. Given that the smallest Firefox
build (Windows) is 7.1 MB, this doesn't sound like a nonstarter to me
at all, especially since the browser could download it in the
background.
> Updating the filter could then be something we do on a 24 hour
> autoupdate basis. Doing either this, or doing revocation checking over
> DNS (seriously), is not necessarily a bad idea. We need to do better
> than we've been.
Yes, there are a number of approaches to more efficient CRL
checking, I think that's a separate issue.
-Ekr
Ben Laurie
> Using this Bloom filter calculator:
> http://www.cc.gatech.edu/~manolios/bloom-filters/calculator.html , plus the
> fact that there are 32,768 weak keys for every key type & size, I get
> various sizes of necessary Bloom filter, based on how many key type / sizes
> you want to check and various false positive rates:
> * 3 key types/sizes with 1e-6 false positive rate: 2826759 bits = 353 KB
> * 3 key types/sizes with 1e-9 false positive rate: 4240139 bits = 530 KB
> * 7 key types/sizes with 1e-6 false positive rate: 6595771 bits = 824 KB
> * 7 key types/sizes with 1e-9 false positive rate: 9893657 bits = 1237 KB
>
> I presume that the first 3 & first 7 key type/sizes in this list
> http://metasploit.com/users/hdm/tools/debian-openssl/ are the best to
> incorporate into the filter.
>
> Is there any chance it would be feasible to get a list of all the weak keys
> that were actually certified by browser-installed CAs, or those weak
> certificates? Presumably, this list would be much smaller and would be more
> effectively distributed in Bloom filter form.
Or as a CRL :-)
Nicolas Williams
> The kerberos style of having credentials expire very quickly is one
> (somewhat less imperfect) way to deal with such things, but it is far
> from perfect and it could not be done for the ad-hoc certificate
> system https: depends on -- the infrastructure for refreshing all the
> world's certs every eight hours doesn't exist, and if it did imagine
> the chaos if it failed for a major CA one fine morning.
The PKIX moral equivalent of Kerberos V tickets would be OCSP Responses.
I understand most current browsers support OCSP.
> One also worries about what will happen in the UI when a certificate
> has been revoked. If it just says "this cert has been revoked,
> continue anyway?" the wrong thing will almost always happen.
No doubt.
Ben Laurie
<eddy...@startcom.org> wrote:
> Ben Laurie:
>
> On Fri, Aug 8, 2008 at 12:44 PM, Eddy Nigg (StartCom Ltd.)
> <eddy...@startcom.org> wrote:
>
>
> This affects any web site and service provider of various natures. It's not
> exclusive for OpenID nor for any other protocol / standard / service! It may
> affect an OpenID provider if it uses a compromised key in combination with
> unpatched DNS servers. I don't understand why OpenID is singled out, since
> it can potentially affect any web site including Google's various services
> (if Google would have used Debian systems to create their private keys).
>
>
> OpenID is "singled out" because I am not talking about a potential
> problem but an actual problem.
>
>
> which makes use of a compromised key has an actual problem and not a
> potential problem. Open ID as a standard isn't more affected than, lets say
> XMPP...If there are servers and providers relying on such keys the have a
> real actual problem.
I do not dispute this.
> I don't see your point about Open ID nor didn't I see
> anything new....
The point is I found OpenID servers with weak keys.
> The problem of weak keys should be dealt at the CA level, many which have
> failed to do anything serious about it.
Indeed.
> We have spotted other actual problems in other services. Details will
> be forthcoming at appropriate times.
>
>
> I think it's superfluous to single out different services since any service
> making use of the weak keys is affected, with recent discovery of DNS
> poisoning making the matter worse. I suggest you try a forum which can
> potentially reach many CAs, they in fact have everything at their disposal
> to remove this threat!
If you have a better forum, bring it on.
However, CAs do not have everything at their disposal to remove the
threat. Browsers,OpenID libraries and RPs must also participate.
Just as saying "buffer overflows are bad" has not magically caused all
buffer overflows to be fixed, I am confident that the only way to get
this problem fixed is to chase down all the culprits individually. I
am sure that OpenID is not the only thing with problems, as you say.
Nicolas Williams
> At 1:47 PM -0500 8/8/08, Nicolas Williams wrote:
> >On Fri, Aug 08, 2008 at 02:08:37PM -0400, Perry E. Metzger wrote:
> >> The kerberos style of having credentials expire very quickly is one
> >> (somewhat less imperfect) way to deal with such things, but it is far
> >> from perfect and it could not be done for the ad-hoc certificate
> >> system https: depends on -- the infrastructure for refreshing all the
> >> world's certs every eight hours doesn't exist, and if it did imagine
> >> the chaos if it failed for a major CA one fine morning.
> >
> >The PKIX moral equivalent of Kerberos V tickets would be OCSP Responses.
> >
> >I understand most current browsers support OCSP.
>
Not that long ago nothing supported OCSP. If all that's left (ha) is
the CAs then we're in good shape. (OCSP services can be added without
modifying a CA -- just issue the OCSP Responders their certs and let
them use CRLs are their source of revocation information.)
Paul Hoffman
>> The kerberos style of having credentials expire very quickly is one
>> (somewhat less imperfect) way to deal with such things, but it is far
>> from perfect and it could not be done for the ad-hoc certificate
>> system https: depends on -- the infrastructure for refreshing all the
>> world's certs every eight hours doesn't exist, and if it did imagine
>> the chaos if it failed for a major CA one fine morning.
>
>The PKIX moral equivalent of Kerberos V tickets would be OCSP Responses.
>
>I understand most current browsers support OCSP.
...and only a tiny number of CAs do so.
--Paul Hoffman, Director
--VPN Consortium
Eric Rescorla
Leichter, Jerry wrote:
>
> | > > Funnily enough I was just working on this -- and found that we'd
> | > > end up adding a couple megabytes to every browser. #DEFINE
> | > > NONSTARTER. I am curious about the feasibility of a large bloom
> | > > filter that fails back to online checking though. This has side
> | > > effects but perhaps they can be made statistically very unlikely,
> | > > without blowing out the size of a browser.
> | > Why do you say a couple of megabytes? 99% of the value would be
> | > 1024-bit RSA keys. There are ~32,000 such keys. If you devote an
> | > 80-bit hash to each one (which is easily large enough to give you a
> | > vanishingly small false positive probability; you could probably get
> | > away with 64 bits), that's 320KB. Given that the smallest Firefox
> You can get by with a lot less than 64 bits. People see problems like
> this and immediately think "birthday paradox", but there is no "birthday
> paradox" here: You aren't look for pairs in an ever-growing set,
> you're looking for matches against a fixed set. If you use 30-bit
> hashes - giving you about a 120KB table - the chance that any given
> key happens to hash to something in the table is one in a billion,
> now and forever. (Of course, if you use a given key repeatedly, and
> it happens to be that 1 in a billion, it will hit every time. So an
> additional table of "known good keys that happen to collide" is worth
> maintaining. Even if you somehow built and maintained that table for
> all the keys across all the systems in the world - how big would it
> get, if only 1 in a billion keys world-wide got entered?)
I don't believe your math is correct here. Or rather, it would
be correct if there was only one bad key.
Remember, there are N bad keys and you're using a b-bit hash,
which has 2^b distinct values. If you put N' entries in the
hash table, the probability that a new key will have the
same digest as one of them is N'/(2^b). If b is sufficiently
large to make collisions rare, then N'=~N and we get
N/(2^b).
To be concrete, we have 2^15 distinct keys, so, the
probability of a false positive becomes (2^15)/(2^b)=2^(b-15).
To get that probability below 1 billion, b+15 >= 30, so
you need about 45 bits. I chose 64 because it seemed to me
that a false positive probability of 2^{-48} or so was better.
-Ekr
Clausen, Martin (DK - Copenhagen)
(http://codefromthe70s.org/sslblacklist.asp) for Firefox or heise SSL
Guardian
(http://www.heise-online.co.uk/security/Heise-SSL-Guardian--/features/11
1039/) for IE to do this. If presented with a Debian key the show a
warning.
The blacklists are implemented using either a traditional blacklist
(text file) or distributed using DNS.
~martin
-Ekr
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to
majo...@metzdowd.com
---------------------- Deloitte Disclaimer ---------------------
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and
is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any
disclosure, copying, or distribution of this message, or the
taking of any action based on it, is strictly prohibited.
----------------------------------------------------------------
Ben Laurie
<mcla...@deloitte.dk> wrote:
> You could use the SSL Blacklist plugin
> (http://codefromthe70s.org/sslblacklist.asp) for Firefox or heise SSL
> Guardian
> (http://www.heise-online.co.uk/security/Heise-SSL-Guardian--/features/11
> 1039/) for IE to do this. If presented with a Debian key the show a
> warning.
>
> The blacklists are implemented using either a traditional blacklist
> (text file) or distributed using DNS.
Browser plugins do not assist RPs.
Ben Laurie
> (http://codefromthe70s.org/sslblacklist.asp) for Firefox or heise SSL
> Guardian
> (http://www.heise-online.co.uk/security/Heise-SSL-Guardian--/features/11
> 1039/) for IE to do this. If presented with a Debian key the show a
> warning.
>
> The blacklists are implemented using either a traditional blacklist
> (text file) or distributed using DNS.
There are two parties that are vulnerable: the user logging into the
OpenID Provider (OP), and the Relying Party (RP). If the RP
communicates with the OP, then it needs to use TLS and CRLs or OCSP.
Browser plugins do not bail it out.
Cheers,
Ben.
Stefan Kanthak
>
>
> Eric Rescorla wrote:
>> At Fri, 8 Aug 2008 17:31:15 +0100,
>> Dave Korn wrote:
>>
>>> Eric Rescorla wrote on 08 August 2008 16:06:
>>>
>>>
>>>> At Fri, 8 Aug 2008 11:50:59 +0100,
>>>> Ben Laurie wrote:
>>>>
>>>>> 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.
>>>>>
>>>> Isn't this a good argument for blacklisting the keys on the client
>>>> side?
>>>>
>>> Isn't that exactly what "Browsers must check CRLs" means in this context
>>> anyway? What alternative client-side blacklisting mechanism do you suggest?
>>>
>>
>> It's easy to compute all the public keys that will be generated
>> by the broken PRNG. The clients could embed that list and refuse
>> to accept any certificate containing one of them. So, this
>> is distinct from CRLs in that it doesn't require knowing
>> which servers have which cert...
> Funnily enough I was just working on this -- and found that we'd end up
> adding a couple megabytes to every browser.
At least for the weak keys kudos to Debian's OpenSSL maintainer
there exists an extension to Firefox which checks the keys, see <http://codefromthe70s.org/sslblacklist.asp>, as well as c't's
SSLguardian for the Windows Crypto API, see
<http://www.heise-online.co.uk/security/features/111039/0> and
<http://www.heise-online.co.uk/security/features/111039/1>
Stefan
Forrest J. Cavalier III
>
> To be concrete, we have 2^15 distinct keys, so, the
> probability of a false positive becomes (2^15)/(2^b)=2^(b-15).
> To get that probability below 1 billion, b+15 >= 30, so
> you need about 45 bits. I chose 64 because it seemed to me
> that a false positive probability of 2^{-48} or so was better.
>
> -Ekr
Since it's a known set, I think you can use perfect hashing.
There will still be false positives, but presumably no
"bad" keys, nor keys matching the hash everyone agrees on,
are going to be issued after today, right?
Yeah, right.
Leichter, Jerry
compared to the number of hash values, but of course it isn't. The
perils of looking at one number just as decimal and the other just in
exponential form....
In any case, I think it's clear that even for extremely conservative
"false hit" ratios, the table size is quite reasonable. You wouldn't
want the table on your smart card or RFID chip, perhaps, but there even
a low-end "smartphone" would have no problems.
-- Jerry
"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
Tim Dierks
version, and I didn't want to fork the thread. Also sorry for
initially sending HTML; I didn't realize it was so abhorrent these
days. ]
On Fri, Aug 8, 2008 at 1:43 PM, Dan Kaminsky <d...@doxpara.com> wrote:
>>
>> It's easy to compute all the public keys that will be generated
>> by the broken PRNG. The clients could embed that list and refuse
>> to accept any certificate containing one of them. So, this
>> is distinct from CRLs in that it doesn't require knowing which servers have which cert...
>
> Funnily enough I was just working on this -- and found that we'd end up adding a couple megabytes to every browser. #DEFINE NONSTARTER. I am curious about the feasibility of a large bloom filter that fails back to online checking though. This has side effects but perhaps they can be made statistically very unlikely, without blowing out the size of a browser.
Using this Bloom filter calculator:
- Tim
Ben Laurie
> 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.
Yeah, I considered this scheme. The problem is that it doesn't really
help the relying parties, who can still be fooled into believing an
existing user is returning (or a new one is arriving) from the original
site. This is particularly a problem for Sun's OpenID Provider, which
makes the additional assertion (out of band) that the user is a Sun
employee. So, anyone can become a Sun employee, as of a few days ago.
This is why the lack of CRL checking in OpenID libraries is an issue.
> 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.
In general, DNS is not fixable without deploying DNSSEC.
a) The current "fix" just reduces the probability of an attack. If
attacker and victim have sufficient bandwidth, it can still be done in
under a day.
b) There are many scenarios, mostly revolving around the use of wireless
hotspots, where users are easily fooled into using a malicious DNS provider.
So, DNS patching is not, IMO, the real answer to this problem. Of
course, the second scenario has been around forever, but is conveniently
ignored when explaining why CRLs are not necessary (and all other things
that rely on perfect DNS). All that's happened recently is we've made
people who are sitting still just as vulnerable as travellers.
But increasingly we are all travellers some of the time, from a "how we
get our 'net" POV. We really can't ignore this use case.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.links.org/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Florian Weimer
> Why do you say a couple of megabytes? 99% of the value would be
> 1024-bit RSA keys. There are ~32,000 such keys.
There are three sets of keys, for big-endian 32-bit, little-endian
32-bit and little-endian 64-bit. On top of that, "openssl genrsa"
generates different keys depending on the existence of $HOME/.rnd (and
-3 creates yet another set of keys, but this is more in the league of
"different key length"). If the library is used for key generation
(instead of the command line tool), different keys might result.
On the other hand, the on-disk size would be comparable to the phishing
filter database.
Part of the problem of the CRL approach is that CAs usually have
policies against obtaining private keys and therefore can't prove to the
customer that their keys are compromised. And adding a CRL entry when
the customer isn't convinced that they've got a problem is probably not
a good idea, either.