Kicking the hornets' nest
Ryan Koski
necessarily reflect the views of my employer.
Disclaimer #2: This message should not be construed as attacking or
defending any of the parties named in this email. I present this
simply as food for thought or discussion (some may call it flame
bait).
In the wake of the most recent Comodo incident, several people have
made the statement that Comodo's root CAs should be disabled or
removed. The basis of this statement is usually a claim of a pattern
of behavior on Comodo's part that jeopardizes the security of Mozilla
users. While the improper issuance of certificates is a major problem
that needs to be addressed, I cannot help but think that the argument
is one-sided. Where is the uproar over Mozilla's repeated mistakes
that jeopardize the security of Mozilla users? Clearly there is a
pattern:
http://www.mozilla.org/security/known-vulnerabilities/firefox30.html
http://www.mozilla.org/security/known-vulnerabilities/firefox35.html
http://www.mozilla.org/security/known-vulnerabilities/firefox36.html
I have yet to see anyone make a statement such as "Mozilla has
repeatedly displayed negligence and incompetence that endangers the
Mozilla users. For the sake of end user security, we should all stop
using Mozilla products."
I reiterate: I am not defending the actions of Comodo or any other
CA. I am merely pointing out that people make mistakes. And if we're
going to hold people accountable for their mistakes, then we should at
least do so equally.
--
Ryan Koski
ryan...@gmail.com
--
Ryan Koski
ryan...@gmail.com
Kyle Hamilton
On Tue, Mar 29, 2011 at 12:00 PM, Ryan Koski <ryan...@gmail.com> wrote:
>
> I have yet to see anyone make a statement such as "Mozilla has
> repeatedly displayed negligence and incompetence that endangers the
> Mozilla users. For the sake of end user security, we should all stop
> using Mozilla products."
> I reiterate: I am not defending the actions of Comodo or any other
> CA. I am merely pointing out that people make mistakes. And if we're
> going to hold people accountable for their mistakes, then we should at
> least do so equally.
In my own mind, the reason why there's a difference between these two cases is because there are few alternatives to Mozilla's products, and it is the only MathML parser for web pages -- whereas, there are some insanely large number of third-party CAs included in the root program.
As soon as there are alternatives, I will state that which you have not yet observed.
-Kyle H
Steingruebl, Andy
> From: Ryan Koski
>
>
> In the wake of the most recent Comodo incident, several people have made
> the statement that Comodo's root CAs should be disabled or removed.
>
> displayed negligence and incompetence that endangers the Mozilla
> users. For the sake of end user security, we should all stop using Mozilla
> products."
Ryan,
Since no one else "bit" on this, let me take a semi-serious stab at this.
1. The job of a web browser maker isn't just security. It is also performance, features, etc. A web browser has necessary security requirements, but that isn't all it does. Web browsers are often also "free" in terms of cost to the end-users. You generally don't buy a web browser.
2. There is currently a functioning market for web browsers, specifically the "relying party" in this case the end-consumer. Don't like the one you are using, switch. Once you've switched, you're no longer personally dependent on the security of that other product. It is also general quite easy to know which browser you're using. It is fairly hard to get fooled an inadvertently use a browser you didn't mean to. Web browser usage stats bear this out, there is robust competition and as new features come out, people actually switch back and forth between them.
Compare that to the market for CAs.
1. The job of a CA is arguably nothing *but* security. They don't provide any functionality other than security functionality. They aren't writing software we need, they are performing cryptographic operations in exchange for money (in most cases) and theoretically offering some form of warranty in return, like they actually did what they were supposed to.
2. There isn't a robust functioning market for the ultimate relying party in the CA space, as user interfaces for both inspecting a certificate, and managing trust anchors are anything but robust and transparent. It is quite easy to know which web browser you are running, it is tremendously difficult to know which TAs you are using, and it is even *harder* to change them. Users don't have any meaningful choice in the matter generally. Even experts don't have good ways of automating this and easily managing it. New updates come out that wipe out previous settings, etc. As a result, for the people who really matter in the equation, the ultimate relying party (end-users) there is no market.
This is why I don't see the situations as analogous at all.
- Andy
Eddy Nigg
> This is why I don't see the situations as analogous at all.
Perhaps one thing to add here is that there is no 100% security, maybe
there is 99.9999%, but not 100. Every CA can be vulnerable at some
point, or a specific layer or control might fail. There is some analogy,
specially what code (software) concerns.
However there is a difference when a particular issue has been detected
and the affected CA promised to have it fixed and implemented a solution
that was accepted by the relying parties (in this case Mozilla), when in
fact it hasn't.
Another difference is that CAs should be (and probably the more serious
ones are) subject to multiple controls and multiple layers of defenses.
This makes sense because CAs are in the security businesses as you
noted, whereas browsers are only partly.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
István Zsolt BERTA
For me it was not surprising at all that a registration procedure of a
one CA failed.
CAs are operated by humans and registration is performed by (or
supported by) humans. Any system that involves humans (or software
developed by humans) will eventually fail.
There are a zillion CAs out there, there will always be one that
commits a mistake.
What did surprise me is that major browsers needed to issue patches
after the CA detected the incident and revoked the certificate.
Why was revocation not enough? Why could not the CA handle this alone
by revoking the certificate? Why was there a need to involve every
relying party (software)?
A CA should be able to fix such an issue alone by revoking the
certificates. Alas, it cannot, e.g.:
http://www.imperialviolet.org/2011/03/18/revocation.html
http://www.thoughtcrime.org/papers/ocsp-attack.pdf
Security is never 100% sure. What _is_ 100% sure that there will be
similar incidents in the future, there will be misissued certificate,
no matter how hard CAs try. There needs to be a better way for
handling this than patching all relying party software worldwide.
Come on, this just does not scale.
I agree that we should not put the whole blame on the CA.
Regards,
István
Paul van Brouwershaven
> Security is never 100% sure. What _is_ 100% sure that there will be
> similar incidents in the future, there will be misissued certificate,
> no matter how hard CAs try. There needs to be a better way for
> handling this than patching all relying party software worldwide.
> Come on, this just does not scale.
>
> I agree that we should not put the whole blame on the CA.
Nobody is ever 100% secure! But can't you blame a CA that has been confronted with the same security
issue before and they lacked to take proper actions to prevent this issue in the future?
Personally I had dozens of discussions with Comodo about there open RA issuing permissions in the
past few years and they always waved it away!
You can definitely blame Comodo for this issue !!!
--
Kind regards,
Paul van Brouwershaven
Networking4all B.V.
____________________________________________
Phone: (31) 20 7881042 Fax: (31) 20 7881040
Email: p.vanbrou...@networking4all.com
Internet: https://www.networking4all.com
LinkedIn: https://www.linkedin.com/in/pvanbrouwershaven
Facebook: https://www.facebook.com/p.vanbrouwershaven
Twitter: https://www.twitter.com/vanbroup
István Zsolt BERTA
Definitely. I am not trying to defend the CA. From what I understand,
they committed a series of critical mistakes.
However, what we saw is not just a failure of a single CA. This is a
failure of the security model.
Regards,
István
Peter Gutmann
>Definitely. I am not trying to defend the CA. From what I understand, they
>committed a series of critical mistakes.
>
>However, what we saw is not just a failure of a single CA. This is a failure
>of the security model.
Yup. And we were incredibly lucky that the numerous times it's been shown to
have failed, it's been a benign failure. In this particular instance the
attacker was extremely cooperative with the defenders, which a genuine
attacker wouldn't be.
(As I pointed out in previous messages, in pretty much all of the public CA
failures, the "attacker" has just been trying to make a point, and helpfully
disclosed what they did. There have been several cases of people obtaining
fraudulent certificates without disclosing it for various reasons, chiefly
liability concerns, that have never been discovered by the CAs that issued the
certs. This points strongly towards there also being fraudulent certs issued
where the attackers weren't helpful enough to let everyone know afterwards
and/or didn't do it for their own amusement and didn't make use of the certs
when they got them).
Peter.
Eddy Nigg
> Definitely. I am not trying to defend the CA. From what I understand,
> they committed a series of critical mistakes.
>
> However, what we saw is not just a failure of a single CA. This is a
> failure of the security model.
Failing to implement the expected controls (Mozilla and others require)
is not a failure of the security model at all, it's a failure of the CA.
Specially when that CA promised to have that implemented after a
previous failure.
Jean-Marc Desperrier
>> However, what we saw is not just a failure of a single CA. This is a failure
>> of the security model.
> Yup. And we were incredibly lucky that the numerous times it's been shown to
> have failed, it's been a benign failure.
I've been thinking about this case again, and that :
- The initial weak point was a compromised web server
- There's no guarantee that none of the target web sites of that attack
will ever be compromised
- They very certainly use software keys
- So if they are compromised, it won't difficult for the attacker to
steal the actual private key of those server
- we've seen we don't trust revocation enough to just rely on it in such
a case
So what will happen the day one of those servers is compromised ?
Another hurried up release with an hard coded revocation list inside it
? But then, who deserves the hard coded revocation list treatment and
who will just get the normal, unrealiable revocation mechanism ?
I think we must put in place a working, trustable revocation mechanism,
which the current one clearly isn't.
Paul Tiemann
On Apr 4, 2011, at 10:11 AM, Jean-Marc Desperrier wrote:
> Peter Gutmann wrote:
>>> However, what we saw is not just a failure of a single CA. This is a failure
>>> of the security model.
>> Yup. And we were incredibly lucky that the numerous times it's been shown to
>> have failed, it's been a benign failure.
>
> I've been thinking about this case again, and that :
> - The initial weak point was a compromised web server
> - There's no guarantee that none of the target web sites of that attack will ever be compromised
> - They very certainly use software keys
> - So if they are compromised, it won't difficult for the attacker to steal the actual private key of those server
> - we've seen we don't trust revocation enough to just rely on it in such a case
>
> So what will happen the day one of those servers is compromised ? Another hurried up release with an hard coded revocation list inside it ? But then, who deserves the hard coded revocation list treatment and who will just get the normal, unrealiable revocation mechanism ?
I think in this case, there was some cause to fear that it could have been a national government with the power to spoof DNS and block access to OCSP in order to run a broad MITM attack against thousands/millions.
Revocation under normal circumstances works fairly well when you aren't worried that there's a chance millions of people are going to get their DNS _and_ OCSP messed with.
> I think we must put in place a working, trustable revocation mechanism, which the current one clearly isn't.
Here's the cleanest, fastest path I can see toward the goal of failing closed when revocation checks fail:
1) First try the OCSP responder.
2) If the OCSP attempt does not yield an authoritative answer, try at least one (preferably all) of the CRLs listed in the CRL Distribution Points extension.
3) At a minimum, draw a red line through the URL in the location bar and a red error symbol instead of the site's favicon (or some equivalent UI warning)
4) If settings:i.want.my.ssl.to.be.secure=true (some equivalent setting) then block the connection entirely, and toss up a page describing the revocation check failure, what was done (OCSP was tried, then CRLs were tried), some info on the offending certificate, and at least a button to "report this incident" to something similar to Firefox's Crash Recovery tool...
Browsers could recover from 99.99% of OCSP glitches (which should be less than 0.01% rare to begin with) just by checking the CRL.
CAs should be able to host their OCSP and CRL services on different networks, or at the very least on different servers.
CAs whose revocation checking services have poor uptime will deservedly begin to feel the heat from their own customers.
Kyle Hamilton
On Mon, Apr 4, 2011 at 7:34 AM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 04/04/2011 02:42 PM, From István Zsolt BERTA:
>>
>> Definitely. I am not trying to defend the CA. From what I understand,
>> they committed a series of critical mistakes.
>>
>> failure of the security model.
>
> not a failure of the security model at all, it's a failure of the CA.
> Specially when that CA promised to have that implemented after a previous
> failure.
Yes, this is a failure of a single CA. However, the response to learning about this failure is exposing some serious problems with the infrastructure.
The issue is, "Why were Internet-standard revocation mechanisms not enough? Why did Mozilla et al choose to push out new software versions instead of relying on the revocation infrastructure?"
-Kyle H
Eddy Nigg
On 04/05/2011 12:21 AM, From Kyle Hamilton:
> Eddy, please don't be obtuse.
??
> Yes, this is a failure of a single CA. However, the response to
> learning about this failure is exposing some serious problems with the
> infrastructure.
Which is?
> The issue is, "Why were Internet-standard revocation mechanisms not
> enough?
Because software vendors aren't enforcing the revocation mechanism that
have been defined for the security model some think was failing.
> Why did Mozilla et al choose to push out new software versions
> instead of relying on the revocation infrastructure?"
Because as usual, other unrelated considerations had priority with the
decision makers what revocation status checking concerns.
There is nothing wrong with either the security model nor with the
"infrastructure"...
Ian G
>
> On Apr 4, 2011, at 10:11 AM, Jean-Marc Desperrier wrote:
>
>> Peter Gutmann wrote:
>>>> of the security model.
>>> Yup. And we were incredibly lucky that the numerous times it's been shown to
>>> have failed, it's been a benign failure.
We are incredibly lucky, or we've overspent. This is Dan Geer's
observation, that, in the absence of any real damages (e.g., excluding
demos and academic experiments) we cannot distinguish blind luck from
over-expenditure.
>> I've been thinking about this case again, and that :
>> - The initial weak point was a compromised web server
>> - There's no guarantee that none of the target web sites of that attack will ever be compromised
>> - They very certainly use software keys
>> - So if they are compromised, it won't difficult for the attacker to steal the actual private key of those server
(The breach of the client's webserver has been expected as the easiest
way to steal random private keys. We've long expected the development
of stolen key attacks in phishing because they already use random
domains, but apparently this hasn't been attractive to phishers...)
>> - we've seen we don't trust revocation enough to just rely on it in such a case
>>
>> So what will happen the day one of those servers is compromised ? Another hurried up release with an hard coded revocation list inside it ? But then, who deserves the hard coded revocation list treatment and who will just get the normal, unrealiable revocation mechanism ?
>
> I think in this case, there was some cause to fear that it could have been a national government with the power to spoof DNS and block access to OCSP in order to run a broad MITM attack against thousands/millions.
Was there ever any evidence for that? This is the sort of thing that
would be useful to disclose, as it indicates response capabilities.
It's somewhat uncertain to rely on the infrastructure to any great value
when we can't see how these responses pan out.
As an aside, one thing we did add in recent years was an ability to
revoke the root, in the Mozilla wiki somewhere. It seems that there was
no such procedure. I've heard it said that banks, etc, won't put any of
their critical infra onto PKI because of this flaw.
> Revocation under normal circumstances works fairly well when you aren't worried that there's a chance millions of people are going to get their DNS _and_ OCSP messed with.
Revocation works when it isn't needed. Question is, how well does it
work when it is needed?
iang
Erwann Abalea
[...]
> Here's the cleanest, fastest path I can see toward the goal of failing closed when revocation checks fail:
>
> 1) First try the OCSP responder.
> 2) If the OCSP attempt does not yield an authoritative answer, try at least one (preferably all) of the CRLs listed in the CRL Distribution Points extension.
As I said on another list, if I were an attacker with the power to
create any certificate I want, I'd create a long-lived OCSP
certificate with the OCSPNoCheck extension. And probably a sub-CA
certificate.
With such an OCSP certificate, I could control the revocation status
of any certificate issued under the same CA, and thanks to the
OCSPNoCheck extension, it cannot be revoked. At all.
--
Erwann.
Eddy Nigg
> As I said on another list, if I were an attacker with the power to
> create any certificate I want, I'd create a long-lived OCSP
> certificate with the OCSPNoCheck extension. And probably a sub-CA
> certificate.
I assume and it's my expectation that one of those certificates is
harder to get.
Kyle Hamilton
Hi Kyle,
On 04/05/2011 04:14 AM, From Kyle Hamilton:
1) No capacity to provide a true trustworthy-in-the-face-of-state-level-attack revocation.
2) No capacity to ensure that a given certificate was ever issued in actuality.
3) No capacity to make the existing infrastructure useful to the end-consumer.
4) No elegant recovery from cryptographic algorithm breakage (like MD5).
Why don't you post this to the mailing list? I hate writing twice the same thing.
I will. It was a mistake, I hit 'reply' instead of 'reply all'. (I will follow this up to the list with the original mail.)
Even if the browser vendor did enforce the revocation mechanism, the revocation mechanism was compromised by the apparent capacity of the attacker to change the layout of the network.
But then the certificate would be considered invalid if no revocation status was successfully received. That's why browsers should enforce it. I have it enforced and it works perfect.
Sure, and now I as a business owner have to rely upon the infrastructure of a 3rd party for my cart being displayed without a "legitimate sites will not ask you to do this" warning.
What everyone has failed to remember is that this isn't just about the security of the end user, this is also about the security of the site and its usability without being libeled or slandered.
This is a failure of the infrastructure, and a failure of the standards.
No, it's a failure of not implementing and enforcing the defined standard.
No, this is a failure of the infrastructure and the defined standard. I'll explain why in a moment.
I dispute this. The existing revocation infrastructure does not meet the challenges of the real world.
Really? And why not?
Because the existing revocation infrastructure relies solely upon the cryptography never being compromised.
There is something wrong with the model. It relies on the cryptography never being compromised.
Well, either you rely on cryptography or on something else. Right now I'm not aware on anything better than that.
That's because you're stuck looking from the inside out. Come on out of your box, and I'll show you the situations that your model doesn't take into consideration.
(The solution to cryptography which is crackable is to minimize reliance upon it, and put more faith in corroboration.)
If root certificates and intermediate certificates had something like the CRL Issuer Distribution Point extension
Who says that they don't have OCSP and CRLs?
That information is passed to the client via the certificate-in-the-hands-of-Mallory -- i.e., in every certificate which the issuer mints. That information is not passed to the client as being authoritatively asserted by the parent of the intermediate. (In other words, if Mallory can control the content of his own certificate, Mallory can change the OCSP or the CRL location within the certificate.)
Before CAs are signed, all of the OCSP and CRL URLs have already been determined. There's no reason other than hubris (and the belief that cryptography was going to be big and slow forever) that the signer of the CA shouldn't put the CA's already-determined CRL and OCSP addresses in the certificate it issues to its new child.
Really, why shouldn't a CA certificate include its points of contact for revocation within itself, instead of the certificates its key signs?
This is a failure of the standard, and it is a failure of the infrastructure.
even the DNS- and OCSP-rebinding attacks by states previously contemplated wouldn't work because there would be a trustworthy chain from the root to the intermediate, with authoritative information obtainable from inside the certificate authorizing the delegation.
If....but they do have.
But they don't have. Remember the 2nd preimage scenario: the false certificate contains the revocation distribution point for itself, and the false certificate doesn't have to point to the same place. The easiest way to address this is to move the revocation distribution point from the end-entity certificate to the end-entity's signer's certificate.
Once you do that, even if the state moves DNS and server hosting there's no intermediate delegation from a trusted authority -- which means that the only place that the information can be truly provided can be checked by the client, and if it doesn't check out it's an attack
But then again, OCSP doesn't really provide a response that a given certificate has ever actually been issued, is associated with a particular public key, or has a given hash.
Right, that's all that is needed. Either it's signed by the same issuer (or the response comes from a delegate thereof) or it's not a valid response. I suggest to study this subject a little bit better before coming to the wrong conclusions.
I suggest to study the problem space from outside your static rigid worldview before relying upon your already-evident wrong conclusions.
The fundamental rule of solving a problem: figure out what the problem is, and then figure out how to solve it. Don't simply try to force a particular pattern with the tools that you've created, if the tools themselves show signs of weakness. The tools have permitted certain attacks to exist. The tools do not need to permit those attacks to exist.
The Identity CA is not good for authorizing sites to run. Sites exist independently of the Identity CA infrastructure, and run with or without the CA. It's only the browser that's enabling the Identity CA to extort protection value.
Remove that extortion, and the Identity CA is actually an even better piece than it's currently contemplated to be.
-Kyle H
Eddy Nigg
>
> But then the certificate would be considered invalid if no
> revocation status was successfully received. That's why browsers
> should enforce it. I have it enforced and it works perfect.
>
>
> Sure, and now I as a business owner have to rely upon the
> infrastructure of a 3rd party for my cart being displayed without a
> "legitimate sites will not ask you to do this" warning.
Yes, you are also getting the service from a third party.
> What everyone has failed to remember is that this isn't just about the
> security of the end user, this is also about the security of the site
> and its usability without being libeled or slandered.
What????
>
> Because the existing revocation infrastructure relies solely upon the
> cryptography never being compromised.
Well, everything here relies on cryptography of sorts...what else would
you like to use? Soap?
> (The solution to cryptography which is crackable is to minimize
> reliance upon it, and put more faith in corroboration.)
I think this discussion is becoming useless. If you refer to a general
problem, it probably has nothing to do with either OCSP and other
revocation mechanism and the standards that define them.
>
> That information is passed to the client via the
> certificate-in-the-hands-of-Mallory -- i.e., in every certificate
> which the issuer mints. That information is not passed to the client
> as being authoritatively asserted by the parent of the intermediate.
> (In other words, if Mallory can control the content of his own
> certificate, Mallory can change the OCSP or the CRL location within
> the certificate.)
But he probably can't. If he can, there is a far bigger problem I guess...
> Really, why shouldn't a CA certificate include its points of contact
> for revocation within itself, instead of the certificates its key signs?
It's the egg and chicken problem. A certificate can't revoke itself, it
would be useless (we've been discussing the suicide notification already)
> But they don't have. Remember the 2nd preimage scenario:
Yes, we know that. No news, we guard against pre-imaging attacks and
others as much as possible.
> The fundamental rule of solving a problem: figure out what the problem
> is, and then figure out how to solve it. Don't simply try to force a
> particular pattern with the tools that you've created, if the tools
> themselves show signs of weakness. The tools have permitted certain
> attacks to exist. The tools do not need to permit those attacks to exist.
Well, I assume there is no perfect solution, but feel free to write your
own standards and hope to have them adopted. If they are good, they might...
> The Identity CA is not good for authorizing sites to run. Sites exist
> independently of the Identity CA infrastructure, and run with or
> without the CA. It's only the browser that's enabling the Identity CA
> to extort protection value.
I feel free to let somebody else answer those comments, I simply don't
have the time for it...
Gervase Markham
> Failing to implement the expected controls (Mozilla and others require)
> is not a failure of the security model at all, it's a failure of the CA.
> Specially when that CA promised to have that implemented after a
> previous failure.
Eddy,
Paul is not saying that the failure by Comodo/Comodo's RA is a failure
of the model. He is saying that the fact that all the browsers decided
to issue patches rather than rely on the revocation infrastructure means
that the revocation system, as currently implemented, doesn't work for
the purpose for which it is designed. And I agree.
It's quite possible to argue that it doesn't work because we haven't
implemented it properly. But whatever the reason, it doesn't work. And
we have to decide how to fix it. "Implement it properly" is one answer -
but not the only one.
Gerv
Eddy Nigg
> Paul is not saying that the failure by Comodo/Comodo's RA is a failure
> of the model. He is saying that the fact that all the browsers decided
> to issue patches rather than rely on the revocation infrastructure
> means that the revocation system, as currently implemented, doesn't
> work for the purpose for which it is designed. And I agree.
It's a failure to enforce the standards I believe - the patches are a
result thereof as the only more reliable defense. And it's still bad
because there will be scores of systems and browsers that will remain
vulnerable if and until they update.
> It's quite possible to argue that it doesn't work because we haven't
> implemented it properly.
Well yes - it's also a matter of policies. Many CA policies require the
relying party to check a certificate with the either the CRL or OCSP
responder, without having performed that check any warranty could be void.
Today most, if not all browsers are not hard failing when revocation
status was not successfully obtained. Which means, relying parties would
have a hard time to provide evidence that they checked the revocation
status.
> But whatever the reason, it doesn't work. And we have to decide how to
> fix it. "Implement it properly" is one answer - but not the only one.
I'm happy to hear if you have other options, in my opinion it's by
enforcing that the certificates (any and all) must contain revocation
CRLs and/or OCSP and those must be obtained successfully in order to
rely on it.