This blog post was written by Márton Horváth who worked on implementing a monitor for Certificate Transparency logs in the context of his student semester project. As a proof-of-concept, he used the monitor he created to collect information about logged certificates issued in Hungary or issued to Hungarian web sites. This blog post contains the main findings of the analysis of those certificates.
SSL certificates and the underlying PKI are the backbones of secure web transactions, but this system – just as any – has some weaknesses. One of such weaknesses is the lack of fast information propagation for easier detection of fraudulent activity. This problem motivated Google to introduce Certificate Transparency (or CT for short), which aims at extending the existing PKI by making it more open and verifiable. CT defines three main components: the logs, the monitors, and the auditors.
The most important components of CT are the log servers, which are cryptographically assured append-only databases of certificates. Certificates can be logged by the issuer (which is preferably a Certificate Authority) before or after the issuance, or by the subject (e.g., the operator of a web site). By logging a certificate to a known log, it becomes available to others, including monitors, which query these logs and check logged certificates.
What is this good for? Well, in case of any abuse of a logged certificate, there is a higher chance of someone detecting it. So submitting to a log server is a good thing from a security point of view. What we study in this post is how far the Hungarian web server operators progressed in this process so far.
The data used for this study was collected from public CT logs by a Proof-of-Concept CT monitor implementation developed in the CrySyS Lab. This monitor ran for 11 days at the time this article was written, filtering for certificates that have Hungarian reference in the subject or issuer fields.
The monitor – that is a simple program that queries logs for certificates that are interesting for the owner of the monitor (in our case Hungarian certificates) – found 427.026 matching entries during this time period. With a rough simplification every issuer and subject was considered distinct if there was any difference in the corresponding field (e.g., two certificates based on this logic come from different issuers if one of it had in the issuer field the [‘HU’, ‘Microsec Ltd.’, ‘Qualified’, ‘e-Szigno CA 2009 info@e-szigno.hu’] values and the other had [‘HU’, ‘Microsec Ltd.’, ‘Advanced Class 2’, ‘e-Szigno CA 2009 info@e-szigno.hu’], although they were both issued by Microsec Ltd). Using this method the aforementioned certificates have 122.416 distinct subjects and 129 distinct issuers.
According to Google, the preferred type of certificate logging in the long run is logging before issuance. It requires intervention to the issuing process of the CA, so it is more difficult to implement. The CA has to produce a yet unsigned special format of the certificate, called the pre-certificate, and this has to be logged before signing the real certificate, because in this way, the structure that is returned from the log server (called the SCT or signed certificate timestamp) can be attached to the certificate as an extension. So greater share of pre-certificates should be detected in the logs as time passes, but at the current stage, much more ‘classic’ x509 entries are expected. And this is exactly the case: the current share of pre-certificates in the logs is tiny as shown the following figure.
An interesting retrospection and good indicator of the popularity is the time distribution of logging events. The first certificate that we detected was logged on the 28th of February, 2017 at 9:55. It was still the only one in the 1st of April, so we started enumerating the monthly distribution from that date. The first day of the given month was the base of sampling. Representing this data on charts shows a more intense logging activity from October 2017 to February 2018.
This roughly fits the time period when it was believed that Google going to mandate the use of SCTs in Chrome for HTTPS based communications. By then Google announced a delay in introducing this policy, but it still seems that Google’s intentions had a pressing effect on site owners and CAs. The same tendencies could be seen if we display only the delta in the number of logged certificates in each month. There were two bulks of logging: a smaller one from May 2017 to August 2017 and a greater one from November 2017 to February 2018.
Now let’s see the perspective of the Certificate Authorities! Which CAs have been logging their certificates already? Who is using the pre-certificate format when logging?
It is not surprising that Let’s Encrypt logged the most certificate by far: 421,555 out of the 427,028 entries contains the string “Let’s Encrypt” in the issuer field. This is probably due to the fact that these certificates are free to acquire and Let’s Encrypt integrated the automatic logging in its issuing workflow following Google’s requirements. But one should not forget that the operator of the web site can also log its already issued certificates, so simply the amount of entries is not a good measurement of progress on the CA’s side. Rather the existence of pre-certificate entries should be examined, as those can only be produced before issuance, so those must have been logged by CAs for sure. Considering this, we have to re-evaluate Let’s Encrypt’s advantage in logging, as it has no pre-certificate entry at all. Considering logged pre-certificates, the best result was achieved by DigiCert with 1,395 entries.
The Hungarian CAs has also started to implement logging: there is a sum of 374 certificates that contain reference to a Hungarian issuer CA. Regarding pre-certificate vs. “classic” x509 certificates, Microsec is leading with 18.25%, followed by NetLock with 2.01%.
An entry also contains meta information, such as a timestamp of the log event. We can use this combined with the “not before” field from the certificate to estimate the time difference between issuance and logging. This is not so precise though, because the “not before” value could be set after the issuance. In any case, a big difference in this difference is something notable. We calculated the (not_before – logging_timestamp) difference for every entry. We did not find any negative differences which means that no certificate was logged before it became valid. This fact implies that the issuers already calculate with the delay introduced by the logging and set the “not before” field, according to it. The minimal time to log was 1 hour and 1 second, the maximum was more than 18 years. This latter was a certificate with a “not before” field of 1999 that was logged in 2017. The average difference was about 4 days, but because of these kinds of edge cases, probably the median, which was 3 hours, represents the dataset better. This data also describes the x509 entries correctly, because those entries make up the majority of the log entries. On the other hand pre-certificates themselves show a very different distribution. The minimum difference for them is the same 1 hour and 1 second, but the maximum difference is 1 day and 1 hour. This may not be surprising, because most logs offer a 24-hour maximum merge delay (MMD), meaning that they append the entry to their database within this time interval. In this case, the 11 hours average difference and 10 hours median did not differ that much.
The examined extension field (extended key usage) provided the expected result. Most of the entries contain the serverAuth and clientAuth value. The public key algorithm field within the subject public key info shows that most certificates (426,692) contain an RSA key and only a couple of them (334) contains ECDSA keys.
Certificate Transparency is a new way the improve the security of PKI without much effort from the participants of the TLS certificate issuance process. In addition, it is designed to be optional, hence it does not require everyone to adopt it instantly. So introducing it is a good trade-off for the community. The Hungarian CAs and web server operators have already started to include logging into their procedures, but there is still much room for improvement, especially, in the aspect of logging pre-certificates rather than already issued certificates.