Re: Handling OCSP check failures
Paul Tiemann
using OCSP...
Eddy said...
If you use Firefox to check if an OCSP is working correctly you
> obviously have to set OCSP checking to hard fail, otherwise it will
> simply ignore a failed response.
>
> More than that, today 100% of all Mozilla Firefox users are vulnerable
> to some extend. An attacker can simply block access to the OCSP
> responder and an attack with a revoked certificate would succeed.
>
Robin Alden said...
> I agree. Treating a failed attempt to check revocation the same way you
> treat a successful revocation check is not a feature, it's a vulnerability.
>
[Paul Tiemann]
I'm interested in your opinions about what a good solution would look
like...
Here are my own opinions offered as a straw man. Maybe a discussion will
yield a better way to handle failed OCSP attempts.
Today we have two choices:
1) SILENT PASS: Act as if the check succeeded and status=good. Show
security indicators, including Green EV UI for EV certs.
2) HARD FAIL: An impassable brick wall with geek speak written on it: Secure
Connection Failed: The OCSP server experienced an internal error. (Error
code: sec_error_ocsp_server_error). There is a "Try Again" button, but
there is no way to say "Continue anyway" or "Try the CRL" -- you have to go
turn off the hard fails for all OCSP responders to get past the error.
Opinion 1: We need more than just these two ways before we change the
default behavior. Just switching the default to hard fail would make things
worse. I can think of two reasons:
Reason 1 - If hard fail were the default, then bad guys could use an OCSP
service as a DOS-amplifier against all of a CA's customers. Anyone employed
by a CA can imagine the nightmare scenario of having every customer calling
you at the same time because all of their Mozilla users are unable to login,
buy, use their email, etc... Should every small CA be forced to implement
an anycast global network with enough bandwidth to soak up a DDOS against
their OCSP service?
Reason 2 - There are various ways an OCSP attempt can fail:
- DNS resolution failure
- TCP handshake times out (routing issue somewhere between browser and OCSP
responder, firewalls, etc...)
- TCP handshake fails with "Connection Refused"
- TCP handshake succeeds, but request/response times out after the connect
(due to some server load issue, etc)
- OCSP response is malformed (bad or missing signature, data formatting
error)
- OCSP response is not within its Valid-From and Valid-To time window
- OCSP response is not signed by the issuing CA or an OCSP responder cert
issued by the CA
- You can probably think of a handful of other ways...
Opinion 2: I agree that it is bad to treat a failed OCSP attempt as a
successful status=good response. However, it seems to me that effectively
treating it as status=revoked is actually worse. By the numbers: What
percentage of certificates are status=good versus status=revoked? The
extreme minority are revoked. A failed OCSP attempt really means
status=unknown, and that should at least be treated differently than
status=revoked (the brick wall presented to the user should at least not be
10 feet high)
Here's a practical illustration: Exchange 2010 on Windows 2008 R2 will not
allow you to assign your SSL certificate unless it can get a status=good
response from the OCSP service listed in the certificate's Authority
Information Access. This causes a lot of trouble for people who disallow
outbound HTTP for their Exchange servers. I can see the wisdom in not
allowing a user to assign a status=revoked certificate. However, blocking
the certificate because of a failed status check just causes a lot of
headaches. In examples like this, it would be better to at least allow the
user to override a warning instead of putting up a brick wall.
Opinion 3: It is _extremely_ rare to see a certificate with an OCSP
responder defined, but no CRL defined. If an OCSP attempt fails to yield a
definitive answer, then the CRLs should be tried next. Only after both
methods are exhausted should the user have to deal with some kind of
"Certificate Status Unknown" warning. Throwing an error when OCSP fails and
the CRL would have worked seems like it would be an effective way to
discourage CAs from providing OCSP.
Opinion 4: Firefox should use GET requests for OCSP attempts instead of POST
requests. Using POSTs makes it so CAs can't use content delivery networks
for their OCSP services. We all want super-fresh OCSP responses. It's in
the interest of all browser makers to be able to get fresh OCSP responses as
quickly as possible. If OCSP could be served from CDN acceleration
services, everyone wins. Most of the CAs who operate OCSP responders could
get away with just CRLs which they can serve via CDN. Being a "good
citizen" by providing an OCSP service is made more difficult because of the
POST requests from Firefox.
Opinion 5: Firefox should cache successful OCSP responses across restarts.
At a minimum, it should cache responses for CA certificates. How many
revokes of CA intermediates have ever occurred?
It would help if each cached response had a success_count and
first_good_date were kept -- or some other tracking information that would
be useful to help a user decide whether to ignore a status=unknown error.
Best regards,
Paul Tiemann
[ CTO, DigiCert -- These opinions are my own, based on my work handling our
OCSP responders for a few years ]
Eddy Nigg
> I'm interested in your opinions about what a good solution would look
> like...
>
Some notes back....
> 1) SILENT PASS: Act as if the check succeeded and status=good. Show
> security indicators, including Green EV UI for EV certs.
>
Currently EV status is not shown in case OCSP fails, but shows the
regular SSL UI.
> - DNS resolution failure
> - TCP handshake times out (routing issue somewhere between browser and OCSP
> responder, firewalls, etc...)
> - TCP handshake fails with "Connection Refused"
> - TCP handshake succeeds, but request/response times out after the connect
> (due to some server load issue, etc)
> - OCSP response is malformed (bad or missing signature, data formatting
> error)
> - OCSP response is not within its Valid-From and Valid-To time window
> - OCSP response is not signed by the issuing CA or an OCSP responder cert
> issued by the CA
> - You can probably think of a handful of other ways...
>
Most of the points above really shouldn't happen, for this CAs operate a
critical infrastructure. In particular the points except #2 are the CAs
responsibility mostly.
> The
> extreme minority are revoked. A failed OCSP attempt really means
> status=unknown, and that should at least be treated differently than
> status=revoked (the brick wall presented to the user should at least not be
> 10 feet high)
>
That's probably one way doing it and should be considered.
> Opinion 3: It is _extremely_ rare to see a certificate with an OCSP
> responder defined, but no CRL defined. If an OCSP attempt fails to yield a
> definitive answer, then the CRLs should be tried next.
>
Yes, I would highly recommend such an implementation. More than that,
some have multiple CRL entries and they should be all tried before
giving up. This is important for certain disaster scenarios.
> Being a "good
> citizen" by providing an OCSP service is made more difficult because of the
> POST requests from Firefox.
>
With Firefox in relation to EV certs, the CA must have an OCSP responder
at the moment in order to show the EV UI. OCSP isn't optional in this
respect. Regarding POST versus GET, I believe that OCSP server stapling
will provide eventually the correct solution.
> Opinion 5: Firefox should cache successful OCSP responses across restarts.
>
I wonder how much of an impact that would have. Browsers aren't
restarted every here and now these days. I believe the effect would be
fairly limited.
> It would help if each cached response had a success_count and
> first_good_date were kept -- or some other tracking information that would
> be useful to help a user decide whether to ignore a status=unknown error.
>
This could be an interesting idea.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
David E. Ross
>
> Today we have two choices:
>
> 1) SILENT PASS: Act as if the check succeeded and status=good. Show
> security indicators, including Green EV UI for EV certs.
>
> 2) HARD FAIL: An impassable brick wall with geek speak written on it: Secure
> Connection Failed: The OCSP server experienced an internal error. (Error
> code: sec_error_ocsp_server_error). There is a "Try Again" button, but
> there is no way to say "Continue anyway" or "Try the CRL" -- you have to go
> turn off the hard fails for all OCSP responders to get past the error.
The "hard fail" case might be addressed by an implementation of bug
#548380. See <https://bugzilla.mozilla.org/show_bug.cgi?id=548380>.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. © 1997
Varga Viktor
> > The
> > extreme minority are revoked. A failed OCSP attempt really means
> > status=unknown, and that should at least be treated differently than
> > status=revoked (the brick wall presented to the user should at least
> not be
> > 10 feet high)
> >
>
> That's probably one way doing it and should be considered.
>
> > Opinion 3: It is _extremely_ rare to see a certificate with an OCSP
> > responder defined, but no CRL defined. If an OCSP attempt fails to
> yield a
> > definitive answer, then the CRLs should be tried next.
> >
>
> Yes, I would highly recommend such an implementation. More than that,
> some have multiple CRL entries and they should be all tried before
> giving up. This is important for certain disaster scenarios.
And of*course don't forget te multiple AIA:OCSP fields too.
I think the correct way, that you will get the first OCSP, then the second, third, ...
If none of them give you a correct answer, jum ont he CDP, and try them.
CDP can hold multiple entries too.
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
_______________________________________________________________________
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 ________________________________________________________________________________________
Eddy Nigg
>> Yes, I would highly recommend such an implementation. More than that,
>> some have multiple CRL entries and they should be all tried before
>> giving up. This is important for certain disaster scenarios.
> And of*course don't forget te multiple AIA:OCSP fields too.
>
> I think the correct way, that you will get the first OCSP, then the second, third, ...
> If none of them give you a correct answer, jum ont he CDP, and try them.
> CDP can hold multiple entries too.
Correct. However I haven't seen multiple OCSP entries so far.
Varga Viktor
It includes 3 AIA:OCSP, 3 AIA:CaISsuer and 3 CDP too.
I like the redundancy. :)
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> -----Original Message-----
> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> [mailto:dev-security-policy-
> bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Eddy Nigg
> Sent: Monday, July 19, 2010 8:34 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Handling OCSP check failures
>
> On 07/19/2010 06:00 PM, From Varga Viktor:
> >> Yes, I would highly recommend such an implementation. More than
> that,
> >> some have multiple CRL entries and they should be all tried before
> >> giving up. This is important for certain disaster scenarios.
> > And of*course don't forget te multiple AIA:OCSP fields too.
> >
> > I think the correct way, that you will get the first OCSP, then the
> second, third, ...
> > If none of them give you a correct answer, jum ont he CDP, and try
> them.
> > CDP can hold multiple entries too.
>
> Correct. However I haven't seen multiple OCSP entries so far.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> XMPP: star...@startcom.org
> Blog: http://blog.startcom.org/
> Twitter: http://twitter.com/eddy_nigg
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy