OCSP error

[mikeysc]

Lately (last 2? days), I've been getting an OCSP error for this site. I'm using v25b2 but I have no reason to think it is related to that. I checked the entries in about:config which contain OCSP and they are all at default values. I can't point it to anything specific and it has only happened on the PM forum so far. If there is something I should check, or remove/reset, in Certificates, I'm willing but no idea what at this point. This is just general FYI; no troubleshooting help desired unless someone has a good idea of the cause. Otherwise, I'm not worried about it.

So I just thought I'd post this to see if anyone else sees it. Even though the message says it is the site causing it, it is and has been working fine now and at other times so I don't think that is likely. Also, SeaMonkey hasn't shown this problem. I had just restarted PM to see if that would help after getting this error. Same error after restart, but this time I chose Try Again and got right in. This is the error message:

Secure Connection Failed

An error occurred during a connection to forum.palemoon.org. The OCSP response contains out-of-date information. (Error code: sec_error_ocsp_old_response)

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.

[Moonchild]

We're aware of this; it seems to be a problem with caching done by CloudFlare of OCSP responses, and stapling expired (cached) OCSP responses to SSL sessions. Since Pale Moon supports OCSP stapling, it causes these errors in the browser. CloudFlare is aware of it and is investigating. You should be able to simply press "try again" to bump the cloud server and get new data, after which it will load.

I'm not sure if SeaMonkey supports OCSP stapling in the same fashion. If it doesn't then this error will never occur since it will use a different method to check revocation status of certificates.

[Moonchild]

It looks like it may actually just be a server defect. NGinx has an issue where it may serve an expired OCSP response stapled to an SSL session.
Since CloudFlare uses nginx as their reverse proxy software to serve data to users, and the forum uses CloudFlare, this can happen when you re-visit the site over SSL after a time. They are investigating this further at the moment - it seems to be a global issue (your report is at least the third mention).

SeaMonkey and Firefox won't show you the error (even if it does occur) because Mozilla has built in a workaround for this. Of course not showing the error also means that server operators never become aware of the problem where their server doesn't act according to spec. Basically, because some large sites initially had problems with stapling and instead of having the servers fixed, the browser was fitted with a workaround for this particular issue. So, you get this error because Pale Moon adheres to the RFC/spec more closely and aborts the connection if there is an error with the stapled OCSP response, while Firefox and SeaMonkey never tell you and silently fall back to standard OCSP (not even sure about that, it may actually just ignore and continue with cert verification).

I can build in the same workaround, but that won't fix the root cause of the problem.

[x-15a2]

I can build in the same workaround, but that won't fix the root cause of the problem.

Please don't. Or if you decide that you will, plz make it optional. Thanks!

[Night Wing]

@Moonchild

I have the same thing occuring in both Windows Pale Moon and linux Pale Moon. But, you don't have to build a workaround. Eventually the problem will get fixed.

[Moonchild]

I'd rather not use the workaround, since it's directly against RFC spec. Basically Pale Moon giving the error means it's more RFC compliant than Firefox
Just for the sake of ease for some people, though, it would be a good option to have.

[Jonguy30]

For the last couple of times I've visited this forum, I've been presented the with the "OSCP Error" page every time. It's no big deal as it goes away when I "Try again". I didn't get it back when it was reported, but now it has hit me too...

[Moonchild]

I'm still waiting for a response from CloudFlare. I suspect it may take some time. Whether you get the error page or not depends on if you are the first to visit the forum from your general area after a while. As said, the "try again" option will fix it until the server-side is taken care of.

[New Tobin Paradigm]

So it is possible whatever server I am hitting at cloudflare likely has a fresh non-invalid copy most of the time because I have the unread posts sitting in a pinned tab refreshing every few min so that means others hitting the the same cloudflare server are experiencing the issue less?

[Moonchild]

So it is possible whatever server I am hitting at cloudflare likely has a fresh non-invalid copy most of the time because I have the unread posts sitting in a pinned tab refreshing every few min so that means others hitting the the same cloudflare server are experiencing the issue less?

Yes, since you're effectively keeping the cloud edge supplied with a fresh copy of the cert.

[New Tobin Paradigm]

So it is possible whatever server I am hitting at cloudflare likely has a fresh non-invalid copy most of the time because I have the unread posts sitting in a pinned tab refreshing every few min so that means others hitting the the same cloudflare server are experiencing the issue less?

Yes, since you're effectively keeping the cloud edge supplied with a fresh copy of the cert.

Fun!

[Moonchild]

I've discussed this some with the Mozilla Security team (and we agreed on disclosure of the issue below to discuss openly) and I've built in the same workaround in Pale Moon in case a site really insists on keeping the expired OCSP response. However, it will be behind a new pref security.ssl.allow_unsafe_ocsp_response and will default to false (keeping the current behavior of aborting the connection).

Why this inconvenience? A few reasons and concerns that I'd like to state here and see some feedback on (and if anyone can check/verify if Firefox can be abused this way, it's something to note):

1. Aborting the handshake means following RFC6066, which is a Good Thing™. Firefox is deliberately not following the spec to prevent the inconvenience of having to press "try again" or being unable to access some really improperly set up servers.
2. Since the workaround for the inconvenience is simply ignoring this particular error response, and there is no code at all to retry a connection or fall back to something else, despite what the code comment says, checking of the validity of the OCSP response is simply incomplete.
3. More importantly, I think this can be abused: If a server operator uses a revoked (but otherwise verifiable) certificate, and purposefully staples an expired OCSP response, Firefox would simply accept it as valid if the cert checks out OK otherwise. This would allow malicious server operators with illegal certificates (that are since revoked) e.g. after a CA has been compromised or has given out certificates to entities it shouldn't have, to create a situation where the revoked certificate can be used. Users would not be any wiser to the state of the certificate because the browser will simply display the validation of the certificate that checks out otherwise. There's a good reason certificates get revoked, you don't want to effectively ignore that.

Especially the last point was a concern of me why I discussed this with MozSec before. They told me open discussion of these concerns would be beneficial and OKed disclosure of it, hence this post here. As said I'm curious to know if anyone can come up with a proof of concept for Firefox being vulnerable here; it might be tricky to set up and I simply don't have the time to spend on this.

[Kocayine]

So... is setting security.ssl.allow_unsafe_ocsp_response to true a bad idea? Because I've been getting this error occasionally. It's not a big deal to just press F5 but I wouldn't mind avoiding it...

[Moonchild]

So... is setting security.ssl.allow_unsafe_ocsp_response to true a bad idea? Because I've been getting this error occasionally. It's not a big deal to just press F5 but I wouldn't mind avoiding it...

It can potentially be abused. I've tried opening a dialogue about this with the people at Mozilla Security, but they didn't seem to be too interested in getting to the bottom of this.

Basically, what Firefox does by default and what Pale Moon can do with the setting enabled is simply ignore the error. The stapled response is accepted even if the OCSP response has expired and is no longer valid for the certificate it is stapled to. Basically, it short-circuits OCSP-checking, so you could potentially have a revoked (but otherwise valid) server certificate that doesn't get checked anymore for revocation. I don't think this is being exploited "in the wild" at the moment, since it's still tricky to get to the point where abuse is possible, but it is very much a concern.

e.g. if an incorrect cert was issued by a certificate authority, it would normally be revoked on the short term. Attackers could still use this certificate by stapling an expired OCSP response to it after it has been revoked, that is otherwise valid for the certificate (i.e.: a response retrieved before the certificate was revoked) and the browser would just accept the certificate as valid and active, as a result. As said, this is tricky and situational, but it's an unsafe setting if the browser allows this - that's why the setting is disabled by default.

[back2themoon]

Getting this not-so-annoying error lately, too. Hope they fix it soon since I won't apply a potentially unsecure "fix". Thanks for the info.