Symantec criticises Google for stripping security certificate checks from Chrome

Stripping OCSP (Online Certificate Status Protocol) and CRL (Certificate Revocation List) checks from Google Chrome could have dangerous implications because it will turn Google into a single point of failure, according to security vendor Symantec.

When accessing a website over HTTPS, browsers check whether its SSL certificate has been revoked by the issuing certificate authority. This is done by querying the CA's OCSP responder or by checking its published certificate revocation list.

For usability reasons, all major browsers currently ignore OCSP and CRL requests that result in network errors by default, in what is known as a soft fail mechanism. However, some of them do offer users the option to enable hard fail, which triggers errors for every request that goes unanswered.

Adam Langley, security engineer at Google, has announced that Chrome will stop performing OCSP and CRL checks in future versions. Instead, these checks are to be replaced with a locally cached list of revoked certificates that will be kept up to date by Google.

The reasons behind the decision are related to performance and security issues. OCSP and CRL requests increase page load times and are susceptible to blocking by man-in-the-middle attackers or captive portals, websites commonly used by Wi-Fi access points to prevent HTTP connections before users authenticate.

"This is a corner case that happens very infrequently. We argue that one shouldn't discard OCSP and CRLs because they don't work in a tiny fraction of cases," said Fran Rosch, vice president of Trust Services and SSL at Symantec. "His proposal to have the browser maintain a list of revoked certificates turns Google into a single point of failure, which Langley himself agrees is bad engineering practice."

According to Rosch, the soft fail mechanism currently used by browsers is the real issue, since it allows HTTPS sessions to continue without establishing whether the SSL certificate is valid or not. Symantec has maintained an uptime of 100 percent for its OCSP and CRL services for the past ten years, so CA-level downtime shouldn't be a concern, he said.

"OCSP clearly does not work today because all major browsers operate it in soft fail mode. That needs fixing," said Ivan Ristic, director of engineering at security firm Qualys. "My view is that Google should have first made an effort to fix the problem," he said.

Qualys plans to start a project called "Global OCSP Responder monitoring" which will track the availability of all OCSP responders and identify CAs with unreliable ones. "That would hopefully enable everyone to switch to hard fail by default," Ristic said.

According to Ristic, the performance issues could be resolved with the help of a technique known as OCSP stapling, which involves the owner of a SSL certificate querying the CA's OCSP server periodically and caching a signed response. This response would then be served to clients directly without them needing to open a connection to a separate host.

"Even without OCSP stapling, browsers can start to display a website and perform the check in the background, so there's not going to be an immediate performance impact," Ristic said. "They could hard fail after a second or two, possibly preventing further interactions with the site."

Removing OCSP checks from Google Chrome might even have legal implications for users, who won't be able to claim warranties for damages resulting from the use of bad certificates if the software they rely on doesn't make an effort to check certificate revocation status, said Eddy Nigg, founder and chief technology officer of certificate authority StartCom, via email.

"Strictly speaking, Google as a relying party and software vendor might not be able to make use of the CA root certificates its browser currently uses, due to non-compliance to those relying party obligations," Nigg said.

Nigg agreed that the problem is the soft fail mechanism implemented in browsers, which he described as a failure in itself. "It's rather the browsers that have fairly weak implementations at their side and don't try hard enough (and smart enough) in order to obtain a status response," he said.