What is TLS
This text is a free translation of this chapter of the remarkable book “High Performance Browser Networking” by Ilya Grigorik. The translation was done as part of writing a term paper, which is why it is very free, but it will nevertheless be useful to those who have little idea what TLS is and what they eat it with.
TLS (transport layer security) is based on SSL (Secure Sockets Layer), originally developed by Netscape to enhance e-commerce security on the Internet. SSL was implemented at the application-level, directly above TCP (Transmission Control Protocol), which allows higher-level protocols (such as HTTP or the e-mail protocol) to work without changes. If SSL is configured correctly, the third-party observer can only find out the connection parameters (for example, the type of encryption used), as well as the frequency of sending and the approximate amount of data, but cannot read and change them.
The specific place of TLS (SSL) in the stack of Internet protocols is shown in the diagram:
')
After the SSL protocol was standardized by the IETF (Internet Engineering Task Force), it was renamed TLS. Therefore, although the names SSL and TLS are interchangeable, they are still different, since each describes a different version of the protocol.
The first released version of the protocol was called SSL 2.0, but was rather quickly replaced with SSL 3.0 due to vulnerabilities discovered. As already mentioned, SSL was developed by Netscape, so in January 1999 the IETF openly standardized it under the name TLS 1.0. Then in April 2006, a version of TLS 1.1 was published, which expanded the original capabilities of the protocol and covered known vulnerabilities. The current protocol version is TLS 1.2, released in August 2008.
As already mentioned, TLS was designed to work on TCP, but a special version of TLS, known as Datagram Transport Layer Security (DTLS), was developed to work with datagram protocols such as UDP (User Datagram Protocol).
The TLS protocol is designed to provide three services to all applications working on it, namely: encryption, authentication and integrity. Technically, not all three can be used, but in practice, to ensure safety, as a rule, all three are used:
In order to establish a cryptographically secure data channel, the connection nodes must agree on the encryption methods and keys used. The TLS protocol uniquely identifies this procedure, more is discussed in paragraph TLS Handshake. It should be noted that TLS uses public key cryptography, which allows nodes to establish a shared secret encryption key without any prior knowledge of each other.
Also in the framework of the TLS Handshake procedure, it is possible to establish the authenticity of the identity of the client and the server. For example, a client can be sure that the server that provides him with information about a bank account is really a bank server. And vice versa: the company's server can be sure that the client who connects to it is an employee of the company, and not an outsider (this mechanism is called Chain of Trust and will be discussed in the appropriate section).
Finally, TLS sends each message with a Message Authentication Code (MAC) code, whose creation algorithm is a one-way cryptographic hashing function (actually a checksum), the keys of which are known to both communication participants. Whenever a message is sent, its MAC value is generated, which can be generated by the receiver as well, this ensures the integrity of the information and protection against its substitution.
Thus, all three mechanisms underlying the cryptosecurity of the TLS protocol are briefly considered.
Before starting data exchange via TLS, the client and server must agree on the connection parameters, namely: the version of the protocol used, the method of data encryption, and check the certificates, if necessary. The scheme of starting the connection is called TLS Handshake and is shown in the figure:
Let us examine in more detail each step of this procedure:
Clearly, establishing a TLS connection is, generally speaking, a lengthy and time consuming process, so there are several optimizations in the TLS standard. In particular, there is a procedure called “abbreviated handshake”, which allows you to use previously agreed parameters to reconnect (of course, if the client and server have established a TLS connection in the past). This procedure is discussed in more detail in the item “Resumption of the session”.
There is also an additional extension of the Handshake procedure, which is called TLS False Start. This extension allows the client and server to begin exchanging encrypted data immediately after the encryption method is established, which reduces the connection establishment by one iteration of messages. This is discussed in more detail in “TLS False Start”.
For various historical and commercial reasons, TLS uses RSA key exchange most often: the client generates a symmetric key, signs it with the server's public key and sends it to the server. In turn, the client's key on the server is decrypted using the private key. After this, the key exchange is declared complete. This algorithm has one drawback: the same pair of public and private keys is also used for server authentication. Accordingly, if an attacker gains access to the server's private key, he can decrypt the entire communication session. Moreover, an attacker can simply record the entire communication session in an encrypted version and take the decryption later when it is possible to get the server's private key. At the same time, Diffie-Hellman key exchange seems to be more secure, since the installed symmetric key never leaves the client or server and, accordingly, cannot be intercepted by the attacker, even if he knows the server's private key. The service to reduce the risk of compromising past communication sessions is based on this: for each new communication session, a new, so-called “temporary” symmetric key is created. Accordingly, even in the worst case (if the attacker knows the server's private key), the attacker can only get the keys from future sessions, but not decrypt the previously recorded ones.
At the moment, all browsers, when establishing a TLS connection, prefer the combination of the Diffie-Hellman algorithm and the use of temporary keys to increase the security of the connection.
Once again, public key encryption is used only in the TLS Handshake procedure during initial connection setup. After the tunnel is configured, symmetric cryptography comes into play, and the communication within the current session is encrypted with the specified symmetric keys. This is necessary to increase performance, since public key cryptography requires significantly more computational power.
As noted earlier, the complete TLS Handshake procedure is quite lengthy and expensive in terms of computational overhead. Therefore, a procedure was developed that allows you to resume a previously interrupted connection on the basis of already configured data.
Starting with the first public version of the protocol (SSL 2.0), the server within TLS Handshake (namely, the initial ServerHello message) can generate and send a 32-byte session identifier. Naturally, in this case, the server stores a cache of generated identifiers and session parameters for each client. In turn, the client stores the ID sent and includes it (of course, if it exists) in the initial message of the ClientHello. If both the client and the server have identical session identifiers, then the establishment of a common connection occurs using the simplified algorithm shown in the figure. If not, the full version of TLS Handshake is required.
The session renewal procedure allows you to skip the generation of a symmetric key, which significantly increases the connection setup time, but does not affect its security, as previously uncompromised data from the previous session is used.
However, there is a practical limitation: since the server must store data about all open sessions, this leads to a problem with popular resources that are simultaneously requested by thousands and millions of clients.
To circumvent this problem, a “Session Ticket” mechanism was developed that eliminates the need to save each client’s data on the server. If the client during the initial connection setup indicated that it supports this technology, then the server during the TLS Handshake sends the client the so-called Session Ticket — session parameters encrypted with the server's private key. The next time the session is resumed, the client sends a Session Ticket along with ClientHello. Thus, the server is free from the need to store data about each connection, but the connection is still safe, since the Session Ticket is encrypted with a key known only on the server.
The session resume technology undoubtedly improves protocol performance and reduces computational costs, but it is not applicable in the initial connection to the server, or in the case when the previous session has already expired.
To get even more speed, TLS False Start technology was developed, which is an optional protocol extension and allows you to send data when TLS Handshake is only partially completed. The detailed TLS False Start scheme is shown in the figure:
It is important to note that TLS False Start does not alter the TLS Handshake procedure. It is based on the assumption that at that moment when the client and the server already know about the connection parameters and symmetric keys, application data can already be sent, and all the necessary checks can be carried out in parallel. As a result, the connection is ready to use one messaging iteration earlier.
Authentication is an integral part of every TLS connection. Consider the simplest authentication process between Alice and Bob:
Obviously, this scheme is built on trust between Alice and Bob. It is assumed that the exchange of public keys occurred, for example, during a personal meeting, and thus Alice is confident that she received the key directly from Bob, and Bob, in turn, is sure that she received Alice’s public key.
Suppose now that Alice receives a message from Charlie, with whom she is not familiar, but who claims to be friends with Bob. To prove this, Charlie asked him to sign his own public key with Bob's private key in advance, and he attached this signature to Alice’s message. Alice first checks Bob’s signature on Charlie’s key (she’s able to do this, because Bob’s public key is already known to her), makes sure Charlie is really Bob’s friend, accepts his message and performs an already known integrity check, making sure that the message is really from Charlie :
The one described in the previous paragraph is the creation of a “chain of trust” (or “Chain of trust”, if in English).
In the TLS protocol, trust chain data is based on certificates of authenticity provided by special bodies, called certificate authorities (CA). Certificate authorities make checks and, if the issued certificate is compromised, this certificate is revoked.
From the certificates issued is formed already considered a chain of trust. Its root is the so-called “Root CA certificate” - a certificate signed by a large center, the credibility of which is indisputable. In general, the chain of trust looks like this:
Naturally, there are cases when an already issued certificate must be revoked or revoked (for example, the certificate’s private key was compromised, or the entire certification procedure was compromised). To do this, certificates of authenticity contain special instructions on checking their relevance. Therefore, when building a chain of trust, it is necessary to check the relevance of each trust node.
The mechanism of this check is simple and it is based on the so-called. “Certificate Revocation List” (CRL - “Certificate Revocation List”). Each certification authority has this list, which is a simple list of the serial numbers of revoked certificates. Accordingly, anyone who wants to verify the authenticity of the certificate simply downloads this list and searches for the certificate number to be checked. If the number is found - it means that the certificate is revoked.
There is obviously some technical irrationality: to check only one certificate, it is required to request the entire list of revoked certificates, which results in slowing down. To combat this, a mechanism called the Certificate Certificate Status Protocol (OCSP - Online Certificate Status Protocol) was developed. It allows you to check certificate status dynamically. Naturally, this reduces the load on the network bandwidth, but at the same time raises several problems:
Actually, in all modern browsers both solutions (OCSP and CRL) complement each other, moreover, as a rule, it is possible to customize the preferred policy for checking the status of a certificate.
Thus, this article discusses all the key tools provided by the TLS protocol to protect information. For some ad-libbing in the article I apologize, this is the cost of the original purpose of the translation.
TLS Overview
TLS (transport layer security) is based on SSL (Secure Sockets Layer), originally developed by Netscape to enhance e-commerce security on the Internet. SSL was implemented at the application-level, directly above TCP (Transmission Control Protocol), which allows higher-level protocols (such as HTTP or the e-mail protocol) to work without changes. If SSL is configured correctly, the third-party observer can only find out the connection parameters (for example, the type of encryption used), as well as the frequency of sending and the approximate amount of data, but cannot read and change them.
The specific place of TLS (SSL) in the stack of Internet protocols is shown in the diagram:
')
After the SSL protocol was standardized by the IETF (Internet Engineering Task Force), it was renamed TLS. Therefore, although the names SSL and TLS are interchangeable, they are still different, since each describes a different version of the protocol.
The first released version of the protocol was called SSL 2.0, but was rather quickly replaced with SSL 3.0 due to vulnerabilities discovered. As already mentioned, SSL was developed by Netscape, so in January 1999 the IETF openly standardized it under the name TLS 1.0. Then in April 2006, a version of TLS 1.1 was published, which expanded the original capabilities of the protocol and covered known vulnerabilities. The current protocol version is TLS 1.2, released in August 2008.
As already mentioned, TLS was designed to work on TCP, but a special version of TLS, known as Datagram Transport Layer Security (DTLS), was developed to work with datagram protocols such as UDP (User Datagram Protocol).
Encryption, authentication and integrity
The TLS protocol is designed to provide three services to all applications working on it, namely: encryption, authentication and integrity. Technically, not all three can be used, but in practice, to ensure safety, as a rule, all three are used:
- Encryption is the concealment of information transmitted from one computer to another;
- Authentication - verification of the authorship of the transmitted information;
- Integrity - the detection of falsification of information.
In order to establish a cryptographically secure data channel, the connection nodes must agree on the encryption methods and keys used. The TLS protocol uniquely identifies this procedure, more is discussed in paragraph TLS Handshake. It should be noted that TLS uses public key cryptography, which allows nodes to establish a shared secret encryption key without any prior knowledge of each other.
Also in the framework of the TLS Handshake procedure, it is possible to establish the authenticity of the identity of the client and the server. For example, a client can be sure that the server that provides him with information about a bank account is really a bank server. And vice versa: the company's server can be sure that the client who connects to it is an employee of the company, and not an outsider (this mechanism is called Chain of Trust and will be discussed in the appropriate section).
Finally, TLS sends each message with a Message Authentication Code (MAC) code, whose creation algorithm is a one-way cryptographic hashing function (actually a checksum), the keys of which are known to both communication participants. Whenever a message is sent, its MAC value is generated, which can be generated by the receiver as well, this ensures the integrity of the information and protection against its substitution.
Thus, all three mechanisms underlying the cryptosecurity of the TLS protocol are briefly considered.
Tls handshake
Before starting data exchange via TLS, the client and server must agree on the connection parameters, namely: the version of the protocol used, the method of data encryption, and check the certificates, if necessary. The scheme of starting the connection is called TLS Handshake and is shown in the figure:
Let us examine in more detail each step of this procedure:
- Since TLS is working on TCP, a TCP connection is first established between the client and the server.
- After installing TCP, the client sends the specification to the server in plain text (namely, the version of the protocol that it wants to use, supported encryption methods, etc).
- The server approves the version of the protocol used, selects an encryption method from the provided list, attaches its certificate and sends a response to the client (if desired, the server can also request a client certificate).
- The protocol version and encryption method are currently considered approved, the client checks the certificate sent and initiates either RSA or Diffie-Hellman key exchange, depending on the parameters set.
- The server processes the message sent by the client, verifies the MAC, and sends the client a final ('Finished') message in encrypted form.
- The client decrypts the received message, verifies the MAC, and if everything is good, the connection is considered established and the application data exchange begins.
Clearly, establishing a TLS connection is, generally speaking, a lengthy and time consuming process, so there are several optimizations in the TLS standard. In particular, there is a procedure called “abbreviated handshake”, which allows you to use previously agreed parameters to reconnect (of course, if the client and server have established a TLS connection in the past). This procedure is discussed in more detail in the item “Resumption of the session”.
There is also an additional extension of the Handshake procedure, which is called TLS False Start. This extension allows the client and server to begin exchanging encrypted data immediately after the encryption method is established, which reduces the connection establishment by one iteration of messages. This is discussed in more detail in “TLS False Start”.
TLS key exchange
For various historical and commercial reasons, TLS uses RSA key exchange most often: the client generates a symmetric key, signs it with the server's public key and sends it to the server. In turn, the client's key on the server is decrypted using the private key. After this, the key exchange is declared complete. This algorithm has one drawback: the same pair of public and private keys is also used for server authentication. Accordingly, if an attacker gains access to the server's private key, he can decrypt the entire communication session. Moreover, an attacker can simply record the entire communication session in an encrypted version and take the decryption later when it is possible to get the server's private key. At the same time, Diffie-Hellman key exchange seems to be more secure, since the installed symmetric key never leaves the client or server and, accordingly, cannot be intercepted by the attacker, even if he knows the server's private key. The service to reduce the risk of compromising past communication sessions is based on this: for each new communication session, a new, so-called “temporary” symmetric key is created. Accordingly, even in the worst case (if the attacker knows the server's private key), the attacker can only get the keys from future sessions, but not decrypt the previously recorded ones.
At the moment, all browsers, when establishing a TLS connection, prefer the combination of the Diffie-Hellman algorithm and the use of temporary keys to increase the security of the connection.
Once again, public key encryption is used only in the TLS Handshake procedure during initial connection setup. After the tunnel is configured, symmetric cryptography comes into play, and the communication within the current session is encrypted with the specified symmetric keys. This is necessary to increase performance, since public key cryptography requires significantly more computational power.
Resuming TLS Session
As noted earlier, the complete TLS Handshake procedure is quite lengthy and expensive in terms of computational overhead. Therefore, a procedure was developed that allows you to resume a previously interrupted connection on the basis of already configured data.
Starting with the first public version of the protocol (SSL 2.0), the server within TLS Handshake (namely, the initial ServerHello message) can generate and send a 32-byte session identifier. Naturally, in this case, the server stores a cache of generated identifiers and session parameters for each client. In turn, the client stores the ID sent and includes it (of course, if it exists) in the initial message of the ClientHello. If both the client and the server have identical session identifiers, then the establishment of a common connection occurs using the simplified algorithm shown in the figure. If not, the full version of TLS Handshake is required.
The session renewal procedure allows you to skip the generation of a symmetric key, which significantly increases the connection setup time, but does not affect its security, as previously uncompromised data from the previous session is used.
However, there is a practical limitation: since the server must store data about all open sessions, this leads to a problem with popular resources that are simultaneously requested by thousands and millions of clients.
To circumvent this problem, a “Session Ticket” mechanism was developed that eliminates the need to save each client’s data on the server. If the client during the initial connection setup indicated that it supports this technology, then the server during the TLS Handshake sends the client the so-called Session Ticket — session parameters encrypted with the server's private key. The next time the session is resumed, the client sends a Session Ticket along with ClientHello. Thus, the server is free from the need to store data about each connection, but the connection is still safe, since the Session Ticket is encrypted with a key known only on the server.
TLS False Start
The session resume technology undoubtedly improves protocol performance and reduces computational costs, but it is not applicable in the initial connection to the server, or in the case when the previous session has already expired.
To get even more speed, TLS False Start technology was developed, which is an optional protocol extension and allows you to send data when TLS Handshake is only partially completed. The detailed TLS False Start scheme is shown in the figure:
It is important to note that TLS False Start does not alter the TLS Handshake procedure. It is based on the assumption that at that moment when the client and the server already know about the connection parameters and symmetric keys, application data can already be sent, and all the necessary checks can be carried out in parallel. As a result, the connection is ready to use one messaging iteration earlier.
TLS Chain of trust
Authentication is an integral part of every TLS connection. Consider the simplest authentication process between Alice and Bob:
- Both Alice and Bob generate their own public and private keys.
- Alice and Bob exchange public keys.
- Alice generates a message, encrypts it with her private key and sends it to Bob.
- Bob uses the key received from Alice to decrypt the message and thus verifies the authenticity of the received message.
Obviously, this scheme is built on trust between Alice and Bob. It is assumed that the exchange of public keys occurred, for example, during a personal meeting, and thus Alice is confident that she received the key directly from Bob, and Bob, in turn, is sure that she received Alice’s public key.
Suppose now that Alice receives a message from Charlie, with whom she is not familiar, but who claims to be friends with Bob. To prove this, Charlie asked him to sign his own public key with Bob's private key in advance, and he attached this signature to Alice’s message. Alice first checks Bob’s signature on Charlie’s key (she’s able to do this, because Bob’s public key is already known to her), makes sure Charlie is really Bob’s friend, accepts his message and performs an already known integrity check, making sure that the message is really from Charlie :
The one described in the previous paragraph is the creation of a “chain of trust” (or “Chain of trust”, if in English).
In the TLS protocol, trust chain data is based on certificates of authenticity provided by special bodies, called certificate authorities (CA). Certificate authorities make checks and, if the issued certificate is compromised, this certificate is revoked.
From the certificates issued is formed already considered a chain of trust. Its root is the so-called “Root CA certificate” - a certificate signed by a large center, the credibility of which is indisputable. In general, the chain of trust looks like this:
Naturally, there are cases when an already issued certificate must be revoked or revoked (for example, the certificate’s private key was compromised, or the entire certification procedure was compromised). To do this, certificates of authenticity contain special instructions on checking their relevance. Therefore, when building a chain of trust, it is necessary to check the relevance of each trust node.
The mechanism of this check is simple and it is based on the so-called. “Certificate Revocation List” (CRL - “Certificate Revocation List”). Each certification authority has this list, which is a simple list of the serial numbers of revoked certificates. Accordingly, anyone who wants to verify the authenticity of the certificate simply downloads this list and searches for the certificate number to be checked. If the number is found - it means that the certificate is revoked.
There is obviously some technical irrationality: to check only one certificate, it is required to request the entire list of revoked certificates, which results in slowing down. To combat this, a mechanism called the Certificate Certificate Status Protocol (OCSP - Online Certificate Status Protocol) was developed. It allows you to check certificate status dynamically. Naturally, this reduces the load on the network bandwidth, but at the same time raises several problems:
- Certificate authorities must handle real-time workloads;
- Certificate authorities must ensure their availability at all times;
- Because of real-time requests, certificate authorities receive information about which sites each user has visited.
Actually, in all modern browsers both solutions (OCSP and CRL) complement each other, moreover, as a rule, it is possible to customize the preferred policy for checking the status of a certificate.
Thus, this article discusses all the key tools provided by the TLS protocol to protect information. For some ad-libbing in the article I apologize, this is the cost of the original purpose of the translation.
Source: https://habr.com/ru/post/258285/
All Articles