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+GwAQUkssAaDtwlx2UmxiR
voReHJS6sagCAwP%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
--
You received this message because you are subscribed to the Google Groups
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186D506DBC99EC60CA5D62A92B19%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
