What is the exact difference between regular OCSP and OCSP stapling?
OCSP stapling is more efficient than regular OCSP and provides better privacy.
The OCSP protocol is used to determine if a certificate is still valid or has been revoked. Say, you want to securely connect to a website via TLS. To be certain that the certificate has not been revoked or expired, your browser can issue an OCSP request to the corresponding certificate authority. After receiving a signed confirmation of the certificate's validity, you then continue with the TLS handshake.
This process has some downsides: Contacting the CA costs time and slows down your browsing experience. It may also create high traffic volume for the CA, discloses to the CA which website you're visiting and you always have to rely on the availability of the OCSP responder since otherwise no confirmation is possible - and you would have to decide between accepting the certificate despite a lack of confirmation or abort the connection. For these reasons Google Chrome has dropped support for regular OCSP.
OCSP stapling avoids these problems by having the server issue the OCSP queries periodically itself. Instead of making the user perform the validity check, the web server would present you the OCSP response during the TLS handshake. It is not a security problem that the server performs the OCSP query itself as the response has been signed by the CA and includes a timestamp, thus preventing tampering. Since the server caches the response, the CAs aren't flooded with OCSP requests anymore and as a user you don't need to contact a third party to have a certificate verified which benefits your privacy.
Somethings to add to @Arminius' answer:
- client initiated OCSP request and OCSP stapling still share a problem - non responsive OCSP responders. Whether it's the client, or the server that is being certified, that's getting the OCSP response, the responder is the same. If the responder is down, the whole security guarantees fall apart.
The absence of a valid OCSP response is dealt in two ways :
Hard Fail - a browser can display a warning on the page stating the connection might be compromised and require the user to click through the warnings to be able to browse the server in question.
Soft Fail - browser attempts to get a valid OCSP response (from the responder or from the certificate sent by the server in case of OCSP staple) but in the case of failure carries on with the connection and ignores the absence of a valid OCSP response.
In order to maintain availability the browsers usually prefer the 2nd approach.
It's hard to say that one way is more secure than the other. The OCSP staple does reduce the load on the responder reducing the chances of it being DOS-d by genuine requests. The cached responses on the server side speed things up quite a bit and reduce the load on the browsers to do the OCSP heavy lifting. That said an attacker can potentially still DDOS an OCSP responder and prevent even the genuine servers from obtaining a valid OCSP staple.
OCSP Stapling has however resulted in a lot of increased performances as is explained by this short but brilliant post by Nick Sullivan from Cloudflare in his blog. If we can get around the problem of Unresponsive OCSP Responders, and can find a way to be assured that an ocsp response will always be presented, certificates can be generated with ocsp-must-staple extension. THIS, if in place, would mean stronger security guarantees as compared to no ocsp staple.