Certificate Transparency Review

The principle of operation of the SSL / TLS protocol is based on public key cryptography. One or both sides of the interaction have certificates and associated private keys. This allows authentication and encryption of traffic.

As for authentication, it is more often than not mutual authentication, which implies the server checks the client certificate and the client checks the server certificate, but only the server authenticates the client. If necessary, the server can authenticate the client later using any available method, for example, using one-time passwords. The principle by which certificate authentication is performed is quite simple: the client signs a data set with his private key, and the server verifies this signature.

Encryption using SSL / TLS is not really asymmetric, as some people think. Asymmetric cryptography is used to exchange a symmetric encryption key. Further data exchange occurs using a symmetric cipher.

It would be possible to carry out cryptographic operations for authentication and encryption with only a key pair. But then there are difficulties with the distribution of public keys and trust in them. Each side of the interaction will be forced to somehow make sure that a certain public key corresponds to a specific subject. That is, you need to get the key through a trusted channel, otherwise how to make sure that we are not an attacker? Here certificates come to the rescue. They are a set of data signed by electronic signature, including information about the subject and his public key. The most important thing a certificate does is that it certifies that its owner (subject) has a pair of public key - a private key.

The trust model on the web implies that browsers (or other software) include certificates of certification authorities in the list of trusted ones, or directly trust the final certificates of subjects. Installing third-party certificates as trusted requires additional actions from the user, especially if you approach this process wisely. Therefore, the model of trust in the subject is more often encountered through trust in the certification authority that issued its certificate. In simple words: if I trust the CA, then I trust the certificates that it issues.

Of course, in addition to checking the signature of the certification authority, a number of other certificate validations are also made: validity period, presence in the revocation lists (CRL), purpose, etc.

Certificate for the domain

Domain owners receive certificates so that their website is accessible to users via HTTPS, which allows users to be sure that the traffic to the web server is protected and that the web server is not fraudulent. As the certification authority issuing the certificate, one is selected that is trusted for most browsers. Then site visitors will not have security warnings. Before signing the certificate, the certification authority checks that the domain owner is contacting it. For this, the CA can send a link to a technical email for this domain or, for example, ask to place a specific file on a web server. A more rigorous verification of the domain owner is required for certificates with advanced verification - Extended Validation Certificate.

Certificate Issues

There are examples where certification authorities issued certificates for domains without the permission of the owners of these domains:

• An IT manager from Finland registered such aliases in his mailbox: hostmaster@live.fi, security@live.fi and hostmaster@hotmail.fi. He later managed to obtain a certificate for the live.fi domain.
• The CNNIC Certification Authority issued the certificate to the intermediate certification authority, which used it to organize the man-in-the-middle on the local network. Valid certificates for visited websites were generated on the fly.
• During internal testing, Symantec issued certificates for several domains, including google.com and www.google.com

These and other cases of unauthorized issuance of valid certificates are not only worrying for users and technical experts. Certification authorities themselves do not want to lose confidence in the services they provide. And Internet giants like Google also do not want their services to be compromised without their knowledge.

Having a certificate (and a private key) from someone else’s domain on hand, you can organize a man-in-the-middle attack and not attract attention with any error messages, because the certificate for the domain, although illegal, is not valid from the browser’s point of view suspicions.

Certificate Transparency

So, we have come to the conclusion that the domain owner is not always aware of which certificates are issued for his domain. Certificate Transparency Project(CT) aims to get rid of this misunderstanding.

Certificate Transparency is an experimental open IETF standard and an open source project initiated by Google.

Certificate Transparency does not add any additional verification of domain ownership and does not prevent the issuance of certificates, but only allows anyone to find out about all the certificates that were issued by the certification center. When all certification authorities support this standard, it will become impossible to issue a certificate so that the domain owner cannot find out about it.

When using Certificate Transparency, information about each issued certificate is logged ( Certificate log) available for recording only and open to public audit. This log does not allow changing or deleting entries, but allows only their addition. Anyone can access the log and get information about the issued certificates. At the moment, there are already several such logs. Constant monitoring of these logs will allow you to track the release of all certificates for the domain and not miss the wrong one. To make the log only accessible by adding entries, a tree hash is used, otherwise called the Merkle tree . This allows you to verify that any newer version of the log includes any previous version. The log itself must be electronically signed, more precisely, the hash of the Merkle tree root for the log is signed.

When adding a certificate to the log, the signed time stamp of the certificate is returned. It is as if the promise of the log to include the certificate in the log for a fixed time. When establishing a TLS connection, the web server must, together with the certificate, provide the client with a time stamp from one or more logs. The client browser, in turn, should not accept the certificate if there is no valid time stamp.

There are three different ways to tell a client about a signed time stamp:

• Adding a time stamp to the X.509v3 certificate extension . In this case, the web server does not require any changes. The certification center sends the so-called pre-certificate to the log server, receives a signed time stamp in response, and only after that issues a certificate. Although the pre-certificate itself, due to a special extension, cannot pass validation on the client, its issuance by the certification center means a promise to issue a real certificate. Therefore, an incorrect issue of a pre-certificate is equivalent to an incorrect issue of a certificate.
• Passing a time stamp in the TLS extension signed_certificate_timestamp. Then changes are required on the web server so that it starts supporting such an extension.
• Through the OCSP Stapling mechanism . For this, the certification center issues a certificate and at the same time transfers it to the log server. Then the web server makes an OCSP request and receives a response with a signed time stamp from the certification authority.

Log monitoring is done by observers ( Certificate monitor ). These are the servers that track each new entry in the log and compare the new hash of the Merkle tree root with their own calculations. They are designed to find illegally issued certificates or unusual certificates, for example, certificates of certification centers.

Another role in Certificate Transparency is the auditor ( Certificate auditor) He takes partial information about the log and verifies that this information is consistent with other available partial information, that is, he is convinced of the correct behavior of the log and its cryptographic sequence. The second task of the auditor is to make sure that a particular certificate appears in the log. The auditor can be both the client’s browser and a third-party service. The audit function can also be performed by an observer.


As a result, when browsers do not accept certificates, information about which is not in the logs, it will be difficult to issue a certificate unnoticed for someone else’s domain. However, in order to detect an unauthorized issue of a certificate that meets the requirements of Certificate Transparency, the domain owner is forced to monitor the logs. That is, either independently maintain the observer server, or pay for the service to a third-party service that will notify the domain owner of the certificates issued for this domain.

Since the beginning of 2015, the Chrome browser requires CT support for EV certificates. So, for example, the address bar for the same domain now looks in Firefox and Chrome.


If you look at the connection details, you can see that there is no CT information for this certificate.
In Firefox browser alsoSupport for Certificate Transparency technology is planned . But Microsoft goes its own way and develops another technology. Starting with IE11, the built-in SmartScreen filter collects information about certificates visited by web pages. This data can be used to search for unusual certificates, for example:

• The website uses a certificate intended for a subordinate certification authority
• Unexpected use of a different certificate for visitors to a specific region
• Significant changes in the fields of certificates issued by a particular certification authority. For example, a change or lack of reference to OCSP.

In general, Microsoft's approach is more closed, largely aimed at its users. I will not particularly comment on it, since the topic is not about that.

Conclusion

Although the standard is still experimental, this does not prevent its gradual application. Both certification authorities and browser manufacturers have already partially begun to support Certificate Transparency, or at least announced their participation. Companies will receive a tool for control over certification authorities and will be able to quickly identify “bad” certificates. Certification Authorities will be even more responsible in issuing certificates. You should not rely on Certificate Transparency as a panacea, but it will definitely be possible to complicate the activities of attackers.