OCSP Responder Performance Needs Improvement

Recently I set up a PingDom monitor to track the overall performance of the various OCSP responders out there, PingDom is limited to doing GETs and cannot parse the responses from the responders but it’s a fair mechanism to look at response time.

These tests run from a number of different global locations and are averaged together, the locations change but the same locations are used for each set of tests so again this seems fair.

I decided to use the Google logo as my control test, as it is about the same size as a larger OCSP response, after about a month of monitoring this is what I saw:

Test Avg. Response time
Google Logo (3972 bytes)

44 ms

GoDaddy OCSP

186 ms

GlobalSign OCSP

228 ms

Digicert OCSP

266 ms

Comodo OCSP

268 ms

TrustCenter OCSP

273 ms

TrustWave OCSP

315 ms

Startcom OCSP

364 ms

Entrust OCSP

371 ms

Geotrust OCSP

432 ms

VeriSign OCSP

510 ms

CyberTrust OCSP

604 ms

Certum OCSP

776 ms

As you can see the fastest responder is over four times slower than the Google logo, far from acceptable.

When looking at the individual responses and their responses this is what I saw:

  • Very few responders are using CDNs, AnyCast or other techniques to globally distribute responses.
  • Only a handful of responders have multiple DNS entries for failover scenarios.
  • Quite a few responders are not following the HTTP caching header requirements in RFC 5019.
  • Most responders are not sending CA signed responses which reduce the response size significantly (down to 471 bytes), in my opinion a OCSP responder should do this for all pre-produced responses.
  • Some responders are returning Unknown for out of scope responses, this really isn’t safe for unauthenticated requests as it exposes the responder to resource consumption denial of service for against the signing keys.
  • Response freshness ranges from 6 hours to 14 days, I am quite sure the six hour responses are failing for a very large % of the internet community due to time skew; 4 days appear to be optimum.

These are all fairly easy things to address and I believe it’s reasonable for responders to get down to response times that are consistent with the control test above.

2 thoughts on “OCSP Responder Performance Needs Improvement

    1. rmhrisk Post author

      I determined what the GET URIs for each of the CAs OCSP status would be and configured them as HTTP tests; no need for a script. OCSP says that you should get a non-successes should be something other than HTTP 200 so this works.

      I no longer use PingDom and instead use Monitis though I am considering switching to thousandeyes.com.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *