April 2, 2018 at 16:27“The Internet has become a little safer”: IETF approves TLS 1.3
After 4 years and 28 drafts, the Internet Engineering Council (IETF) approved the updated TLS 1.3 protocol. Next, we will explain the reason for the long approval of the protocol, and talk about its features. / photo Solo se puede CC
The approval of the new version of the protocol took so much time, as the update caused concern in some companies, in particular, banks. TLS 1.3 does not allow to decrypt the passing traffic on the network, since the architecture of the new protocol uses ephemeral keys instead of static ones . Banks need to analyze traffic to ensure the transparency of connections: the data center for financial institutions is usually subject to certain requirements (for example, PCI DSS ).
In order to be able to track traffic, some operators proposed to build a kind of “backdoor” into the protocol: introduce a static protocolDiffie - Hellman. Discussion of this issue has delayed TLS approval. Note that the initiative was rejected.
The first reason for the failure is that using the Diffie-Hellman static protocol will allow you to listen on the network, which is a violation of RFC 2804 IETF Policy on Wiretapping.
The second reason is that the IETF working groups are not ready to standardize weak encryption support in the new protocol. History shows that using weak encryption algorithms such as export-grade RSA ciphers can lead to attacks such as man-in-the-middle. Therefore, the IETF did not agree to deploy less secure versions of TLS, even if this would complicate the work of network providers.
TLS 1.3 also stood in the wayThe case of the Chromebooks. In January 2017, Google introduced the Chrome 56 release with support for TLS 1.3, available for devices on Linux, macOS, Windows, Android, and iOS. But after upgrading Chrome to the new version, Chromebooks and Windows PCs in the schools of Montgomery County, USA, could not connect to the network.
It was later revealed that the cause of the failure was the Blue Coat 6.5 security tool. He “hung up” the system if Chrome established a connection using TLS 1.3, since the developers did not fully follow the specifications of Google. As a result, the IT giant temporarily suspended the implementation of the protocol.
/ photo Jack-Benny Persson CC
In TLS 1.3, the developers made several significant changes compared to the previous version of the protocol.
When using TLS 1.2, the process of establishing a connection proceeds in several stages:
TLS 1.3 speeds up the whole process by 2 times by combining several steps, reducing the time before the exchange of information begins. The sequence is as follows:
At the same time, the mechanism itself has become more secure, since the developers have removed all the algorithms that do not use the AEAD modes of block encryption . Moreover, in the structure of typical cipher suites, authentication and key exchange mechanisms were “separated” from the write protection algorithm and hash functions for HMAC .
This innovation will not allow attackers to use the copied keys of one session to decrypt other data. Even if the master key is compromised, session keys will not be cracked.
The mode in which the server and the client can establish a connection using the old keys if they have already exchanged packets. This approach will reduce the time before the start of data reception and transmission.
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, fake it. Therefore, in the protocol specification separately considered attack the repeat ( Replay Attacks ), which are realized by recording and subsequent sending previously sent valid messages, and methods of countering them.
It is important to remember here that the server is responsible for implementing protection against such attacks, therefore, the IETF document places special emphasis on protection mechanisms that would counteract the activities of attackers. The proposed approaches can be found here .
A description of other functions and features of the standard can be found here .
PS A few articles from the First Corporate IaaS Blog:
PPS A selection of articles from the blog "IT-GRAD" on Habré:
Why so long
The approval of the new version of the protocol took so much time, as the update caused concern in some companies, in particular, banks. TLS 1.3 does not allow to decrypt the passing traffic on the network, since the architecture of the new protocol uses ephemeral keys instead of static ones . Banks need to analyze traffic to ensure the transparency of connections: the data center for financial institutions is usually subject to certain requirements (for example, PCI DSS ).
In order to be able to track traffic, some operators proposed to build a kind of “backdoor” into the protocol: introduce a static protocolDiffie - Hellman. Discussion of this issue has delayed TLS approval. Note that the initiative was rejected.
The first reason for the failure is that using the Diffie-Hellman static protocol will allow you to listen on the network, which is a violation of RFC 2804 IETF Policy on Wiretapping.
The second reason is that the IETF working groups are not ready to standardize weak encryption support in the new protocol. History shows that using weak encryption algorithms such as export-grade RSA ciphers can lead to attacks such as man-in-the-middle. Therefore, the IETF did not agree to deploy less secure versions of TLS, even if this would complicate the work of network providers.
TLS 1.3 also stood in the wayThe case of the Chromebooks. In January 2017, Google introduced the Chrome 56 release with support for TLS 1.3, available for devices on Linux, macOS, Windows, Android, and iOS. But after upgrading Chrome to the new version, Chromebooks and Windows PCs in the schools of Montgomery County, USA, could not connect to the network.
It was later revealed that the cause of the failure was the Blue Coat 6.5 security tool. He “hung up” the system if Chrome established a connection using TLS 1.3, since the developers did not fully follow the specifications of Google. As a result, the IT giant temporarily suspended the implementation of the protocol.
/ photo Jack-Benny Persson CC
Key Features of TLS 1.3
In TLS 1.3, the developers made several significant changes compared to the previous version of the protocol.
Changed the handshake procedure
When using TLS 1.2, the process of establishing a connection proceeds in several stages:
- First, the client accesses the server and offers a number of encryption systems with which it can work.
- The server responds to the client, reports which encryption system it will use, and sends the encryption key.
- The client receives the key and uses it to encrypt and send a random sequence of characters.
- Next, 2 new keys are created: the master key (stronger) and the session key (weaker).
- Further, the client reports which encryption system he plans to use for the session key.
- Finally, the server approves the encryption system and data exchange begins.
TLS 1.3 speeds up the whole process by 2 times by combining several steps, reducing the time before the exchange of information begins. The sequence is as follows:
- The client informs the server about the encryption systems with which it can work.
- The server approves the system and transfers its key.
- The client provides session keys.
At the same time, the mechanism itself has become more secure, since the developers have removed all the algorithms that do not use the AEAD modes of block encryption . Moreover, in the structure of typical cipher suites, authentication and key exchange mechanisms were “separated” from the write protection algorithm and hash functions for HMAC .
Implemented forward secrecy
This innovation will not allow attackers to use the copied keys of one session to decrypt other data. Even if the master key is compromised, 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 have already exchanged packets. This approach will reduce the time before the start of data reception and transmission.
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, fake it. Therefore, in the protocol specification separately considered attack the repeat ( Replay Attacks ), which are realized by recording and subsequent sending previously sent valid messages, and methods of countering them.
It is important to remember here that the server is responsible for implementing protection against such attacks, therefore, the IETF document places special emphasis on protection mechanisms that would counteract the activities of attackers. The proposed approaches can be found here .
A description of other functions and features of the standard can be found here .
PS A few articles from the First Corporate IaaS Blog:
- Features of two-factor authentication: does it work in the IaaS cloud
- State systems in the cloud: placement features
- Personal data protection: a European approach
PPS A selection of articles from the blog "IT-GRAD" on Habré: