Past and Present SSL Certificates

SSL appearance

SSL (Secure Sockets Layer), a family of cryptographic transport, has been known since about 1994 (the first work on the use of cryptography as a transport for already known protocols has been carried out before).

The latest protocol of the family, SSL v3, in June 2015 in RFC7568 is deprecated. Instead, it should use the new version of the SSL family, TLS (Transport Layer Security) version 1.2 or later (at the time of this writing).
')
Both protocols use the so-called public key certificate of the X.509 standard, which is not quite correctly called the SSL certificate now. The standard has been known since 1988. The public key certificate, which has been successfully used throughout the past time, has managed to demonstrate its strengths and weaknesses (as described below).

X.509 is used in the so-called public key infrastructure (PKI) - this includes not only software for using certificates and other components of the standard for transmitting data over intercepted channels, but also equipment, organizations, and people who comply with the standards and ensuring the functioning of the entire infrastructure in all different scales. A single system administrator may be sufficient to successfully maintain a PKI within a fairly large local area network of a not very large organization.

It is important to understand that the SSL certificate is just a document format. It is not a "magic" tool for building confidence in a particular resource. The certificate allows, under certain conditions, to verify the authenticity of the transmitted data, to indicate the degree of confidence in the source of the encrypted data. Like any tool, a certificate can be used both to form a certain degree of trust in the data source and to discredit it.

Public key cryptography

Until 1970, only symmetric key cryptography was used. The obvious weak link in such cryptographic schemes is the need to transfer the key to all parties involved in a secure exchange.

The inventor of public key encryption is Ralph Merkle. If, in the case of symmetric encryption, the same key (a fixed set of data of arbitrary length) is used for both encryption and decryption, then in the public key approach there are two keys: a secret one that only the owner should know and a public one that everyone can wishing. Only the owner of the secret key can decrypt the ciphertext intended for it or sign with the key any data set (file). At the same time, any owner of the public key can send (encrypt) the text to the owner of the secret key, or verify the signature of a file.

Theoretically, a public key encryption system relies on the fact that decomposing sufficiently large numbers to simple factors will require a lot of time and / or significant computational power. This is the basis of the selection of the secret key for the well-known public Everything depends on computing resources and time. Today it is considered that the use of keys with a length of 2048 bits does not allow, in general, to pick up the secret key within a reasonable time within the limits of the computing power currently available. We recommend that you familiarize yourself with the details of how the key length affects the probability of opening a cipher in the case of symmetric encryption and public key encryption. Simplifying: a public key with a length of 1024 bits in terms of the required computational power is approximately the same racks as an 80-bit symmetric key.

In the case of RSA (abbreviation by the names of the inventors of this cryptosystem, Rivest-Shamir-Adleman), the encryption speed is roughly proportional to the square of the key length, and the decryption is cube. Modern cryptography programs operate in general with keys up to 4096 bits. Even 2048 bits in many cases is enough to rule out the possibility of hacking in a reasonable time. The use of longer keys can significantly increase the time and computational power, as well as the size of the received ciphertext, without adding significant differences in the time required for decryption. That a hundred years, that a million - in practice, in most cases there is no difference.

An important point: if you managed to save both the ciphertext and the public key that is relevant for that moment, then sooner or later (theoretically) the text will be read. This should be borne in mind if the information is intended for long-term storage without access to it by third parties. Encryption in this form does not imply the presence of so-called. Perfect forward secrecy , when obtaining a key for encryption in the future would not affect the ability to decrypt past messages.

Certificates and PKI in general

It is not very difficult to formulate the basic principles of a PKI. Since everything revolves around pairs of keys and digital signatures, the basics are easy to derive based on these terms.

A certificate allows you to determine the degree of trust - because anyone can create a certificate, the question is in trust. The digital signature of the public key (one of the parts of the certificate) is also a way to indicate trust.

Having a digital signature means that there is a beginning somewhere in this chain. So-called root certificates, which usually belong to certificate authorities (CA), must be taken for granted. In practice, a number of root certificates are already entered either into the corresponding storage of a specific operating system, or into the storage of a program using SSL / TLS (such as browsers, email clients, etc.).

In addition to having a digital signature from a trusted CA, you need to associate a certificate with a specific resource (for example, a Web site accessed over HTTPS or another similar secure protocol). The certificate indicates the domain name and / or IP address of the resource so that the client can determine how authentic the certificate is. For the same reason, the certificate indicates to whom it was issued (to a person or organization), its validity period. All this, taken together, allows you to make sure that the certificate is used by those to whom it was issued.

CA issuing (signing) certificates, in fact, vouch for the integrity of the owners of the resources to which they are issued. This leads to the false conclusion that a certificate obtained from a reliable CA, especially a paid one (and even more so - a very expensive one), guarantees integrity.

In practice, of course, it is not. Although icons and badges that demonstrate the degree of trust in the site (for example, the green lock in the address bar) are widely used, the existence of an expensive certificate alone cannot guarantee that site visitors are guaranteed safety, high quality of service and no subsequent trouble.

It must be remembered that the interaction is with people. The reliability, security, and other benefits of using X.509 certificates are determined by the weakest link in all security systems: specific people.

Summarizing: SSL certificates are used to implement the following key features:
confidentiality of communication;
confirmation of the integrity of the message (that it was not changed during the delivery process);
confirm the authenticity of the message source.

Revocation of keys and certificates

Those who use cryptography, for example, a program like GnuPG (or its “ancestor” - OpenPGP), know the concept of revocation certificate (revocation certiificate). Since public key servers are used to distribute GnuPG keys, to cancel subsequent operations with a specific key, it is usually sufficient to send a special certificate to the key server announcing the specific key as revoked. After that, anyone who takes your keys from key servers will not be able to use a key that has already been revoked, thereby putting at risk communication with you over a secure channel.

In the case of SSL certificates, there are several protocols (CMP, OCSP , etc.), allowing to determine the status of the certificate and, accordingly, the possibility or impossibility of its use. In practice, since, in reality, connectivity within the Internet and the rapid response of various resources are not guaranteed, there is no way to reliably announce certificate revocation. A typical installation of “trusting a certificate if it is not possible to check its status” can be used by attackers in a situation where it is possible to block access to services that verify the authenticity.

Different trust models

CA can perform both simplified verification, only by domain (DV - when verifying that the ordering certificate controls the domain settings), and extended (OV - organization verification; EV - organization verification). Depending on the situation and the type of certificate requested, verification may include checking the existence of the contracting authority, the presence of valid contact information, etc.

Because of all this, prices for OV / EV-type certificates for which verification is required, and most importantly - a guarantee (for example, in the form of insurance), can be quite high. In this regard, it is worth mentioning the Web of Trust model, when trust extends not only from the root certificate, the reliability of which is beyond doubt, but from a person or organization that other members of the trust network have voted for.

Simply put, if trust is confirmed to one of the network members, then it applies to all other members of the same network. The verification procedure itself usually requires the physical presence of a person, so the distribution of such networks may not be very easy.

Among the shortcomings of the “trust network” approach is a not very clear procedure for revoking trust (both by the efforts of the network participant itself and those of other individuals or organizations).

An example of a CA operating under a trust network scheme is OpenCA . With a minimal level of trust, their certificates essentially confirm only the fact that the domain name is managed. In addition, the OpenCA root certificate is not included by default in the truststools of the OS and individual software products - so it remains to be persuaded the user to enter it manually. The use of certificates for resources of a commercial nature, for resources processing or storing private data, etc. becomes problematic.

EFF (Electronic Frontier Foundation) announced the launch of Lets Encrypt service in September 2015, where a free certificate will be able to receive each resource.

Trust Abuse

The main weak link of any security schemes - people. PKI is no exception. In the event that the interests of the state or other power structures meet the user's expectations, it becomes possible to use the so-called. SSL proxy ( man-in-the-middle attack option), thereby disappearing confidence that the data exchange remains confidential.

Two well-known examples illustrating the potential risks of using trust schemes that are fundamental to this infrastructure. The Dutch CA DigiNotar was closed after a series of incidents that began on July 10, 2011, when attackers obtained fake multi-domain certificates (initially used to disguise as Google services, a few days later the domains of other popular Internet services were added to the list).

Another example is an incident with CA TrustWave , which issued in 2011 a subordinate (child) CA certificate suitable for falsifying any certificate in a situation when the TrustWave root certificate is installed. Although the company acknowledged the fact of such issuance, and also noted that all measures had been taken to prevent such falsification from occurring, their root certificate was revoked by most OS and software products.

In case of such incidents, the main thing is the prompt revocation of root certificates . This is one of the shortcomings of SSL certificates: there is no mechanism to guarantee a quick revocation of a certificate. For a number of reasons, not all OS and software products always use the latest, most current lists of trusted root certificates. Even a difference in a matter of days can lead to undesirable consequences (the magnitude of the consequences are determined by the fact that the forged or more trusted certificate was issued for).

It should also be noted that manufacturers of some OS and software products (example: Microsoft in the case of Windows) can supplement the list of trusted certificates in the OS repository without explicitly notifying the user.

Software errors when using certificates

One of the most unpleasant problems is the complete disregard for certificate errors when using a secure connection. The article “ The Most Dangerous Code in the World ” discusses typical techniques that are unsuitable from the point of view of practical information security, when certificate errors are simply ignored.

Another incident was the situation when Mozilla products began to consider invalid all self-signed certificates for which it was not possible to verify the authenticity on external services (such as OCSP servers). The result was the practical impossibility of using such products for local networks of companies, where their own CA and its root certificate were usually used.

Prospects for using SSL certificates

An PKI alternative based on the X.509 standard is unlikely to appear in the near future: the scope of the necessary actions for a global transition to new standards would be quite large. For the same reason, one should not expect significant overcoming of already known problems of the standard, such as the impossibility of promptly excluding the root certificate, or the time-consuming procedure for obtaining the certificate as a whole.

Almost all protocols and Internet networks are moving to a secure data transmission channel. As a result, the demand for SSL certificates will only increase. How viable will be the model OpenCA and Lets Encrypt , we can only guess.

In the meantime, a thorough verification of CA's reputation before purchasing a certificate from him is the most reliable way to ensure that you are not in trouble in this area, at least until the next update of any of the SSL / TSL products installed on your computer appears. And, of course, it makes sense to keep track of all OS updates and components, not to forget to be interested in their state from a security point of view.