Making OCSP soft fail smarter
Gervase Markham
"is revoked" response is treated as "is not revoked". There is a user
pref that allows the user to change that, so that any response other
than "is not revoked" is treated as "is revoked".
IMO, we need to be smarter about that.
Here's a straw man:
OK:
200 response with OK
No response (network problems)
Not OK:
200 response with revocation
400 response (OCSP responder actively denying response)
500 response (OCSP responder broken)
What do people think? Putting 400 and 500 in "not OK" makes it harder to
inject a failure in order to get Firefox to pass a cert. Although one
can still inject an OCSP tryLater <sigh>.
Gerv
Eddy Nigg
Firefox uses OCSP but, by default, any response other than a definite "is revoked" response is treated as "is not revoked". There is a user pref that allows the user to change that, so that any response other than "is not revoked" is treated as "is revoked".
IMO, we need to be smarter about that.
Here's a straw man:
OK:
200 response with OK
No response (network problems)
What about those certificate which don't have any OCSP URI in the certificate? Should they be treated as....?
-- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP: star...@startcom.org Blog: http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg
Rob Stradling
mozilla.dev.security?
Daniel Veditz said yesterday...
"An alternate approach I'd like to lobby our front-end guys on would be
to put up a scary red bar when we can't validate OCSP. Users can still
get to their sites so they won't ditch us for another browser, site
owners are still getting traffic so they won't be breathing down _our_
neck (too much), but the site will look a little scary and link to an
explanation so site owners can take the issue up with their CA and users
have the opportunity to decide not to submit sensitive data over the
connection."
This morning I suggested changing the boolean user pref of which you speak
into 3 radio buttons:
"When an OCSP server connection fails:
o ignore the problem
o show a warning (the new default)
o treat the certificate as invalid"
So rather than just "OK" and "Not OK", I'd like to see 3 categories:
1. OK. Continue to download and display the webpage.
2. Maybe OK. Display a warning message about problems with the response from,
or problems accessing, the CA's OCSP Responder. Continue to download and
display the webpage.
3. Not OK. Display a message that the certificate is revoked. Block access
to the webpage.
"Maybe OK" would be treated as "OK" if "ignore the problem" is selected, or
as "Not OK" if "treat the certificate as invalid" is selected.
I would treat No Response, 400 response, 500 response and "tryLater" as "Maybe
OK"s.
--
Rob Stradling
Senior Research & Development Scientist
C·O·M·O·D·O - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Gervase Markham
> Gerv, have you read the current "security.OCSP.require in Firefox" thread on
> mozilla.dev.security?
Er. Yes. This discussion is happening in multiple places at the moment,
and I lost track :-) Let's carry on with Dan's thread.
Gerv
Ian G
> Firefox uses OCSP but, by default, any response other than a definite
> "is revoked" response is treated as "is not revoked". There is a user
> pref that allows the user to change that, so that any response other
> than "is not revoked" is treated as "is revoked".
>
> IMO, we need to be smarter about that.
> Here's a straw man:
My view: I would defer any "smarter" things that reduce customer
usability until (a) everyone has OCSP really well worked throughout,
end-to-end ... and (b) we see some actual evidence that suggests that
the risk of an OCSP interference is something worth worrying about.
By far the number one threat to PKI is denial of service. That is, it
denies service to users, and users go elsewhere, and are then
unprotected. As the number one threat that PKI could help with is
secure browsing, if it was widely deployed, and secure browsing is
resulting in billion dollar losses ... it is far more important to
spread usage of certificates than to make them secure against imagined
and theoretical bogeymen.
That's just me :)
iang
Wes Kussmaul
Not OK:
300 OCSP blocked by AV software, vendor fined $1 for each occurrence
Wes Kussmaul
Anders Rundgren
particularly good idea because the only likely case for a revocation
is when a CA fails to validate a customer. That has happened
but not often enough to motivate the building of new infrastructure.
It seems like an easier way to just roll your own certs if you want
to screw somebody because it is a fairly risky business exposing
your identity when you are in a fraudulent mode :-)
Somewhat related: It seems that few VPNs perform verification
checks except during login which casts a certain shaddow over
the verification concept for mobile devices.
Eddy Nigg
> My view: I would defer any "smarter" things that reduce customer
> usability until (a) everyone has OCSP really well worked throughout,
> end-to-end ... and (b) we see some actual evidence that suggests that
> the risk of an OCSP interference is something worth worrying about.
Which means NEVER, but as usual thanks for your thoughts and
contributions. It was very helpful ;-)
Robert Relyea
> Firefox uses OCSP but, by default, any response other than a definite
> "is revoked" response is treated as "is not revoked". There is a user
> pref that allows the user to change that, so that any response other
> than "is not revoked" is treated as "is revoked".
>
> IMO, we need to be smarter about that.
We have to be very careful here. There is a major risk in trying to
prevent the attacker from intercepting the OCSP response. Here's why:
For an attacker with a compromised certificate:
Case 1: The attacker does not have the ability to block the OCSP
responder, or modify the response.
We get the OCSP response which says revoked and we don't trust the cert.
Case 2: The attacker can modify the response.
The attacker modifies the OCSP packet. He can:
1) invalidate the signature. The packet says revoked, but we
don't trust it because the signature isn't valid.
2) changes revoked to not revoked. Again, we ignore this because
the signature isn't valid.
3) Moxie's attack.
We can solve 1 & 2 by considering a bad signature as revoked.
We can solve 3 by ignoring the unsigned status fields.
4) He can modify the http response to some other status (400,500).
We can solve 4 by your proposal.
Case 3: The attacker can substitute his own response.
The attacker can give a funky status (400,500) (looks like 2.4), or
the attacker can give an OCSP response that looks valid except the
signature (looks like 2.2).
Case 4: The attacker can block the response (or the request).
These show up as no response. This is indistinguishable from network
problems.
It turns out that of all cases 2, 3, and 4, case 4 is the easiest
(simply overload the requested OCSP server). Also, if you can do 2, and
3, you can always do 4 (You just drop the packet on the ground). So
while an attacker may have lots of things he can do to us, he can always
do the one case that we are going to always accept under this proposal.
OK, so lets ignore this case, and assume that the attacker is stupid (or
there is a case 2 or 3 that doesn't allow the attacker to just drop the
packet) and mounts a case 2 or 3 attack.
In order to be successful, the attacker needs both a compromised
certificate and the ability to mount a case 2 or 3 attack. So we defend
against cases 2 or 3. Firefox goes out, by default, with where it
rejects any cert if it gets a skanky OCSP response (bad signature,
unexpected http status response, etc.).
Now an attacker, who can mount a case 2 or 3 attack, can attack websites
which he does not have a compromised certificate for:
If he could mount case 2, he could:
1) modify the signature of a valid response (indistinguishable from case
2.2).
2) change a valid response to an invalid response (indistinguishable
from case 2.1).
3) change the http response (indistinguishable from 2.4).
If he could mount case 3, he could supply his own funky http status, or
his own response without a valid signature.
In all these cases, Firefox would now reject the certificate as revoked.
The attacker now has the ability to effectively shut off any number of
https websites he chooses simply by attacking the OCSP responder for the
CA that certified that website.
So in trying to prevent an attack based on an OCSP responder, we have
expanded the possible attack surface such an attacker could leverage (at
the same time failed to prevent he exact attack we were initially trying
to prevent).
OK, so does that mean we ignore this strawman?
Not necessarily. The ecosystem is highly interdependent, and changes to
the equation may change our vulnerability to different attacks. For
instance, if we believe attacks of class 2 and 3 are sufficiently
difficult to be rare, then we may go ahead with making them fatal. In
this case we aren't necessarily protecting against some OCSP attacker
(who can always revert to class 4 attacks), but we are making sure our
infrastructure is working properly. If a CA puts up a non-working OCSP
responder, it will be come obvious quickly, and there will be lots a
pressure to get that CA to fix it's responder.
In doing so, we assume that the internet infrastructure people would
quickly detect the OCSP based DoS attack in the real world and shut it
down (I am not naive enough to believe that class 2 or 3 attacks are
impossible, not as long as DNS can be subverted).
Adding OCSP stapling to the mix makes things even better. Now websites
have protection against OCSP DoS attacks by supporting stapling. The
OCSP response need not be fetched since we already have it.
In summary, we have to be careful about 'doing something because it just
seems right'. We need to truly understand the risks, and what we are
getting for those risks.
bob
Robert Relyea
> Gerv, have you read the current "security.OCSP.require in Firefox" thread on
> mozilla.dev.security?
>
> "An alternate approach I'd like to lobby our front-end guys on would be
> to put up a scary red bar when we can't validate OCSP. Users can still
> get to their sites so they won't ditch us for another browser, site
> owners are still getting traffic so they won't be breathing down _our_
> neck (too much), but the site will look a little scary and link to an
> explanation so site owners can take the issue up with their CA and users
> have the opportunity to decide not to submit sensitive data over the
> connection."
>
>
> So rather than just "OK" and "Not OK", I'd like to see 3 categories:
> 1. OK. Continue to download and display the webpage.
> 2. Maybe OK. Display a warning message about problems with the response from,
> or problems accessing, the CA's OCSP Responder. Continue to download and
> display the webpage.
> 3. Not OK. Display a message that the certificate is revoked. Block access
> to the webpage.
>
and unknown. Failure to connect to the OCSP responder is treated as
unknown (as well as an OCSP response which explicitly says 'Unknown').
The pkix processing has a very complex set of processing rules that tell
it how to treat an overall unknown response.
The problem is pkix is processing a chain of certificates trying to give
you the answer "is this chain good". There are more reasons for a chain
to fail than simply revocation.... and there can be more than one cert
that is revoked.... and there can be more than once source of revocation
information (pkix will also try to fetch CRLs if OCSP fails).
That being said, you may be able to implement this policy as such
(warning this is pseudo code -- spellings are made up, not actual NSS
spellings, but the basic functionality is there):
status = PKIX_VerifyCert(.... revocation_policy_strict ....);
if (!status & reason == revoked) {
status = PKIX_VerifyCert(.... revocation_policy_best_effort ....);
if (status) {
set_revocation_warning(.....);
}
}
/* continue processing */
I believe the corner cases will still old here, the bigger risk is that
you somehow process a different chain in the latter case (though I'm
currently not able to construct one that presents an attack*). We should
walk through all the scenarios to make sure this is safe.
-----------------
* The closest I've come is this: A certificate with no AIA or CRLDP
extension issued by a revoked intermediate CA. Attacker blocks the OCSP
responder for the intermediate CA. The first call fails because the user
cert has no way of providing revocation information. The second succeeds
because the attacker has blocked our revocation information. But the
result is still exactly what we guaranteed the user. We would get the
page with the revocation warning. The surprising thing for the user is
they get the same warning whether or not the intermediate was revoked,
but that fits within the policy we've defined... and it is a bit of a
corner case.
Eddy Nigg
> On 10/13/2009 06:54 AM, Gervase Markham wrote:
>
>> Firefox uses OCSP but, by default, any response other than a definite
>> "is revoked" response is treated as "is not revoked". There is a user
>> pref that allows the user to change that, so that any response other
>> than "is not revoked" is treated as "is revoked".
>>
>> IMO, we need to be smarter about that.
>>
> We have to be very careful here. There is a major risk in trying to
> prevent the attacker from intercepting the OCSP response. Here's why:
>
> For an attacker with a compromised certificate:
> Case 1: The attacker does not have the ability to block the OCSP
> responder, or modify the response.
> We get the OCSP response which says revoked and we don't trust the cert.
>
> Case 2: The attacker can modify the response.
> The attacker modifies the OCSP packet. He can:
> 1) invalidate the signature. The packet says revoked, but we
> don't trust it because the signature isn't valid.
> 2) changes revoked to not revoked. Again, we ignore this because
> the signature isn't valid.
> 3) Moxie's attack.
Bob, a way to mitigate attacks on OCSP responders (DOS) can be mitigated
to by also supporting CRLs at multiple locations. Also we considered
already multiple different locations for OCSP responders, I'm not sure
if NSS (and other software) would support that.
Varga Viktor
> particularly good idea because the only likely case for a revocation
> is when a CA fails to validate a customer. That has happened
> but not often enough to motivate the building of new infrastructure.
Dont forget the sale of the domain or the server hacking.
Revocation is needed in these cases.
regards.
Viktor
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Robert Relyea
>>
>> In summary, we have to be careful about 'doing something because it just
>> seems right'. We need to truly understand the risks, and what we are
>> getting for those risks.
>>
>
> Bob, a way to mitigate attacks on OCSP responders (DOS) can be
> mitigated to by also supporting CRLs at multiple locations. Also we
> considered already multiple different locations for OCSP responders,
> I'm not sure if NSS (and other software) would support that.
NSS has supported preloaded CRL, but it treats that separately from OCSP
(it always checks the CRL if it's loaded, it never fetches the CRL. OCSP
is still interegated with the same semantics as if the CRL didn't exist.
As of NSS 3.12, the libpkix code has a much more flexible plan for
revocation. It can fetch OCSP, CRL, or both. It can work down the list
and stop when it gets an answer (either revoked or not), and it can be
configured to require an answer from one of the sources. I believe as of
the most recent release of NSS it can also fulfill such requests from
it's cache (which is a big win when dealing with intermediates). The CRL
fetching on the fly is a relatively recent addition. I don't believe it
deals with multiple OCSP servers, but alexi could answer that question.
Currently mozilla products only use libpkix when validating EV status.
This, of course, only helps if the CRL and OCSP servers are on different
hosts with different hostnames, preferably even different domain names.
The proxied case isn't solved, but anyone owning a proxy has a much
easier DoS than preventing OCSP and CRL fetching;).
bob
Ian G
better, here is a fairly eloquent article from Bruce Schneier that might
help. I don't always agree with him, but on this article, I am in full
agreement. First and last paras only.
http://threatpost.com/blogs/difficulty-un-authentication-128
In computer security, a lot of effort is spent on the authentication
problem. Whether it�s passwords, secure tokens, secret questions, image
mnemonics, or something else, engineers are continually coming up with
more complicated -- and hopefully more secure -- ways for you to prove
you are who you say you are over the Internet.
[snip]
Designing systems for usability is hard, especially when security is
involved. Almost by definition, making something secure makes it less
usable. Choosing an unauthentication method depends a lot on how the
system is used as well as the threat model. You have to balance
increasing security with pissing the users off, and getting that balance
right takes time and testing, and is much more an art than a science.
Gervase Markham
> IMO putting OCSP or CRLs in public SSL certificates was never a
> particularly good idea because the only likely case for a revocation
> is when a CA fails to validate a customer. That has happened
> but not often enough to motivate the building of new infrastructure.
That's just not true. Debian weak keys and the recent \0 certs are both
cases where customer validation was done to the appropriate level but
the certs still had to be revoked.
Gerv
Gervase Markham
> It turns out that of all cases 2, 3, and 4, case 4 is the easiest
> (simply overload the requested OCSP server). Also, if you can do 2, and
> 3, you can always do 4 (You just drop the packet on the ground). So
> while an attacker may have lots of things he can do to us, he can always
> do the one case that we are going to always accept under this proposal.
A very good point.
Gerv
Ian G
Note the careful insertion of the word "likely". I think what Anders is
saying is that revocation is purposed to a failure in validation. That
is, in security modelling, revocation is the mitigation technique that
is put in place for that threat.
Revocation is not thought of as being purposed to mitigate software
bugs. That's probably because a software bug is too hard to predict,
and the real fix there is to fix the darn software.
However, I'm not comfortable with Ander's complete claim. I would think
that stolen keys is a good case where revocation is a mitigating
technique. (But maybe he will point out that this hasn't happened much
either, and doesn't justify the building of the new infra.)
In the absence of any particular losses, it is certainly complicated to
predict what is the threat we are best putting our resources against.
And in another related thread, have a look at this:
http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html
What this says to me (and I really haven't researched it ...) is that
Verisign / DNSSEC / etc have dumped the concept of revocation
altogether, and are instead relying on fast key switching.
iang
Eddy Nigg
> On 15/10/2009 15:21, Gervase Markham wrote:
>> On 13/10/09 16:18, Anders Rundgren wrote:
>>> IMO putting OCSP or CRLs in public SSL certificates was never a
>>> particularly good idea because the only likely case for a revocation
>>> is when a CA fails to validate a customer. That has happened
>>> but not often enough to motivate the building of new infrastructure.
>>
>> That's just not true. Debian weak keys and the recent \0 certs are both
>> cases where customer validation was done to the appropriate level but
>> the certs still had to be revoked.
>
>
> Note the careful insertion of the word "likely". I think what Anders
> is saying is that revocation is purposed to a failure in validation.
Which is obviously not correct. Most revocations happen due to loss and
compromise of private keys, retirements, software bugs, misuse, but
seldom due to validation failures.
Anders Rundgren
>Which is obviously not correct. Most revocations happen due to loss and
>compromise of private keys, retirements, software bugs, misuse, but
>seldom due to validation failures.
I would be surprised if a single public-TTP-issued server-certificate has ever
been revoked due to loss or compromise of private keys.
But I don't *insist* that OCSP validation is a bad thing I just think that
using plain-vanilla HTTP or rolling your own cer seem to be an easier
way than faking an identity for a CA.
Anders
Eddy Nigg
> But I don't *insist* that OCSP validation is a bad thing I just think that
> using plain-vanilla HTTP or rolling your own cer seem to be an easier
> way than faking an identity for a CA.
>
Agreed, but this is obviously an entire different issue.