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 [email protected] schrieb am Donnerstag, 7. Oktober 2021 um 20:39:08 UTC+2: > 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 > > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ff7128c6-fce3-4911-91bb-604c202414f5n%40mozilla.org.
