Tag Archives: OCSP

Testing OCSP Stapling

9 Replies

So you have configured OCSP stapling and you want know if it’s actually working, it’s easy enough to check using the openssl  s_client command:

openssl s_client -connect login.live.com:443 -tls1  -tlsextdebug  -status

Loading ‘screen’ into random state – done

CONNECTED(0000017C)

TLS server extension “status request” (id=5), len=0

….

OCSP response:

======================================

OCSP Response Data:

OCSP Response Status: successful (0x0)

…

Cert Status: good

This Update: Jun 12 02:58:39 2012 GMT

Next Update: Jun 19 02:58:39 2012 GMT

…

In this example you see that the client is requesting the servers OCSP response, you then see the server providing that response successfully and openssl determining the servers certificate is good.

For another example we can query the US Mint’s website for an example of a site that has not yet (and probably won’t for some time since it’s a government site) configured OCSP stapling:

openssl s_client -connect www.usmint.gov:443 -tls1  -tlsextdebug  -status

Loading ‘screen’ into random state – done

CONNECTED(0000017C)

OCSP response: no response sent

….

Hope this helps you deploy OCSP Stapling successfully.

Ryan

OCSP Stapling in IIS

3 Replies

Windows Server 2008 and later support a feature called OCSP stapling. When enabled a server pre-fetches the OCSP response for its own certificate and delivers it to the user’s browser during the TLS handshake. This approach offers a privacy advantage. But, the main benefit is the browser doesn’t have to make a separate connection to the CA’s revocation service before it can display the Web page. This gives better performance and reliability.

For this pre-fetching to work the web-server certificate needs to contain a pointer to the OCSP responder, this is a best practice and a recommendation of the CA/Browser Forums baseline requirements so it’s almost certain your certificate has it.

Unlike Apache this feature is enabled by default, it’s possible your servers are already doing OCSP stapling and you do not even know it.

With that said chances are you have a firewall between your webservers and the internet; it’s also likely that firewall disallows outbound connections from your servers unless explicitly allowed. So you might need to allow your web servers to communicate with the OCSP responder before it will work.

To figure out what host and port you will need to open you will need to look at the certificates you use on your webserver; one way to do that is to browse to your current site and view the details of the certificates you are currently using, for example:
   

The value you want is in the “Authority Information Access” field, you want the ones (there may be multiple) that have the “Access Method” of “On-line Certificate Status Protocol”.

Once these two conditions are met OCSP Stapling will “Just work” there is nothing else you need to do.

Ryan

OCSP Stapling in Apache

4 Replies

Apache 2.3 and later support a feature called OCSP stapling. When enabled a server pre-fetches the OCSP response for its own certificate and delivers it to the user’s browser during the TLS handshake. This approach offers a privacy advantage. But, the main benefit is the browser doesn’t have to make a separate connection to the CA’s revocation service before it can display the Web page. This gives better performance and reliability.

For this pre-fetching to work the web-server certificate needs to contain a pointer to the OCSP responder, this is a best practice and a recommendation of the CA/Browser Forums baseline requirements so it’s almost certain your certificate has it.

Chances are you have a firewall between your webservers and the internet; it’s also likely that firewall disallows outbound connections from your servers unless explicitly allowed. So before you enable OCSP stapling you are going to need to allow your web servers to communicate with the OCSP responder.

To figure out what host and port you will need to open you will need to look at the certificates you use on your webserver; one way to do that is via OpenSSL, for example:

1. Get the certificate using s_client

openssl.exe s_client -connect www.globalsign.com:443
…
…
—–BEGIN CERTIFICATE—–
—–END CERTIFICATE—–
…
…

You need to copy the PEM header and footer (“—–BEGIN/END CERTIFICATE—–“) and the Base64 between them into a file.

2. Identify the OCSP responders within the server certificate

openssl.exe x509 -in globalsign.com.cer -text
…
…
X509v3 extensions:
..
Authority Information Access:
CA Issuers – URI:
http://secure.globalsign.com/cacert/gsextendvalg2.crt
OCSP – URI:
http://ocsp2.globalsign.com/gsextendvalg2
…
…

You need to find the “OCSP – URI” section, in the example certificate above the OCSP responder is http://ocsp2.globalsign.com/gsextendvalg2 there may be multiple responders specified, you should allow your servers to initiate outbound traffic to all of them.

Once your servers can request OCSP responses enabling stapling is very straight forward, there are just two directives that need to be added, these directives can be global or specific to a specific to one instance:

SSLUseStapling on
SSLStaplingCache “shmcb:logs/stapling_cache(128000)”

Their purpose is self-evident; SSLUseStapling turns the feature on while SSLStaplingCache specifies where to store the cache and how big it should be.

There are other directives also you can use but you should not need to worry about them.

As long as you are running the most recent stable versions of Apache and OpenSSL enabling this feature is safe. It is only used when the client supports it so there won’t be compatibility issues and if the server for some reason fails to populate its cache with a valid OCSP response the client will typically fall back to doing a live OCSP request on its own.

Ryan

 

Additional Resources

Overclocking Mod_SSL

Browser Revocation Behavior Needs Improvement

6 Replies

Today the best behaving client for revocation behavior is that of Windows, in the case of browsers that means IE and Chrome.

With that said it has a very fundamental problem, if it reaches a CA’s OCSP responder and it provides an authoritative “that’s not mine” (aka Unknown) clients built on this platform treat the certificate as good.

You got that right; it treats a certificate that is clearly invalid as good! This unfortunately is a common behavior that all the browsers implement today.

The other browsers are even worse, Firefox for example:

  1. Do not  maintain a cache across sessions – This is akin of your browser downloading the same image every time you opened a new browser session instead of relying on a cached copy.
  2. Does OCSP requests over POST vs. GET – This prevents OCSP responders from practically utilizing CDN technology or cost-effectively doing geographic distribution of responders
  3. Do not support OCSP stapling – IE has supported this since 2008, Firefox even paid OpenSSL to add support around the same time but they have yet to get support in themselves.

These each seem like fairly small items but when you look at all these issues as a whole they significantly contribute the reality we face today – Revocation Checking isn’t working.

There are other problems as well, for example:

In some cases browsers do support GET as a means to do a OCSP request but if they receive a “stale” or “expired” response from an intermediary cache (such as a corporate proxy server) they do not retry the request bypassing the proxy.

All browsers today do synchronous revocation checking, imagine if your browser only downloaded one image at a time in series; that’s in-essence what the browsers are doing today.

These and other client behaviors contribute to reliability and performance problems that are preventing Hard Revocation Checking from being deployed. These issues need to be addressed and the browser vendors need to start publishing metrics on what the failure rates are as well as under what conditions they fail so that any remaining issues on the responder side can be resolved.

 

OCSP Responder Performance Needs Improvement

2 Replies

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.

How to do OCSP requests using OpenSSL and CURL

10 Replies

 

It pretty easy, the OpenSSL and CURL manuals make it fairly easy but I thought I would put it all here in a single post for you.

First in these examples I used the certificates from the http://www.globalsign.com site, I saved the www certificate to globalsignssl.crt and its issuer to globalsignssl.crt.

Next you will find a series of commands used to generate both POSTs and GETs for OCSP:

1. Create a OCSP request to work with, this also will produce a POST to the OCSP responder

openssl ocsp -noverify -no_nonce -respout ocspglobalsignca.resp -reqout ocspglobalsignca.req -issuer globalsigng2.cer -cert globalsign.com.cer -url "http://ocsp2.globalsign.com/gsextendvalg2" -header "HOST" "ocsp2.globalsign.com" -text

2. Base64 encode the DER encoded OCSP request

openssl enc -in ocspglobalsignca.req -out ocspglobalsignca.req.b64 -a

3. URL Encode the Base64 blob after removing any line breaks (see: http://meyerweb.com/eric/tools/dencoder/ for a decoder)

4. Copy the Base64 into the URL you will use in your GET

http://ocsp2.globalsign.com/gsextendvalg2/{URL encoded Base64 Here}

5. Do your GET:

curl --verbose --url http://ocsp2.globalsign.com/gsextendvalg2/MFMwUTBPME0wSzAJBgUrDgMCGgUABBSgcg6ganxiAlTyqPWd0nuk87cvpAQUsLBK%2FRx1KPgcYaoT9vrBkD1rFqMCEhEhD0Xjo%2FV7lgq3ziGoWG69rA%3D%3D

 

If you like you can also re-play the request that was generated with OpenSSL as a POST:

curl --verbose --data-binary  @ocspglobalsignca.req -H "Content-Type:application/ocsp-request" --url http://ocsp2.globalsign.com/gsextendvalg2