Dear all, A couple of days ago we had an issue with the OCSP Responder and an OpenSSL user, where the OCSP Request was being sent over HTTP but transversing a Squid cache. The problem was a combination of an OpenSSL's "known issue" (use the "host+path" parameters instead of the "url" parameter when performing an OCSP Request) with the Squid ability to cache certain types of HTTP requests (in this case HTTP/1.0). Even though RFC2560 mentions the following: "The reliance of HTTP caching in some deployment scenarios may result in unexpected results if intermediate servers are incorrectly configured or are known to possess cache management faults. Implementors are advised to take the reliability of HTTP cache mechanisms into account when deploying OCSP over HTTP." Maybe we should add to the "OCSP Requirements for Grids" document this note, so potential deployments disable OCSP over HTTP caching in intermediate servers. What do you think about it? More info about the OpenSSL issue mentioned above can be found in the openssl-users mailinglist under the folloing link: http://marc.theaimsgroup.com/?l=openssl-users&m=111091034704961&w=2 Best regards, Jesus & Oscar
Is the recommendation one to the authors of OCSP client-side software or to proxy administrators? It seems natural to take advantage of http proxies -- especially in those unfortunate circumstances where you have no other choice! Unless it's hopeless, but I don't see that from the example cited or from the RFC, but I definitely don't understand all the potential problems.
Mensaje citado por Mike Helm <helm@fionn.es.net>:
Is the recommendation one to the authors of OCSP client-side software or to proxy administrators?
I think that this should be addressed to OCSP architects in charge of deploying/planning the Grid-OCSP Responders ("please disable OCSP-service caching at HTTP-caches"). However this recommendation also could be useful for developers trying to figure out potential problems with their clients (the HTTP cache responding instead of the OCSP Responder).
It seems natural to take advantage of http proxies -- especially in those unfortunate circumstances where you have no other choice! Unless it's hopeless, but I don't see that from the example cited or from the RFC, but I definitely don't understand all the potential problems.
HTTP Proxying is useful, but the problem may arise from HTTP-caches were a misconfigured server may begin responding OCSP Requests instead of sending them to the OCSP Responder. I think that this is likely to happen when OCP Requests are being send over HTTP/1.0 (i.e. OpenSSL clients?). Regards, Jesus
On Apr 24, 2006, at 2:39, jluna@ac.upc.edu wrote:
HTTP Proxying is useful, but the problem may arise from HTTP-caches were a misconfigured server may begin responding OCSP Requests instead of sending them to the OCSP Responder. I think that this is likely to happen when OCP Requests are being send over HTTP/1.0 (i.e. OpenSSL clients?).
It would be very important to know what caching control is being sent by the OCSP Responder when the cache first sends the request to it.
Exactly, in fact IETF Draft's "Lightweight OCSP Profile for High Volume Environments" in section "5.2 HTTP Proxies" has an interesting text about this issue -something which may have been useful to specify also in RFC2560-. Do you think that it may be worth mentioning it into the OCSP reqs document or let's just skip it? Regards, Oscar & Jesus Mensaje citado por Matt Crawford <crawdad@fnal.gov>:
On Apr 24, 2006, at 2:39, jluna@ac.upc.edu wrote:
HTTP Proxying is useful, but the problem may arise from HTTP-caches were a misconfigured server may begin responding OCSP Requests instead of sending them to the OCSP Responder. I think that this is likely to happen when OCP Requests are being send over HTTP/1.0 (i.e. OpenSSL clients?).
It would be very important to know what caching control is being sent by the OCSP Responder when the cache first sends the request to it.
I don't see anyone objecting to this being an issue that is worth adding a note about in the doc. /O On Apr 26, 2006, at 09:19, jluna@ac.upc.edu wrote:
Exactly, in fact IETF Draft's "Lightweight OCSP Profile for High Volume Environments" in section "5.2 HTTP Proxies" has an interesting text about this issue -something which may have been useful to specify also in RFC2560-. Do you think that it may be worth mentioning it into the OCSP reqs document or let's just skip it?
Regards, Oscar & Jesus
Mensaje citado por Matt Crawford <crawdad@fnal.gov>:
On Apr 24, 2006, at 2:39, jluna@ac.upc.edu wrote:
HTTP Proxying is useful, but the problem may arise from HTTP-caches were a misconfigured server may begin responding OCSP Requests instead of sending them to the OCSP Responder. I think that this is likely to happen when OCP Requests are being send over HTTP/1.0 (i.e. OpenSSL clients?).
It would be very important to know what caching control is being sent by the OCSP Responder when the cache first sends the request to it.
HTTP Proxying is useful, but the problem may arise from HTTP- caches [...] It would be very important to know what caching control is being sent by the OCSP Responder when the cache first sends the request to it. Exactly, in fact IETF Draft's "Lightweight OCSP Profile for High Volume Environments" in section "5.2 HTTP Proxies" has an interesting text about this issue [...] Do you think that it may be worth mentioning it into the OCSP reqs document or let's just skip it? I don't see anyone objecting to this being an issue that is worth adding a note about in the doc.
I had not looked at the i-d Jesus referred to (draft-ietf-pkix- lightweight-ocsp-profile-04.txt), but its treatment of the issue looks complete and accurate.
participants (4)
-
jluna＠ac.upc.edu -
Matt Crawford -
Mike Helm -
Olle Mulmo