Preface#
In the field of SSL/TLS certificates, we have to mention OCSP (Online Certificate Status Protocol). It is a protocol used for online checking of certificate status, allowing clients to determine if a target server is trustworthy. In a recent discussion with Steamfinder, he mentioned that Kaspersky Enterprise Edition reported an SSL/TLS certificate status error for a website, while the Standard Edition did not report it. At that time, I speculated that it might be a problem with the OCSP configuration of the website (possibly requiring OCSP Stapling to be enabled, but the website did not configure it), and the Enterprise Edition focuses more on security, so it checks OCSP Stapling, while the Standard Edition does not.
Verification#
First of all, it should be noted that the design goal of OCSP is to better check the revocation status of certificates, so it considers factors such as lightweight design. Compared to the previous Certificate Revocation Lists (CRL) method, which requires downloading a large file from the Certificate Authority (CA) and matching whether the target certificate is in the revocation list, it is very cumbersome and slow to respond. Moreover, the status of the certificate needs to wait for the CA to update the CRL, which introduces a certain time difference. If a revoked website is accessed within this time difference, but the CRL has not been updated, the security level for ordinary users will be lowered because the revoked certificate is verified as trusted within the time difference! The emergence of OCSP is precisely for lightweight real-time online verification.
Before this, I have verified whether Chrome and Firefox will actively initiate OCSP requests. I recorded the entire DNS request process through my DNS server and accessed a subdomain to check the OCSP request for the certificate of that subdomain. Obviously, Chrome does not actively request OCSP to check the certificate status, while Firefox does. Moreover, Firefox has OCSP queries enabled by default, as shown in the following figure:
So, does Chrome have a similar option? I searched for a long time in Chrome's settings and did not find this option. And I tried to find similar settings on the chrome://flags page, but still did not find it. This is because Google has actively disabled this option, believing that it may leak user privacy information and affect the loading speed of Chrome web pages.
Experiment#
Based on the previous information, readers should already know that Chrome does not actively check the certificate status under normal circumstances. As long as the certificate chain is complete and can be verified to the root certificate, it is generally considered trusted. Firefox, on the other hand, verifies the certificate status through OCSP and determines whether the certificate has been revoked based on that status. So why does Chrome behave like this? Because most OCSP websites use the HTTP protocol and do not use the TLS layer (it is not possible to request the certificate of an OCSP website and recursively request its OCSP information when requesting an OCSP website). As everyone knows, HTTP is plaintext, and anyone can inspect HTTP packets without the TLS layer. During this process, user privacy may be compromised, which is a reasonable consideration for Google. Others can learn which websites a user has visited by inspecting OCSP requests because each SSL/TLS certificate has different OCSP information. Given that the traditional CRL update speed is slow, Google maintains its own CRL. In fact, similar to the previous CRL, there is also a time difference for updates.
My experiment is as follows: I applied for an SSL/TLS certificate for my own subdomain and installed it. Then I accessed the subdomain using Chrome and Firefox respectively. Of course, Firefox checked the revocation status of the certificate. Then I manually revoked the certificate and accessed it again using Chrome and Firefox respectively. The access in Chrome was normal, while Firefox reported that the certificate had been revoked. Therefore, OCSP is quite timely. This also shows the insecurity of Chrome disabling OCSP certificate verification.
Enabling OCSP Verification in Chrome#
So, can Chrome really not enable OCSP verification? After some searching and testing, if you create the following two directories 1:
- /etc/opt/chrome/policies/recommended
- /etc/opt/chrome/policies/managed
And write a JSON file in the managed directory with the following content:
{
"EnableOnlineRevocationChecks": true
}
You can enable Chrome's OCSP queries. Through DNS, it can be seen that Chrome requests the OCSP website, as shown in the figure below:
Discussion#
Regarding the reason why Google disabled OCSP, I think it may be due to speed considerations. In the entire TLS handshake process, the speed of OCSP significantly affects the overall handshake speed. If the OCSP server is overloaded or responds slowly, it will affect the website loading speed. For Google, which pursues speed, this is unacceptable. Therefore, protecting user privacy may only be an incidental consideration.
At the same time, Google also needs to compete with its competitor Firefox. Firefox focuses more on security and privacy, so OCSP is enabled by default. However, in some cases, enabling OCSP may cause certain websites to be inaccessible (for example, if the OCSP information is incorrect or the certificate requires OCSP Stapling to be enforced, but the website is not properly configured). In comparison, Chrome can still access these websites, which has established a good reputation for Chrome.
To address the issue of OCSP response speed, OCSP Stapling technology was introduced. Web servers can proactively obtain the OCSP information of their own certificates from the OCSP server and cache it. During the TLS handshake process, the server can directly respond to the client with the OCSP Stapling information, saving the time and latency for the client to query the OCSP server separately. It is worth noting that the OCSP information is signed by the CA's private key, so forgery is generally not a problem.
However, in the verification process, Chrome does not seem to give high priority to the OCSP Stapling information provided by the web server. Chrome's verification priority is to first check the CRL maintained by Google itself, then perform OCSP queries, and finally consider the OCSP Stapling information. This actually goes against the original intention of OCSP Stapling, which is to allow the client to directly use the validated OCSP Stapling information provided by the web server. In comparison, Firefox can happily accept and use the OCSP Stapling information provided by the web server. After updating to Chrome 114 (Linux), it seems that the priority has been modified, and OCSP Stapling has the highest priority.
In China, there have been cases of OCSP domain contamination for Let's Encrypt CA. Since many websites use certificates issued by Let's Encrypt CA, when the OCSP domain is contaminated, it leads to a large number of failed TLS handshakes. This has had a certain impact on users accessing these websites. This situation forced Let's Encrypt CA to change the OCSP domain to solve the problem and ensure that users can access websites that use its certificates normally.
In conclusion, I believe that Chrome actively disabling OCSP is to compete with Firefox, as the impression given to users is that Chrome is fast and Firefox is slow.
I hope Firefox will continue to compete with Chrome!
References#
This article is synchronized and updated to xLog by Mix Space.
The original link is https://www.timochan.cn/posts/study/ocsp_certificate_status_verification_exploration