OCSP Expect-Staple is a new reporting mechanism to allow site owners to monitor how reliable their OCSP Stapling implementation is. With live feedback coming direct from the browser, you can build confidence before enforcing OCSP stapling with OCSP Must-Staple.


Fixing revocation

I don't need to talk about how broken revocation is. In it's current form it's essentially useless and we're now taking steps towards fixing that with mechanisms like Certificate Transparency (CT) and OCSP Must-Staple that I talked about earlier this week. CT allows us to know that mis-issuance has happened and pursue revocation with the CA and Must-Staple allows us to prevent an attacker from abusing one of our certificates if they get the private key. You can read more details in my blog about OCSP Must-Staple but in short it's a flag in the certificate that tells the browser it must be delivered with a stapled OCSP response. Before you commit to such a strong measure though, it'd be a good idea to test that you can reliably deliver certificates with the correct OCSP response stapled!


Policy delivery mechanisms

Currently there's only really one way that you can deliver your requirement to the browser to expect OCSP stapled responses, an addition to the HSTS Preload List. The most logical delivery mechanism going forwards would be a TLS Feature Extension but I also much prefer the idea of a HTTP Response Header. Yes, of course I do have my own personal preference for security based HTTP response headers, but it is an incredibly simple and easy to deploy delivery mechanism. The Expect-Staple requirement is related to the TLS handshake so it does make sense to have the information there instead of later at the application layer so we will have to see where it goes. Interestingly, Expect-CT (blog coming on that soon) is a similar requirement but does have a HTTP response header option for delivery (spec). With the fairly aggressive deadline set by Chrome for all CAs to log to CT by October 2017 (link) I don't think that we could expect widespread deployment of a TLS Feature Extension before then for sites to test with. On the other hand, setting a HTTP response header requires almost zero effort by comparison, and here we are with the option to do so. Anyway, back on topic!


Preloading OCSP Expect-Staple

The Chromium HSTS Preload List also contains details on HPKP, Expect-CT and Expect-Staple preloading. If you're already in the preload list for HSTS then it's simply a case of requesting an update to your entry to add Expect-Staple. Here is the info given in the comments:

//   expect_staple: (optional boolean) true if the site expects responses to
//       contain stapled OCSP repsponses
//   expect_staple_report_uri: (optional string) if expect_staple is true, the
//       URI to which expect_staple reports should be sent.
//   include_subdomains_for_expect_staple: (optional boolean) whether subdomains
//       of |name| are also covered for |expect_staple|.

Once you've requested the expect_staple flag to be set and provided an address for expect_staple_report_uri (Secret Tip: https://report-uri.io already supports this, just get in touch with me to get access) you will filter through the Chrome update channels until you hit stable. I believe my entry is coming in Chrome 58 and here are my before and after entries:

{ "name": "scotthelme.co.uk", "include_subdomains": true, "mode": "force-https" },

{ "name": "scotthelme.co.uk", "include_subdomains": true, "mode": "force-https", "expect_staple": true, "expect_staple_report_uri": "https://scotthelme.report-uri.io/r/default/staple/reportOnly" },

Reporting

Once you have the Expect-Staple flag set then your visitor's browsers will start sending reports if they make a connection and don't receive a valid OCSP response stapled in the connection. The key point to note here is that they won't just report if an OCSP staple is missing, they will report if it's invalid, outdated or any kind of 'wrong'. The report takes the following format detailed in the design document (link):

{
 date-time: "[date]",
 hostname: "[hostname]",
 port: "[port]",
 response-status: "[enum]",
 ocsp-response: "[OCSP response]",
 cert-status: "[enum]",
 served-certificate-chain: "[PEM encoded chain]",
 validated-certificate-chain: "[PEM encoded chain]"
}

These reports will allow you to see not only that something went wrong but specifically what went wrong. If you're going to be enforcing OCSP stapling then getting feedback like this before you commit is invaluable.


Gotchas

As a mechanism, OCSP Must-Staple is great and there aren't any problems with it. The concern is whether or not you as a host can reliably staple a good OCSP response. This is what OCSP Expect-Staple mechanism will help you determine. IIS has a pretty good implementation of OCSP Stapling but Nginx and Apache aren't quite as good. I have a couple of tools and techniques, that I will publish soon, to ensure that my stapling solution is robust and Expect-Staple will help keep track of any problems that may arise even after you deploy Must-Staple.