I would like to express why I believe OCSP stapling should be listed in the `Best Practices' PDF file located at https://www.ssllabs.com/projects/best-practices/index.html , and why I believe it is potentially dangerous and will not be running it on my web servers. BTW thank you to the author of that PDF, I learned a lot.
The problem it is trying to solve is a PKI problem, PKI does not have a method that scales well for determining that a signed TLS certificate has not revoked by the signing authority.
From what I have read about OCSP stapling, and I invested it fairly heavily over the past few days - I want my TLS web servers to be secure, what OCSP stapling does is deliver signed timestamped confirmation to the client that the certificate is valid and has not been revoked, and that is all it does.
It does not increase the security of my web server itself, nor does it fix the PKI problem. All it does is reduce the amount of work the client has to do because of the PKI problem.
But the way that OCSP stapling does even the small thing that it does is fundamentally dangerous. It requires that I continually execute code on my web server that makes a remote connection to access data that I do not control, and then it does things with that data (serves it in a header).
That potentially creates a remote vulnerability on my web server if there is a flaw in the code (apache module, cache, whatever) that provides OCSP stapling.
With respect to the benefit that risk provides between my server and the requesting client, the real benefit is it gives the requesting client more confidence that it is not being taken in by a MITM attack. However, that confidence is mis-placed because a MITM with a fraudulently signed certificate can still send that header as long as the certificate has not been revoked, and simply stop sending the header if / when the certificate is revoked.
A better way to provide confidence that the client is not talking to a MITM is to use DNSSEC with TLSA.
Using DNSSEC with TLSA, the client can validate the signature going all the way from the root DNS server and know that the fingerprint in the TLSA RR is valid. That doesn't validate the certificate, but it does validate that the certificate is the certificate that is suppose to be used with the domain the client is connecting with, at the IP address that is the IP address that the domain is suppose to be at.
That provides much higher confidence that a MITM attack is not taking place. Financial institutions and other likely candidates can increase the confidence even more by using an EV certificate with TLSA.
The DNSSEC/TLSA solution to giving the client confidence also does not require any addition code be deployed on the web server, let alone code that makes remote connections, so it does not add any additional risk to the security of the web server.
The DNSSEC/TLSA solution does not address the flaw in PKI but honestly, neither dot OCSP stapling.
I do have an idea of how to better address that scalability flaw in PKI certificate checking but that is a different topic.
At any rate, that is why I personally do not believe OCSP stapling is the right thing for web servers to be doing.
Thank you for reading this, and I humbly acknowledge that most of you probably have far more experience and knowledge in this area, but I still have to go with what my own critical thinking skills produced unless I can be shown otherwise.