#4919 Encoded slash don't pass via Apache to the OCSP endpoint
Opened 5 years ago by z0rc. Modified 3 years ago

Here is sample request which wasn't proxied by Apache

"GET /ca/ocsp/MEcwRaADAgEAMD4wPDA6MAkGBSsOAwIaBQAEFC0BKz3hyGx%2FWkbnIaBCMbeTnRMmBBQKlDNY3D2MLh5un0bkUHoJgdKM2gIBGg%3D%3D HTTP/1.1" 404 306 "-" "ocspd/1.0.3"

Notice the %2F which corresponds '/' character, IIRC it's a valid symbol here.
Apache has an option to handle this (AllowEncodedSlashes On), but it might me a high security risk as it can be used by server or virtual host context only. And FreeIPA doesn't use any virtual hosts.

For confirmation, RFC 6960 mandates that requests be made this way for some odd reason. See Appendix A1:

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}

We don't have particularly refined access control in IPA (it is done at a high level) which is where this sort of PATH_INFO trickery tends to come into play.

Unfortunately I can reproduce the failure but I'm not seeing this fixed by the AllowEncodedSlashes option. I still get a 404 from Apache. I'm testing using the NSS tool ocspclnt:

# /usr/lib64/nss/unsupported-tools/ocspclnt -d /etc/httpd/alias -V Server-Cert -u s - - [24/Feb/2015:10:55:26 -0500] "GET /ca/ocsp/MGIwYDA%2BMDwwOjAJBgUrDgMCGgUABBRdjrG8DnKToXKmfH4t4ppp2SF9KAQUJl8%2BmGlWY2MgK4%2FxwRBZCO2H%2FlkCAQmiHjAcMBoGCSsGAQUFBzABBAQNMAsGCSsGAQUFBzABAQ%3D%3D HTTP/1.0" 404 342 "-" "-" - - [24/Feb/2015:10:55:26 -0500] "POST /ca/ocsp HTTP/1.0" 200 2268 "-" "-"

Where did you place the directive?

From what I can tell dogtag isn't handling GET OCSP requests very well either, at least not dogtag 10. So even if we got Apache forwarding the requests we'd still be in the same place.

Endi filed a dogtag ticket to look into OCSP GET request handling, https://fedorahosted.org/pki/ticket/1295

Indeed I spoke too soon, there is more fundamental issue with GET not being served. Will verify this issue after the pointed dogtag ticket is resolved.

POST works if that is a configuration option for your OCSP client. It is a preferred route in general, if possible.

4.1.4 was released, moving to new milestone

FreeIPA 4.2.1 was released, moving to 4.2.x.

Besides https://fedorahosted.org/pki/ticket/1295 there is https://fedorahosted.org/pki/ticket/1658 as well. Both are now fixed in dogtag 10.3 and above.

If I now add 'AllowEncodedSlashes On' to /etc/httpd/conf/httpd.conf the url-encoded strings are properly forwarded by Apache to dogtag and the expected result is return.

Since I'm not familiar with all the other request handled by Apache I'm not sure if setting 'AllowEncodedSlashes On' on this level of the configuration has any unwanted side-effects and if there is a better place to set this option.

Btw, although all Linux/UNIX tools seem to use the POST variant of the OCSP request the GET version is important as well, because it is used by Windows (at least for small requests) exclusively.

Metadata Update from @z0rc:
- Issue assigned to edewata
- Issue set to the milestone: FreeIPA 4.5 backlog

3 years ago

Login to comment on this ticket.