Google takes a step forward to improve Certificate Transparency’s ecosystem: No dependence on Google

Sergio de los Santos    12 April, 2022
Man searching in Google. Photo: Unsplash

Although Certificate Transparency (CT) is not very popular among ordinary users, it affects them in many ways to improve the security of their connection to websites.

What’s more, it even affects their privacy and they certainly weren’t taking this into account. Now Google (the main promoter of CT) is taking a step towards independence from the ecosystem, but it must still improve its privacy problems.

What is Certificate Transparency?

Let’s make it short. If a certificate is created, it must be registered on public log servers. If not, it will be suspected to have been created with bad intentions. To “register” it, a Signed Certificate Timestamp, or SCT, is created, a signed cryptographic token given by a Log server as a guarantee that the certificate has been registered in it.

This SCT is always embedded in the certificate and when visiting a website, the browser checks that it is valid against several log servers. One of them must be from Google (there are several certificate companies that have public logs). If this is not the case, an error is displayed. All this happens without the user being aware of it.

An SCT embedded in the certificate, which the browser must check.
An SCT embedded in the certificate, which the browser must check.

However, the SCT is more of a promise to put the certificate in the log, because nothing prevents a log operator (who can be anyone) from agreeing with an attacker, creating a certificate, granting him/her an SCT… but not actually making it public in his/her log. This would invalidate the whole CT ecosystem. How did Google solve it? Through two moves.

  1. One is that there always had to be a “Google Log” among the required ones (currently three) where the certificate was registered. This way, Google trusts itself and knows that it will never do wrong by sending an SCT to a certificate that it has not actually registered.
  2. The other one is “SCT auditing”, which, if poorly implemented, would imply a clear infringement of users’ privacy.

Both solutions have their problems. Let’s look into them.

Chrome showing the three logs where the SCT is valid. Always a Google one... until now.
Chrome showing the three logs where the SCT is valid. Always a Google one… until now.

At least one Google Log

If Google doesn’t trust other logs, why should it trust its own? Because it is the best solution it found at the time. A certificate will not be considered to be validly compliant with the Certificate Transparency ecosystem if it is not in a Google Log…. At least until this month, where that need has been removed.

This will be implemented in Chrome version 100. It is worth remembering that Apple already went its own way with Safari, and in March 2021 announced that it would not follow that policy of relying on Google, that knowing that the SCT was in two different logs was enough for it.

Privacy and SCT auditing

SCT auditing also came not long ago as one of the solutions to control the SCTs and make the logs really perform well. It is simple: randomly audit the SCTs of the certificates and check that they are really in the logs. But how? Well, as Google knows best: using the user and taking advantage of Chrome’s adoption to send the SCTs of the sites visited to the logs to check that they have indeed been registered.

There was a lot of talk about SCT auditing, but it really was an attack on user privacy and a problem to implement. But they did it again in the March 2021 version of Chrome, in the best way they knew. How? They enabled SCT auditing only for users who already shared, through the enhanced data sharing that can be done with Safe Browsing, their visits with Google. As this was something that users activated voluntarily, they were also added as “SCT auditors” in passing. It is not the default option.

Announcement of how SCT auditing would work
Announcement of how SCT auditing would work

The two formulas described above help to control that a malicious log does not issue an SCT for a certificate without being logged by that same log. But SCT auditing must have worked out well for Google since it seems to eliminate the first formula and (as Safari already did) from now on one of the logs does not need to be specifically from Google.

Therefore, in order to ensure that the Logs, we are left with SCT auditing where all users who already share certain browsing data with Safe Browsing are also ensuring a more secure CT ecosystem in turn.

Firefox does not implement Certificate Transparency.

Leave a Reply

Your email address will not be published.