745747 - Treat "OCSP status unknown" as "OCSP status revoked" (even in soft failure mode)

Status: NEW

(NSS :: Libraries, defect, P5)

Description

[Kai Engert [:KaiE:]]

Ryan Hurst proposed that NSS should treat a
  "signed OCSP response with status unknown"
as a revoked certificate.

(If the CA's OCSP responder claims it doesn't know the status of a certificate, then we shouldn't trust it.)

Comment 1

[Kai Engert [:KaiE:]]

Does anyone disagree with the proposal?

Comment 2

[Eddy Nigg (StartCom)]

Yes - unknown !- revoked....it's unknown. You can make it fail, but should use a different code since a revoked certificate should never ever become valid again.

Comment 3

[Ryan Hurst]

Eddy, a few things.

First, a revoked certificate can become valid again -- remember suspended.

Second, the question here is should browsers fail if a responder says - OCSP:Unknown; My opinion is yes, we are saying we do not know the status of this, therefor you can not assume its good.

Then the question becomes what is the user experience to use, IMHO users can't tell the difference from the various states so grouping these into the revocation failure is fine.

Comment 4

[Eddy Nigg (StartCom)]

(In reply to Ryan Hurst from comment #3)
> First, a revoked certificate can become valid again -- remember suspended.

Isn't that a different reason? Anyway, not sure how many really support /suspend/ in their CPS, at least we don't.

> Second, the question here is should browsers fail if a responder says -
> OCSP:Unknown; My opinion is yes, we are saying we do not know the status of
> this, therefor you can not assume its good.

Sure, but just don't report revoked because you actually don't know. Fail is OK, the reason matters IMO.

Comment 5

[Ryan Hurst]

Its a revocation reason but its still revoked.

GlobalSign supports treating unknown as a hard failure.

We think the best way to handle the hard failure in the UI is up to each respective browser but think mapping into the current revoked case is fine since we wont say unknown unless its exceptional.

Comment 6

[Kai Engert [:KaiE:]]

If the suggestion is
   treat as revoked
   but
   don't say revoked

then this bug would involve introducing a new error code, and updating all code to treat both codes functionally equivalent, but with a different user message.

Comment 7

[Eddy Nigg (StartCom)]

+1

Comment 8

[ryan_hurst]

Kai(In reply to Kai Engert (:kaie) from comment #6)
> If the suggestion is
>    treat as revoked
>    but
>    don't say revoked
> 
> then this bug would involve introducing a new error code, and updating all
> code to treat both codes functionally equivalent, but with a different user
> message.

IMHO it would be fine to just say revoked, I do not think a user will care about the subtleties of the two states.

Comment 9

[Gervase Markham [:gerv]]

There are two UI states for a certificate that a user cares about - good and bad. An "unknown" response is currently treated as "good". DigiNotar shows us that not right. If a CA doesn't know about a cert, and specifically tells us so, we should treat that as "bad", not as "good". 

We need to make sure it won't break the web, but assuming it doesn't, I strongly support this.

Gerv

Comment 10

[Adam Langley]

Attachment: patch

Simply in the interests of being concrete, this patch marks "unknown" status as "revoked". The question of whether that's the right behaviour is left to the reader :) If not, I think https://bug769067.bugzilla.mozilla.org/attachment.cgi?id=637276 provides a roadmap for adding a new error code for this case.

Comment 11

[ryan_hurst]

This wont break the web :)

Comment 12

[Thiago]

I disagree with this treatment. If OCSP response is Unknown or the OCSPResponseStatus isn't successful and the certificate has the CRL Distribution Point Extension then the CRL should be downloaded and verified.

The certificate can't be treated as revoked only for the OCSP response since certificates can be validated against CRLs (the ones that have the extension).

PS: I think this bug is related with https://bugzilla.mozilla.org/show_bug.cgi?id=692992 and maybe can be marked as duplicated.

Comment 13

[ryan_hurst]

Thiao, I too am a fan of fail-over from AIA to CRLDP however I believe it only makes sense for non-authoritative responses (like I could not connect to the server, access denied, internal error, etc).

When you get an authoritative response (a signed response in the case of OCSP) checking back with the CA with different mechanism to ask the question of "are you sure about that" is wasteful.

Remember RFC 2560 says:
"The "unknown" state indicates that the responder doesn't know about the certificate being requested."

and RFC 51029 states:

"OCSP responders that do not have access to authoritative records for a requested certificate, such as those that generate and distribute OCSP responses in advance and thus do not have the ability to properly respond with a signed "successful" yet "unknown" response, will respond with an OCSPResponseStatus of "unauthorized"."

Unknown is clearly a authoritative response, if Mozilla was to fallback in this one authoritative case why not in the others, for example download all CRLs and require them to be consistent, vs treat them as multiple points where the same information is available?

Would the client also double check authoritative goods and revokes? How would it rationalize freshness of response?
 
Then there is the stated intent of RFC 2560 which is:

as well as:
   "OCSP may be used to satisfy some of the operational requirements of
   providing more timely revocation information than is possible with
   CRLs and may also be used to obtain additional status information."

Clearly a replacement designed with the intention to provide "better" data.

I agree this may be a dupe of that bug.

Comment 14

[Thiago]

The "double check" would be occur only when some negative cases happens. For me an "Unknown" answer do not means that the certificate is revoked. It is better a warning message that the revocation state could not be verified.

I have this problem with an CA where. I agree that they implementation of OCSP is wrong but deny to user the access to webpage is a strong response, no?

In my case, with Mozilla Firefox I was unabble to access the webpage. The only option that I have is a "Try Again" button. Even an "Add Exception" option was not gave. And this sittuation is bad.

With IE and Google Chrome they use the system API. In my work is Windows so they call the CryptoAPI. I enabled log events and saw that this API fallback to CRL when OCSP response isn't good and I agree with that behaviour cause the certificate has other options to verify its valitity.

PS: I tried to alert the CA of this problem but they called me from a level one support that even know what is an OCSP and was thinking that the problem is of my certificate.

Comment 15

[ryan_hurst]

Thiago, you are correct it does not mean revoked it does however mean you reached the CA (or its official delegate) and they know nothing about this certificate and therefore can not tell you the certificate is "good".

Keep in mind that the by exposing the OCSP responder and its ability to produce Unknown the CA as exposed an HSM with limited resources for signing; they would only bother doing this for a message that they felt was important enough to protect.

If it was a hint it would just be a "exception message" and not be signed and therefore be something you can not rely on for policy decisions.

The intention of the authors is that this is an authoritative response.

In my conversation with Kai that triggered this bug I indicated that this response should be treated as "revoked" what I should have stated was "treated with the same severity as being revoked".

As for your scenario, I was the lead for the Windows CryptoAPI and it only falls back in non-authoritative failures, e.g. if I can not connect or I connect and the responder indicates a "exception error" ocured it will then try the CRL.

I also agree that this is needed in Mozilla but this is unrelated to this topic.

Mozila's ignoring the error from the responder represents a security risk, one with no value to the user - they made the request, they took the perf hit, they got the response and they ignore it.

Comment 16

[Thiago]

Maybe Microsoft has changed this behavior on Windows 7 cause I verified the logs and it discarded the OCSP response and falled back to CRL. Actually, I was searching for the answers why on IE and Chrome I do not receved any errors and with Mozilla I cannot access the webpage.

There is a few documentation about the browsers behaviour (at least my searches did not resulted in good informations) so I started to search for it. So, here I am trying to understand the situation :)

Comment 17

[ryan_hurst]

XP SP3, Vista and Windows 7 will behave the same in this regard I can not speak for the current Windows 8 behavior as it may have changed since I left the company.

There may be other reasons why a OCSP response was "discarded", for example it may be signature invalid, be a non-authoritative error, etc.

feel free to email me at ryan _ hurst at hot mail if you want help diagnosing the failure.

Comment 18

[Kaspar]

(In reply to Gervase Markham [:gerv] from comment #9)
> There are two UI states for a certificate that a user cares about - good and
> bad. An "unknown" response is currently treated as "good".

The last sentence isn't really true when considering what the actual NSS code currently does. Due to the peculiar way of checking the return code in CERT_CheckOCSPStatus(), an OCSP response with status unknown is treated as a hard failure already, irrespective of the value of OCSP_Global.ocspFailureMode:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certhigh/ocsp.c&rev=1.79&mark=4851-4856#4825

The current NSS code will only adjust rvOcsp (in line 4854) when the return value from ocsp_GetOCSPStatusFromNetwork does not indicate success. For OCSP responses with status unknown, ocsp_GetOCSPStatusFromNetwork will signal success in rv (NSS was able to fetch a response, after all), and only rvOcsp will be set to SECFailure (since ocsp_GetOCSPStatusFromNetwork will call ocsp_CacheEncodedOCSPResponse in line 5052 to populate rv_ocsp, and ocsp_CacheEncodedOCSPResponse in turn calls ocsp_SingleResponseCertHasGoodStatus in line 5169 to determine if the response for the specific cert is "good").

The net effect in Firefox is that the handshake will hard fail with SEC_ERROR_UNKNOWN_CERT even when security.OCSP.require is false, and this status is also added to the OCSP cache, so is therefore a rather permanent way of denying access to the site (you need to turn off OCSP checking to get around it).

(In reply to ryan_hurst from comment #15)
> the Windows CryptoAPI and it only
> falls back in non-authoritative failures, e.g. if I can not connect or I
> connect and the responder indicates a "exception error" ocured it will then
> try the CRL.

Not really correct, as you documented yourself at http://unmitigatedrisk.com/?p=155.

> Mozila's ignoring the error from the responder represents a security risk,

Right now it is not, as explained above - so if "everyone" agrees that the behavior described in comment 0 is really the way to go, then this bug can probably be resolved as INVALID...

Comment 20

[Gervase Markham [:gerv]]

(In reply to Kaspar Brand from comment #18)
> The net effect in Firefox is that the handshake will hard fail with
> SEC_ERROR_UNKNOWN_CERT even when security.OCSP.require is false, and this
> status is also added to the OCSP cache, so is therefore a rather permanent
> way of denying access to the site (you need to turn off OCSP checking to get
> around it).

That sounds like a bug...!

Gerv

Comment 21

[Kaspar]

Attachment: Do soft fail on OCSP status "unknown" responses

(In reply to Gervase Markham [:gerv] from comment #20)
> That sounds like a bug...!

I tend to agree, yes - at least when considering how the current OCSP options are labeled in the UI: "Use the Online Certificate Status Protocol (OCSP) to confirm the current validity of certificates" (for security.OCSP.enabled) and "When an OCSP server connection fails, treat the certificate as invalid" (security.OCSP.require).

The attached patch would fix that issue (i.e., responses with status unknown are then only treated as errors in hard failure mode). It's not what this bug was originally filed for, though.

Comment 22

[Gervase Markham [:gerv]]

(In reply to Kaspar Brand from comment #21)
> The attached patch would fix that issue (i.e., responses with status unknown
> are then only treated as errors in hard failure mode). It's not what this
> bug was originally filed for, though.

That's not the change I was expecting you to make! :-) I was expecting you to make it so that it wasn't a DOS attack. This bug is about making "unknown" to be treated like "fail", and it seems that the current code almost does this, but a little too aggressively. We should just dial it back a touch so the behaviour is actually the same in both cases. Unless I've missed something here.

CCing bsmith for his thoughts.

Gerv

Comment 23

[Kaspar]

(In reply to Gervase Markham [:gerv] from comment #22)
> This bug is about making
> "unknown" to be treated like "fail", and it seems that the current code
> almost does this, but a little too aggressively.

The current code implements a failure mode which isn't really one of the two choices currently available / documented in ocspt.h, yes:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certhigh/ocspt.h&rev=1.12&mark=260-281#260

/*
 * ocspMode_FailureIsVerificationFailure:
 * This is the classic behaviour of NSS.
 * Any OCSP failure is a verification failure (classic mode, default).
 * Without a good response, OCSP networking will be retried each time
 * it is required for verifying a cert.
 *
 * ocspMode_FailureIsNotAVerificationFailure:
 * If we fail to obtain a valid OCSP response, consider the
 * cert as good.
 * Failed OCSP attempts might get cached and not retried until
 * minimumSecondsToNextFetchAttempt.
 * If we are able to obtain a valid response, the cert
 * will be considered good, if either status is "good"
 * or the cert was not yet revoked at verification time.
 *
 * Additional failure modes might be added in the future.
 */

Contrary to what Ryan H. says in comment 13, I do not think that a (purportedly "authoritative") OCSP response with status "unknown" should lead to a hard failure already. As long as a current CRL is available from that particular issuer (and does not list the cert in question as revoked), it seems premature to me to conclude that a cert is "revoked" based on that OCSP response alone. Not even the latest publicly-available draft for the "Guidelines for the Processing of Extended Validation SSL Certificates" (https://cabforum.org/pipermail/public/2013-March/001277.html) has provisions which would mandate such a behavior.

With my patch applied, NSS will fall back to CRL-based checking in soft fail mode (i.e., at least in the libpkix case, it will fetch CRLs from the CRLDP URI, if the latter is included in the cert).

Comment 24

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I agree with Kaspar's comment 18 and I disagree with Kaspar's comment 23.

I am going to punt on how OCSP and CRLs should interact, and just focus on the case where we do OCSP only. I believe it should work like follows for NSS "classic" validation:

* If we've cached an "Unknown" response (regardless of whether it has expired), we should always try to fetch a better response, but we should default to returning SEC_ERROR_OCSP_UNKNOWN_CERT if the fetch fails, even in soft fail mode.

* If we've cached a "Revoked" response that hasn't expired, return it. If we've cached a "Revoked" response that has expired, re-fetch but assume SEC_ERROR_REVOKED_CERTIFICATE if the fetch fails, even in soft fail mode.

This way, we never DoS a site that has a newly-issued certificate where the OCSP responder has returned "Unknown" due to the OCSP responder not knowing about the cert as soon as the cert has expired.

An "Unknown" OCSP response that hasn't expired should never fall back to CRLs. The "Unknown" response is authoritative. CRLs can't deal with unknown certs in a reasonable way.

A cached "Unknown" OCSP response that is expired should also not fall back to CRLs. The cached OCSP response indicates that the CA supports OCSP. The fact that it is "Unknown" means there is a much-higher-than-normal likelihood that it is some kind of mis-issued/stolen/forged certificate, so we should be pessimistic about that.

Comment 25

[Kaspar]

(In reply to Brian Smith (:briansmith, was :[e-mail]; NEEDINFO me if you want a response) from comment #24)
> An "Unknown" OCSP response that hasn't expired should never fall back to
> CRLs. The "Unknown" response is authoritative.

RFC 2560 and RFC 6960 define "Unknown" as follows:

   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested.

and

   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested, usually because the request
   indicates an unrecognized issuer that is not served by this
   responder.

respectively. From the RFCs it also doesn't follow that an "Unknown" response is authoritative in the sense of "this certificate is known to not have been issued". Looking at the definition of "good", we find:

   The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued or that the time at which the response was produced
   is within the certificate's validity interval.

and

   The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that no certificate
   with the requested certificate serial number currently within its
   validity interval is revoked.  This state does not necessarily mean
   that the certificate was ever issued or that the time at which the
   response was produced is within the certificate's validity interval.

> CRLs can't deal with unknown certs in a reasonable way.

The same is true for a responder, unless you can determine that it issues responses according to the "Extended Revoked Definition" of RFC 6960. The respective response extension serves exactly this purpose, and "Unknown" can keep its original semantics in this case:

   NOTE: The "revoked" status indicates that a certificate with the
         requested serial number should be rejected, while the "unknown"
         status indicates that the status could not be determined by
         this responder, thereby allowing the client to decide whether
         it wants to try another source of status information (such as a
         CRL).  This makes the "revoked" response suitable for
         non-issued certificates (as defined above) where the intention
         of the responder is to cause the client to reject the
         certificate rather than trying another source of status
         information.

   [...]

   When a responder sends a "revoked" response to a status request for a
   non-issued certificate, the responder MUST include the extended
   revoked definition response extension (Section 4.4.8) in the
   response, indicating that the OCSP responder supports the extended
   definition of the "revoked" state to also cover non-issued
   certificates.

A proper fix for bug 933109 should include support for distinguishing these two types of OCSP responses (and not just unconditionally treat an "Unknown" OCSP response as the binding result for rejecting a cert).

Comment 26

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Kaspar Brand from comment #25)
> (In reply to Brian Smith (:briansmith, was :[e-mail]; NEEDINFO me
> if you want a response) from comment #24):
> > An "Unknown" OCSP response that hasn't expired should never fall back to
> > CRLs. The "Unknown" response is authoritative.

<snip>

> From the RFCs it also doesn't follow that an "Unknown"
> response is authoritative in the sense of "this certificate is known to not
> have been issued".

We can consider any signed OCSP response to be authoritative. If the CA doesn't want us to think that it doesn't know about the certificate, then it shouldn't return "Unknown" from its OCSP responder.

>    NOTE: The "revoked" status indicates that a certificate with the
>          requested serial number should be rejected, while the "unknown"
>          status indicates that the status could not be determined by
>          this responder, thereby allowing the client to decide whether
>          it wants to try another source of status information (such as a
>          CRL).

Note "allowing the client to decide whether it wants to try another source of status information." So, it is our choice to decline to try to try another source of status information.

> A proper fix for bug 933109 should include support for distinguishing these
> two types of OCSP responses (and not just unconditionally treat an "Unknown"
> OCSP response as the binding result for rejecting a cert).

Why? What real-world problem are you solving? The CABForum baseline requirements regarding this issue are definitely intended to allow us to consider "Unknown" to mean something like "mis-issued." It is possible that some CAs that aren't publicly-trusted CAs do things differently than the baseline requirements intend, but I think the solution to that is to have them become compatible with the semantics I laid out above. And, anyway, I think that before we consider any more complicated semantics than what I laid out above, we need to see a real-world scenerio where my suggested semantics fail.

Finally, whether to fall back to CRLs is a non-issue for products that do not support CRLs. I don't want to block the solution for products that do not support CRLs on making the solution perfect for products that do support CRLs. At most, we just need the solution to be not worse than the current situation.

Comment 27

[Kaspar]

(In reply to Brian Smith (:briansmith, was :[e-mail]; NEEDINFO me if you want a response) from comment #26)
> We can consider any signed OCSP response to be authoritative. If the CA
> doesn't want us to think that it doesn't know about the certificate, then it
> shouldn't return "Unknown" from its OCSP responder.

You can consider whatever OCSP response to be authoritative, and you can request all CAs to issue responses with the semantics you have in mind, of course. It's a little different from stating "The 'Unknown' response is authoritative", though, and also not really in line with the spirit of the IETF's standards-track specifications.

Note that an OCSP responder conforming to RFC 2560/6960 MUST issue a "definite response" when the following three conditions are met (section 2.1):

   1. the message is well formed,

   2. the responder is configured to provide the requested service, and

   3. the request contains the information needed by the responder.

If there is a temporary problem for the responder to determine a cert's status (think of an intermittent DB connectivity issue e.g.), then the best thing an RFC 2560/6960 compliant responder can do is to issue a "definite response" with status "Unknown".

> Why? What real-world problem are you solving? The CABForum baseline
> requirements regarding this issue are definitely intended to allow us to
> consider "Unknown" to mean something like "mis-issued."

Which is exactly where the problem lies. The BR just state (in section 13.2.6):

  Effective 1 August 2013, OCSP responders for CAs which are not
  Technically Constrained in line with Section 9.7 MUST NOT respond
  with a "good" status for such certificates.

and are therefore far from defining any useful semantics for responses with status "Unknown".

> It is possible that
> some CAs that aren't publicly-trusted CAs do things differently than the
> baseline requirements intend, but I think the solution to that is to have
> them become compatible with the semantics I laid out above. And, anyway, I
> think that before we consider any more complicated semantics than what I
> laid out above, we need to see a real-world scenerio where my suggested
> semantics fail.

The world is more than just publicly-trusted SSL certificates and Web browsers.

> Finally, whether to fall back to CRLs is a non-issue for products that do
> not support CRLs. I don't want to block the solution for products that do
> not support CRLs on making the solution perfect for products that do support
> CRLs. At most, we just need the solution to be not worse than the current
> situation.

This bug is filed under NSS, and bug 933109 is also talking about changes in the classic and the libpkix code (though it is filed unter Security:PSM). Unless adherence to the standards listed under

  https://developer.mozilla.org/en-US/docs/Overview_of_NSS

is no longer something NSS is aiming for, I don't believe that code based on an idiosyncratic interpretation of RFC 2560/6960 should go into this library.

Comment 28

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Kaspar Brand from comment #27)
> If there is a temporary problem for the responder to determine a cert's
> status (think of an intermittent DB connectivity issue e.g.), then the best
> thing an RFC 2560/6960 compliant responder can do is to issue a "definite
> response" with status "Unknown".

http://tools.ietf.org/html/rfc6960#section-2.3

  "In the event that the OCSP responder is operational but unable to
   return a status for the requested certificate, the "tryLater"
   response can be used to indicate that the service exists but is
   temporarily unable to respond."

> Unless adherence to the standards listed under
> 
>   https://developer.mozilla.org/en-US/docs/Overview_of_NSS
> 
> is no longer something NSS is aiming for, I don't believe that code based on
> an idiosyncratic interpretation of RFC 2560/6960 should go into this library.

Please read http://tools.ietf.org/html/rfc6960#section-2.3 and http://tools.ietf.org/html/rfc5019#section-2.2.3 (referenced by RFC6960 section 2.3). Also, please read http://tools.ietf.org/html/rfc6960#section-2.2, namely:

   NOTE: The "revoked" status indicates that a certificate with the
         requested serial number should be rejected, while the "unknown"
         status indicates that the status could not be determined by
         this responder, thereby allowing the client to decide whether
         it wants to try another source of status information (such as a
         CRL).  This makes the "revoked" response suitable for
         non-issued certificates (as defined above) where the intention
         of the responder is to cause the client to reject the
         certificate rather than trying another source of status
         information.  The "revoked" status is still optional for
         non-issued certificates in order to maintain backwards
         compatibility with deployments of RFC 2560.  For example, the
         responder may not have any knowledge about whether a requested
         serial number has been assigned to any issued certificate, or
         the responder may provide pre-produced responses in accordance
         with RFC 5019 and, for that reason, is not capable of providing
         a signed response for all non-issued certificate serial
         numbers.

Clearly, the client has a lot of discretion on how to react to an "Unknown" response. I think the choice you are proposing and the choice I am proposing are both reasonable and allowable given what the RFCs say.

Is there anything wrong with fixing the most immediate problem (too-agressive caching of "Unknown" responses) now, and defering the fallback logic you are requesting to a follow-up bug? NSS is already not doing the thing you are asking for. Even if you and I disagree on what the ultimate end-result behavior should be, isn't the logic I'm proposing at least better than the current state of NSS?

Comment 29

[Kaspar]

(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO me if you want a response) from comment #28)

I'm aware of those creative ways where error codes like unauthorized or trylater have been reinterpreted to signal things which were not foreseen in the original protocol design. But encouraging responders to fall back to unauthenticated responses (with no date/time and request information at all) is definitely not in the interest of a validating client. It is trivial to forge such replies, and the technique was already demonstrated in practice (Moxie's sslsniff, http://www.thoughtcrime.org/papers/ocsp-attack.pdf).

> Is there anything wrong with fixing the most immediate problem
> (too-agressive caching of "Unknown" responses) now, and defering the
> fallback logic you are requesting to a follow-up bug? NSS is already not
> doing the thing you are asking for. Even if you and I disagree on what the
> ultimate end-result behavior should be, isn't the logic I'm proposing at
> least better than the current state of NSS?

Fixing the caching problem with "Unknown" responses is definitely not wrong, no. Instead of reinterpreting them in a way which doesn't follow from RFCs 2560/6960, the proper way of addressing this issue is to take advantage of what RFC 6960 has brought us recently, though:

   o  Section 2.2 extends the use of the "revoked" response to allow
      this response status for certificates that have never been issued.

Deferring things to follow-up bugs has a good chance of ending up in another case where a fix is simply never going to happen (random examples: bug 203323, bug 416169, or - not so random, actually, bug 480683).