The Internet Has Become a Little Safer – IETF Committee Approved TLS 1.3

After 4 years and 28 drafts, the Internet Engineering Council (IETF) approved the updated TLS 1.3 protocol. Next, we will tell you what is the reason for the long approval of the protocol, and let’s talk about its features

Why so long

Approval of the new version of the protocol took so long, as the update caused some companies, in particular banks, fears. TLS 1.3 does not allow decrypting passing traffic on the network since the architecture of the new protocol uses ephemeral keys instead of static ones. Banks need to analyze traffic in order to ensure the transparency of connections: the data center for financial institutions usually obeys certain requirements (for example, the requirements of the PCI DSS standard).

In order to be able to track traffic, some operators proposed to build a kind of “backdoor” in the protocol: to implement the static Diffie-Hellman protocol. Discussion of this issue delayed the approval of TLS. Note that the initiative was still rejected.

• The first reason for the refusal is that using the static Diffie-Hellman protocol will allow you to listen to the network, and this is a violation of RFC 2804 IETF Policy on Wiretapping.
• The second reason is the unwillingness of the IETF working groups to standardize support for weak encryption in the new protocol. As history shows, the use of weak encryption algorithms, for example, export class RSA ciphers, can lead to such attacks as a man-in-the-middle. Therefore, the IETF did not agree to use less secure versions of TLS, even if this would complicate the work of network providers.

On the way, TLS 1.3, the case with Chromebooks also arose. In January 2017, Google introduced the release of Chrome 56 with support for TLS 1.3, available for devices on Linux, macOS, Windows, Android, and iOS. But after Chrome updated to the new version, Chromebooks and Windows PCs in Montgomery County, United States, could not connect to the network.

Later it became clear that the cause of the failure was the security tool Blue Coat 6.5. He “hung” the system, if Chrome installed a connection on TLS 1.3 because the developers did not follow the specifications of Google. As a result, the IT giant temporarily suspended the implementation of the protocol.

Main features of TLS 1.3

In TLS 1.3, developers made several significant changes, compared to the previous version of the protocol.

Changed the procedure of “handshake”

When using TLS 1.2, the connection establishment process takes place in several stages:

1. First, the client accesses the server and offers a number of encryption systems with which it can work.
2. The server responds to the client, tells which encryption system it will use, and sends the encryption key.
3. The client receives a key and uses it to encrypt and send a random sequence of characters.
4. Next, 2 new keys are created: the master key (stronger) and the session key (weaker).
5. Next, the client tells what encryption system it plans to use for the session key.
   Finally, the server approves the encryption system and begins the exchange of data.

TLS 1.3 doubles the process by combining several steps, shortening the time before the exchange of information begins. The sequence is as follows:

• The client tells the server about the encryption systems with which it can work.
• The server approves the system and sends its key.
• The client provides session keys.

At the same time, the mechanism itself became more secure, since the developers removed all algorithms that do not use AEAD-modes of block encryption. At the same time, in the structure of typical encryption sets, the authentication and key exchange mechanisms were “separated” from the write protection algorithm and the hash function for HMAC.

Implemented forward secrecy

This innovation does not allow attackers to use the copied keys of one session to decrypt other data. Even if the master key is compromised, the session keys will not be cracked.

Added 0-RTT mode

The mode in which the server and the client can establish a connection using the old keys if they already exchanged packages. Such an approach will shorten the time to start receiving/transmitting data.

• However, in this case, the client (for example, the browser) does not establish a secure channel with the server, but simply sends a request. At the same time, attackers can intercept the packet and, if desired, forge it. Therefore, the protocol specification separately considers replay attacks (Replay Attacks), which are implemented by recording and subsequent sending of previously sent correct messages, and ways to counter them.

It is important to remember here that the server is responsible for implementing protection from such attacks, therefore the IETF document places special emphasis on security mechanisms that would counteract the activities of intruders. The proposed approaches are available on the link.

A description of other functions and features of the standard can be found here.

Related posts:

Detecting An Attacks on Active Directory with Azure Any Internet Company Is Obliged To Secretly Change The Program Code At The Request Of The Authorities Do You Think Is That Possible That The Internet Could Be Destroyed At The Bottom or What Threatens Underwater Internet Cables