Certificate Transparency Overview

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



With regard to authentication, it is not common to authenticate each other, which involves checking the server of the client’s certificate and checking the client’s server’s certificate, but only authenticating the server to the client. If necessary, the server can authenticate the client later by any available method, for example, using one-time passwords. The principle of certificate authentication is quite simple: the client signs a dataset with his private key, and the server verifies this signature.



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



To perform cryptographic operations for authentication and encryption, it would be possible to have 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 particular public key corresponds to a particular subject. That is, you need to get the key through the trusted channel, otherwise how to make sure that we are not an attacker? Here certificates come to the rescue. They are a digitally signed data set, including information about the subject and its public key. The most important thing that a certificate does is that it certifies that its owner (subject) has a pair to the public key — the private key.

')

The trust model on the web means 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 are wise to approach this process. Therefore, the model of trust to a subject is more often found through trust to the certificate authority that issued it. In simple words: if I trust the CA, I trust the certificates that it issues.



Of course, in addition to verification of the signature of the certifying center, a number of other certificate validations are also made: expiration date, presence on revocation lists (CRL), appointment, etc.



Certificate for domain



Domain owners get certificates to make their website accessible to users via HTTPS, which allows users to be confident that their traffic to the web server is safe and that the web server is not fraudulent. As a certificate authority issuing a certificate, one that is trusted for most browsers is selected. Then site visitors will not have security warnings. Before signing the certificate, the certifying center verifies that the domain owner is accessing it. For this, the CA can send a link to the technical email for this domain or, for example, ask to place a specific file on the web server. Stricter domain owner verification is required for certificates with extended validation - Extended Validation Certificate.



Certificate Issues



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

• An IT manager from Finland registered such aliases to his mailbox: hostmaster@live.fi, security@live.fi and hostmaster@hotmail.fi. Later he managed to get a certificate for the live.fi domain.
• The CNNIC Certification Authority issued a certificate to an intermediate certification authority, which used it to organize man-in-the-middle on the local network. The generation of valid certificates for visited websites took place on the fly.
• When conducting 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 do not only concern users and technical specialists. Certification centers themselves do not want to lose confidence in the services they provide. Yes, and Internet giants, like Google, too, do not want their services to be compromised without their knowledge.



Having a certificate (and a private key) from someone else’s domain, 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 valid from the browser’s point of view suspicions.



Certificate Transparency



So, we come to the fact that the domain owner is not always aware of what certificates are issued for his domain. The project Certificate Transparency (CT) is designed to get rid of this misunderstanding.



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



Certificate Transparency does not add any additional checks 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 authority. When all certifying centers maintain this standard, it will be impossible to issue a certificate so that the domain owner could not find out.



When using Certificate Transparency, information about each issued certificate is recorded in a log ( Certificate log ) write-only and open to public audit. This log does not allow to change or delete records, and allows only their addition. Anyone can access the log and get information about certificates issued. 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 to miss the wrong one. To make the log available only for adding records, tree hashing is used, otherwise called the Merkle tree . This allows you to check that any newer version of the log includes any previous version. The log itself must be signed with an electronic signature; 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 like the promise of a log to include a certificate in a 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 several logs. The client browser, in turn, should not accept the certificate if there is no valid time stamp.



There are three different ways to inform a customer about a signed time stamp:

• Adding a time stamp in the extension of the X.509v3 certificate. In this case, the web server does not require any changes. The certification authority sends a so-called pre-certificate to the log server, receives a signed time stamp in response, and only after that issues a certificate. Although a pre-certificate itself cannot be validated by a client due to a special extension, its issuance by a certification authority means a promise to issue a real certificate. Therefore, an incorrect pre-certificate issue is equal to an incorrect certificate issue.
• Transmit time stamp in TLS extension signed_certificate_timestamp. Then the web server needs changes to make it support this extension.
• Through the OCSP Stapling mechanism. To do this, the certification authority issues a certificate and simultaneously sends it to the log server. Then the web server makes an OCSP request and receives a response from the certification authority with a signed time stamp.

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



Another role in Certificate Transparency is the auditor ( Certificate auditor ). It takes partial information about the log and verifies that this information matches other available partial information, that is, it 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 specific certificate appears in the log. The auditor can be a client’s browser or a third-party service. Auditing functions can be performed by an observer.





As a result, when browsers will not accept certificates, information about which is absent in the logs, it will be difficult to issue an imperceptible certificate for another domain. However, in order to detect the unauthorized release of a certificate complying with the requirements of Certificate Transparency, the domain owner is forced to monitor the logs. That is, either independently support the server supervisor, or pay for the service to a third-party service that will notify the domain owner about the certificates issued for this domain.



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





If you look at the details of the connection, you can see that there is no CT information for this certificate.

Firefox also plans to support Certificate Transparency technology. But Microsoft goes its own way and develops another technology. Starting with IE11, the built-in SmartScreen filter collects information about certificates of web pages visited. 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 another certificate for visitors to a specific region
• Significant changes in the fields of certificates issued by a certain certification authority. For example, change or absence of the link 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 centers and browser manufacturers have already partially started to support Certificate Transparency, or at least have declared their participation. Companies will receive a tool for control over certification centers and will be able to quickly identify "bad" certificates. Certification centers will be even more responsible in issuing certificates. You should not rely on Certificate Transparency as a panacea, but it will definitely succeed in complicating the activities of intruders.