New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 5 users

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2017
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Issue 727255: Invalid OCSP stapled responses don't cause a spec-mandated connection abort

Reported by, May 29 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.9) Gecko/20100101 Goanna/3.2 Firefox/45.9 PaleMoon/27.3.0

Steps to reproduce the problem:
1. Go to a site which uses an invalid stapled OCSP response (e.g. wrong signing certificate)

What is the expected behavior?
The connection should have been aborted

What went wrong?
Connection was made without any warnings or errors

Did this work before? N/A 

Chrome version: All  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

This was reported due to recent issues with microsoft services using invalid signing certificates, and all Chromium browsers still being able to connect (while NSS-based software correctly aborts).

See also RFC 6066 section 8:
"Clients requesting an OCSP response and receiving an OCSP response in a "CertificateStatus" message MUST check the OCSP response and abort the handshake if the response is not satisfactory"

Comment 1 by, May 29 2017

Components: Internals>Network>SSL
Labels: -Restrict-View-SecurityTeam
Status: Untriaged (was: Unconfirmed)
This has been publicly discussed, so dropping view restrictions.

Given our stance on OCSP, I think this is likely Working-as-Intended

Comment 2 by, May 29 2017

I'm not sure what your "stance" is then. You support stapled responses but just ignore any errors in it, making cert status/revocation checks pointless? I can hardly imagine that that is working as-intended.

Comment 3 by, May 29 2017

cc'ing rsleevi@ for comment.

Comment 5 by, May 29 2017

Labels: allpublic

Comment 6 by, May 29 2017

Well, I'd say this is exactly what your FAQ is proposing: using stapled OCSP responses in favor of OCSP lookups -- but your implementation doesn't fail the connection when there's an error in the stapled OCSP response, contradicting the "better solution". And considering Microsoft's server issue isn't/wasn't just a timing issue (expired or what not) but actually an incorrect signing certificate (that is, signed by the wrong party -- meaning it could just as well have been an invalid certificate), accepting such a response is pretty bad.

CRLSet can't hope to cover all certificates out there, either, so having a proper implementation of a revocation check mechanism that IS working and IS adopted widely by now, is important.

once again: I'm just talking about stapled responses here, not individual lookups which are, indeed, suffering from a few issues (connectivity/privacy).

Comment 7 by, May 30 2017

Status: WontFix (was: Untriaged)
"If the response is not satisfactory" is application-defined. In this case, Microsoft clients will determine that an invalid response is satisfactory (it can be ignored) in favor of fetching a fresh OCSP response directly.

Without getting into spec lawyering - which is to say, a spec is only as useful as the real world implementations (hence "rough consensus _and_ running code" as the IETF mantra) - it's a known behaviour that a stapled OCSP response does not result in a fatal connection error.

OCSP stapling is used for several non-critical functions, with the overall reasoning being what elawrence@ has highlighted in the Security FAQ.

- As a delivery mechanism for SCTs (RFC 6962)
  - The signature of the OCSP response is ignored - since the SCTs are themselves signed - and since SCTs are part of a feature enhancement (Certificate Transparency) that gracefully degrades in their absence, the lack of a valid signature does not in and of itself signal an error
- As an optimization method for the OCSP information
  - When possible, we take the stapled response and hand it to the appropriate cryptographic library. The underlying OS libraries consistently take OCSP stapled information as a 'cache priming' optimization, but in the presence of an invalid response, will simply choose to not persist the item and go to the network to fetch it.
  - Since we do not treat OCSP failures as hard failures, the failure to fetch a valid response via the network is not a failure
  - Since we do not treat the failure to fetch from the network as a failure, it leads to inconsistent behaviour to treat an invalid response as a failure. Again, the FAQ covers this.

The Chrome Team remains committed to improving the status of OCSP (and OCSP stapling), and looks forward to holisticly improving the ecosystem. Within the CA/Browser Forum, the Chrome team continues to work towards a reasonable security profile that makes OCSP viable for stapling. Within Chrome itself, we continue to empirically gather data about real-world deployment challenges, to ensure that our user experience is both consistent with the goals and appropriate for securing users. In the server space, we continue to invest in providing guidance and, when possible, implementation for server operators on how to best and meaningfully deploy OCSP stapling (e.g. )

At this time, OCSP stapling has enough issues that we have no plans to adopt Firefox-like behaviours. We remain committed to attempting to holistically find solutions and to share our research (such as at )

Comment 8 by, May 30 2017

So connect at all costs.. Good to know. You do realize that while Google may see them selves as defining actual behavior over standards when they can't actually define the standards them selves.. That doesn't make it wise to sacrifice user security for the sake of market perception.

You don't own the internet.. Yet. So please reconsider your decision to ignore important security issues.

Comment 9 by, May 30 2017

SCT isn't applicable here, so please don't pull that in.

Also, you may treat an Ocsp connection failure as non fatal, but a stapled response should be considered equal to a received ocsp response and should not be ignored if it is invalid. As for the fatality of the error, rfc 6066 is absolutely clear that it MUST be considered an error that is always fatal. See the relevant section I quoted part of.

What does chromium do in this case? Are erroneous stapled responses considered equal to valid ones? i.e. considered as ok? or are they considered as "not received" ? Both would imply a security risk.

You should reconsider your stance if you are truly supporting your own "holistic improvement" statement!

Comment 10 by, May 30 2017

Labels: Restrict-AddIssueComment-EditIssue
SCTs are applicable, as delivering them via OCSP is specified as part of RFC 6962.

Regarding RFC 6066, as noted, while my intent is not to get into a 'spec-lawyering' discussion (which is both unproductive and misunderstands the role in which the IETF specifications play), I will simply note that "the response is not satisfactory" is application-defined behaviour.

Thank you for your feedback and suggestions. As noted, we have already thought through the implications and behaviours of this, with respect to ensuring a consistent security story with defensible and appropriate security boundaries, as explained in

At this time, there are no plans to hard-fail for OCSP, for the many technical reasons outlined. These technical issues are further compounded by the many procedural issues regarding revocation, such that CA-directed revocation does not currently meet an appropriate bar for blocking access to a site, due to inconsistent revocation policies and incomplete disclosures regarding the reasons for revocation.

We remain committed to continuing to encourage the ecosystem further in the appropriate fora, such as the CA/Browser Forum, and sharing our research and concerns related to this.

I'm restricting further comments to this issue, as we have no plans to revisit the current behaviour independent of those steps.

Sign in to add a comment