OCSP responder behavior for HTTP GET requests

[Corey Bonnell]

Hello,

During a recent analysis of OCSP responder behavior in the Web PKI, an interesting behavior of some OCSP responders was observed that I’d like to share so that any CAs potentially with this issue can investigate and remediate.

 

Section 4.9.10 of the BRs [1] specifies that “OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019”. Section A.1 of RFC 6960 [2] specifies how the URI for HTTP GET OCSP is formed, which I’ll copy/paste here:

An OCSP request using the GET method is constructed as follows:

 

   GET {url}/{url-encoding of base-64 encoding of the DER encoding of

   the OCSPRequest}

 

While unfortunate that there is no explicit normative reference that specifies how exactly the base64 encoding is to be performed, the mention of “url-encoding” indicates that base64url encoding is not used (this interpretation would also be ahistorical, as base64url was defined in RFC 4648 [3], and the original OCSP RFC 2560, which predates RFC 4648, has the same language as above [4]). This is significant, as base64 may contain non-alphanumeric characters, particularly the forward-slash (“/”), which has specific semantics when it appears in the path component of a URI. Additionally, several web server implementations coalesce sequences of multiple forward-slashes into a single forward-slash, which will corrupt base64-encoded OCSP requests.

 

It appears that several CAs’ OCSP responders do not gracefully handle OCSP GET requests whose URL-encoding of the base64-encoded OCSP request contains a sequence of at least two forward slashes, even when those forward-slashes are percent/URL-encoded as per RFC 3986 [5].

 

Here is a sample OCSP request with a sequence of two percent-encoded forward slashes. Correctly configured OCSP responders will return “unauthorized” for this request whereas “malformedRequest” responses or similar errors are indicative of a configuration error that may be blocking legitimate requests from standards-compliant OCSP clients:

MEwwSjBEMEIwPDAJBgUrDgMCGgUABBQZi38wFNaJswehTpPKVshbSQ+GwAQUkssAaDtwlx2UmxiRvoReHJS6sagCAwP%2F%2FKACMACiAjAA

 

Given that OCSP clients may include arbitrary values for nonces, OCSP responders must gracefully handle this condition.

 

I encourage CAs to test their OCSP responders to ensure that they properly handle such sequences of forward-slashes to ensure that they are meeting the obligations of BR section 4.9.10.

 

Thanks,

Corey

 

[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf

[2] https://datatracker.ietf.org/doc/html/rfc6960#appendix-A.1

[3] https://datatracker.ietf.org/doc/html/rfc4648#section-5

[4] https://datatracker.ietf.org/doc/html/rfc2560#appendix-A.1.1

[5] https://datatracker.ietf.org/doc/html/rfc3986#section-3.3

 

[Jacob Hoffman-Andrews]

Good advice, thanks for sharing! People interested in this may also be interested in reading Let's Encrypt's 2017 postmortem related to the same issue: https://community.letsencrypt.org/t/may-19-2017-ocsp-and-issuance-outage-postmortem/34922. Another interesting thing: concatenation happens without regard to whether the OCSP URL in a certificate has a trailing slash. If you issue certificates where the OCSP URL ends in a trailing slash (rare, I think), you'll find that all of your OCSP GET requests start with a doubled slash (//). Also, it's worth being cautious about deploying changes that will cause large numbers of cache entries to be invalidated.

[Peter Gutmann]

'Corey Bonnell' via dev-secur...@mozilla.org writes:

>Section 4.9.10 of the BRs [1] specifies that “OCSP responders operated by the
>CA SHALL support the HTTP GET method

Regardless of the URL-encoding issues, isn't this wrong in any case since GET
is idempotent but OCSP isn't?  So the solution isn't to try and patch up the
use of the wrong HTTP mechanism but to require the use of non-idempotent POST
to match the non-idempotent OCSP, and then the URL-encoding issue resolves
itself.

Peter.

[Ben Wilson]

Could this possibly be the same as the problem I'm encountering with OCSP response for the SERPRO test site (OCSP response not found) when I run this command?

curl --verbose --url http://ocsp.serpro.gov.br/acserprosslv1/ME4wTDBKMEgwRjAJBgUrDgMCGgUABBTBQ28pKtiXfAbGW%2BhUsNmqSdcYRQQUrRZPS%2FEMvsKKooUY1w1GJZMi480CDQDzmwGvO97JMnso57k%3D

(Using instructions from https://unmitigatedrisk.com/?p=42)

See also https://certificate.revocationcheck.com/active-repositorio.serpro.gov.br

Thanks,

Ben

On Thu, Oct 7, 2021 at 6:42 PM 'Jacob Hoffman-Andrews' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

Good advice, thanks for sharing! People interested in this may also be interested in reading Let's Encrypt's 2017 postmortem related to the same issue: https://community.letsencrypt.org/t/may-19-2017-ocsp-and-issuance-outage-postmortem/34922. Another interesting thing: concatenation happens without regard to whether the OCSP URL in a certificate has a trailing slash. If you issue certificates where the OCSP URL ends in a trailing slash (rare, I think), you'll find that all of your OCSP GET requests start with a doubled slash (//). Also, it's worth being cautious about deploying changes that will cause large numbers of cache entries to be invalidated.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAN3x4QmJ4_ZEOOq%3DPgLv45NLD1afcqWeKd0M8PR%2B%3D%3DdShh%2BbZA%40mail.gmail.com.

[Corey Bonnell]

Hi Peter,
My understanding is that although HTTP GET requests are expected to be idempotent (i.e., the state of the world should not change as a side effect of the GET request), there is no expectation that content itself of the specified resource must be static. RFC 5019 leverages GET requests to improve cacheability [1]. Given the performance benefits of implementing RFC 5019, this is likely why the BRs mandate that CAs must support HTTP GET for their responders.

Thanks,
Corey

[1] https://datatracker.ietf.org/doc/html/rfc5019#section-5

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SY4PR01MB625181E9F6A7D472CF3390ECEEB29%40SY4PR01MB6251.ausprd01.prod.outlook.com.

[Corey Bonnell]

Hi Ben,

I think the SERPRO OCSP responder has two issues at play:

1. When I send a GET request containing a valid OCSP request whose base64-encoding consists solely of alphanumeric characters (“http://ocsp.serpro.gov.br/acserprosslv1/MEwwSjBEMEIwPDAJBgUrDgMCGgUABBRCALQ8KegpMz1OADFGgCAaOp1VVAQUQgC0PCnoKTM9TgAxRoAgGjqdVVQCAwCAAqACMACiAjAA”), I get a HTTP 500 with the response body containing an “internalError” OCSP response. Given the different status code (500 vs. 404) for different GET requests, the server possibly isn’t handling the percent-encoded slash in your request correctly.
2. Even when a request is sent in a manner that doesn’t return an HTTP 404 (using HTTP POST or GET with all alphanumeric characters), the server still returns an HTTP 500 and “internalError” OCSP response.

 

Thanks,

Corey

 

From: Ben Wilson <bwi...@mozilla.com>
Sent: Friday, October 8, 2021 5:38 PM
To: Jacob Hoffman-Andrews <js...@letsencrypt.org>
Cc: Corey Bonnell <Corey....@digicert.com>; dev-secur...@mozilla.org
Subject: Re: OCSP responder behavior for HTTP GET requests

 

Could this possibly be the same as the problem I'm encountering with OCSP response for the SERPRO test site (OCSP response not found) when I run this command?

[Paul van Brouwershaven]

Looks like that server has another problem, the URL doesn't have any double slashes, fails also when not encoded, and a request using POST seems to fail as well.

Encoded:

http://ocsp.serpro.gov.br/acserprosslv1/ME4wTDBKMEgwRjAJBgUrDgMCGgUABBTBQ28pKtiXfAbGW%2BhUsNmqSdcYRQQUrRZPS%2FEMvsKKooUY1w1GJZMi480CDQDzmwGvO97JMnso57k%3D

Decoded:

http://ocsp.serpro.gov.br/acserprosslv1/ME4wTDBKMEgwRjAJBgUrDgMCGgUABBTBQ28pKtiXfAbGW+hUsNmqSdcYRQQUrRZPS/EMvsKKooUY1w1GJZMi480CDQDzmwGvO97JMnso57k=

Taking the base 64 request data from the URL above, and decoding the ASN.1, we can successfully get the OCSP request:

https://lapo.it/asn1js/#ME4wTDBKMEgwRjAJBgUrDgMCGgUABBTBQ28pKtiXfAbGW-hUsNmqSdcYRQQUrRZPS_EMvsKKooUY1w1GJZMi480CDQDzmwGvO97JMnso57k

[Rufus Buschart]

Thank you, Corey, for sharing this interesting finding with the community.

 

to those who might be concerned: if you are running your PKI on Nexus CM / Smart ID your OCSP responder is affected by this problem. The vendor has acknowledged the problem and is working on a fix.

/Rufus

[Peter Gutmann]

Corey Bonnell writes:

>RFC 5019 leverages GET requests to improve cacheability [1]. Given the
>performance benefits of implementing RFC 5019, this is likely why the BRs
>mandate that CAs must support HTTP GET for their responders.

Ah, right, and since 5019 removes the replay-protection nonces it would make
the whole thing cacheable while non-5019 OCSP with nonces wouldn't be. The
reason I brought it up is that SCEP has run into problems with GET, see the
note at https://datatracker.ietf.org/doc/html/rfc8894.html#section-4.1, which
are typically very hard to diagnose because of the conditions under which they
occur.

Peter.

[Rufus Buschart]

Do we believe that an affected CA should open a bug report? The situation is an edge case: as long as the OCSP responder didn't receive a requested for such a specific URL, it didn't fail and the CA is compliant to the BRs but as soon as it received such a request once, the CA is not compliant anymore. How do you feel?

/Rufus

[Rufus Buschart]

We had discussions about the '+'-character in the string created by Digicert to assess whether an OCSP responder is behaving according to the RFCs / BRs or not. The earliest reference about URL encoding we found is RFC1738, chapter 2.2 which states:

    Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
    reserved characters used for their reserved purposes may be used
    unencoded within a URL.

Also, there is plenty of discussion on StackOverflow about this issue, and it seems, that the + sign as part of the URL needs to be decoded into a + sign and not into a ‘white space’ as long as it is not part of a form POST submission request body or in the ?query part of the URL (https://stackoverflow.com/a/2700981/1426535).

But there is a reference in RFC6960 to RFC3986, the update to RFC1738. And RFC 3986 section 2.2 states the following for reserved characters: 

    URI producing applications should percent-encode data octets that
    correspond to characters in the reserved set unless these characters
    are specifically allowed by the URI scheme to represent data in that
    component.

With this section applied to the OCSP GET request context, the requesting OCSP client is the 'URI producing application' and should perform percent-encoding of all characters in the reserved set. This would mean, that the '+'-character in the test string is invalid and should be URL encoded.

How does the Mozilla Community feel about this?

/Rufus

[Peter Gutmann]

Rufus Buschart <rufus.b...@siemens.com> writes:

>With this section applied to the OCSP GET request context

^^^
Ah, I see yer problem right there...

(Just use POST and the problem goes away, yet another reason why GET is the
wrong thing to do for PKI applications).

Peter.

[Rufus Buschart]

Hi Peter!

Thank you for your feedback. I'd love to get away from GET requests, but as long as they are specified, we need to support them according to the RFCs. And I've been in discussions with the vendor of one OCSP responder, which has a problem with exactly this '+'-sign and the vendor insists on being compliant with the RFCs as he believes there must be no '+'-sign in the request.

[Corey Bonnell]

Hi Rufus,

Section 3.3 of RFC 3986 [1] defines the following ABNF production rule for a path character (“pchar”):

 

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

 

The production rule for “sub-delims” is defined in section 2.2 as follows:

 

sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"

                  / "*" / "+" / "," / ";" / "="

 

Given this grammar, standards-compliant clients do not need to percent-encode the “+” and “=” characters, so OCSP responders must accept these characters as-is. However, “/” is noticeably absent from the pchar production rule (which makes sense, as it’s used as the path segment delimiter), so it must be percent-encoded.

 

Thanks,

Corey

 

[1] https://datatracker.ietf.org/doc/html/rfc3986#section-3.3

 

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Rufus Buschart
Sent: Monday, January 3, 2022 10:22 AM
To: dev-secur...@mozilla.org
Cc: Rufus Buschart <rufus.b...@siemens.com>
Subject: Re: OCSP responder behavior for HTTP GET requests

 

We had discussions about the '+'-character in the string created by Digicert to assess whether an OCSP responder is behaving according to the RFCs / BRs or not. The earliest reference about URL encoding we found is RFC1738, chapter 2.2 which states:

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c9ecd316-6029-40cc-8677-1d9c9676791fn%40mozilla.org.