"The Internet has become a bit safer": IETF 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 explain the reason for the lengthy 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, since the update caused concerns to some companies, in particular, banks. 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 to ensure connectivity transparency: a data center for financial institutions usually obeys certain requirements (for example, PCI DSS requirements).
')
In order to be able to track the traffic, some operators suggested embedding a kind of “backdoor” into the protocol: implement the Diffie - Hellman static protocol . Discussion of this issue has delayed TLS approval. Note that the initiative was rejected.
The first reason for the failure is that the use of the Diffie-Hellman static protocol will allow you to listen on the network, and this is a violation of RFC 2804 IETF Policy on Wiretapping.
The second reason is the failure of the IETF working groups to standardize weak encryption support in the new protocol. As history shows, the use of weak encryption algorithms, such as RSA export-class ciphers, can lead to such attacks as man-in-the-middle. Therefore, the IETF did not agree to use less secure versions of TLS, even if it complicates the work of network providers.
On the way TLS 1.3 also got a chance with Chrombuki. In January 2017, Google introduced the release of Chrome 56 with TLS 1.3 support, available for devices on Linux, macOS, Windows, Android and iOS. But after upgrading Chrome to the new version, Hrombuki and Windows PCs in schools in Montgomery County, USA, could not connect to the network.
Later it turned out that the cause of the failure was the security tool Blue Coat 6.5. He “hung up” the system if Chrome established a connection using TLS 1.3, as the developers didn’t fully follow Google’s specifications. As a result, the IT giant has temporarily suspended the implementation of the protocol.
/ photo by 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 goes through several stages:
TLS 1.3 speeds up the entire process by 2 times by combining several steps, reducing the time to the start of information sharing. The sequence is as follows:
In this case, the mechanism itself has become more secure, since the developers have deleted all the algorithms that do not use AEAD-modes of block encryption . At the same time, in the structure of typical encryption sets, 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, the 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 to start receiving and 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. In this case, attackers can intercept the package and, if desired, forge it. Therefore, the protocol specification specifically considers replay attacks ( Replay Attacks ), which are implemented by recording and then sending the previously sent correct messages, and ways to counter them.
Here it is important to remember that the server bears responsibility for implementing protection against such attacks, so the IETF document places special emphasis on defense mechanisms that would counteract the activities of intruders. The proposed approaches can be found at the link .
Description of other functions and features of the standard can be found here .
PS Several materials from the First Corporate IaaS blog:
PPS Selection of articles from the blog "IT-GRAD" on Habré:
/ photo Solo se puede CC
Why so long
The approval of the new version of the protocol took so much time, since the update caused concerns to some companies, in particular, banks. 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 to ensure connectivity transparency: a data center for financial institutions usually obeys certain requirements (for example, PCI DSS requirements).
')
In order to be able to track the traffic, some operators suggested embedding a kind of “backdoor” into the protocol: implement the Diffie - Hellman static protocol . Discussion of this issue has delayed TLS approval. Note that the initiative was rejected.
The first reason for the failure is that the use of the Diffie-Hellman static protocol will allow you to listen on the network, and this is a violation of RFC 2804 IETF Policy on Wiretapping.
The second reason is the failure of the IETF working groups to standardize weak encryption support in the new protocol. As history shows, the use of weak encryption algorithms, such as RSA export-class ciphers, can lead to such attacks as man-in-the-middle. Therefore, the IETF did not agree to use less secure versions of TLS, even if it complicates the work of network providers.
On the way TLS 1.3 also got a chance with Chrombuki. In January 2017, Google introduced the release of Chrome 56 with TLS 1.3 support, available for devices on Linux, macOS, Windows, Android and iOS. But after upgrading Chrome to the new version, Hrombuki and Windows PCs in schools in Montgomery County, USA, could not connect to the network.
Later it turned out that the cause of the failure was the security tool Blue Coat 6.5. He “hung up” the system if Chrome established a connection using TLS 1.3, as the developers didn’t fully follow Google’s specifications. As a result, the IT giant has temporarily suspended the implementation of the protocol.
/ photo by 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 goes through 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.
- Further 2 new keys are created: master key (stronger) and session key (weaker).
- Next, the client tells you what encryption system he plans to use for the session key.
- Finally, the server approves the encryption system and begins the exchange of data.
TLS 1.3 speeds up the entire process by 2 times by combining several steps, reducing the time to the start of information sharing. 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 transmits its key.
- The client provides session keys.
In this case, the mechanism itself has become more secure, since the developers have deleted all the algorithms that do not use AEAD-modes of block encryption . At the same time, in the structure of typical encryption sets, 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, 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 have already exchanged packets. This approach will reduce the time to start receiving and 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. In this case, attackers can intercept the package and, if desired, forge it. Therefore, the protocol specification specifically considers replay attacks ( Replay Attacks ), which are implemented by recording and then sending the previously sent correct messages, and ways to counter them.
Here it is important to remember that the server bears responsibility for implementing protection against such attacks, so the IETF document places special emphasis on defense mechanisms that would counteract the activities of intruders. The proposed approaches can be found at the link .
Description of other functions and features of the standard can be found here .
PS Several materials from the First Corporate IaaS blog:
- Features of two-factor authentication: does it work in the IaaS cloud
- Government Systems in the Cloud: Location Features
- Personal data protection: a European approach
PPS Selection of articles from the blog "IT-GRAD" on Habré:
Source: https://habr.com/ru/post/352668/
All Articles