Now officially: TLS 1.3 is recognized as standard
Earlier, we wrote that the Internet Engineering Council (IETF) approved a new version of TLS - 1.3. Last week, the protocol was recognized as a standard. Today - let's talk about its capabilities.
/ photo by Charles Dyer CC
Over the update of the protocol began to work in 2014. Unofficially, the work on TLS 1.3 ended in March of this year, but it took the engineers a few more months to conduct additional checks.
')
The creators claim that the final version of TLS 1.3 is more secure and productive: in its encryption algorithms, all the known (to date) vulnerabilities of TLS 1.2 are closed, and the process of “handshaking” is twice as fast as its predecessor. The developers also added forward secrecy and new features like 0-RTT.
TLS 1.3 made the largest number of significant changes in the entire history of the protocol. For this reason, some have even suggested calling it TLS 2.0.
Now that the new version of the TLS 1.3 protocol ( RFC 8446 ) is officially approved, it remains to implement it for all connections over the network.
TLS has a kind of backward compatibility. When a connection is established between the client and the server, the supported protocol versions are exchanged and the one that both parties can work with is selected. However, this feature is not used everywhere. With the advent of TLS 1.3, more than 3% of servers with TLS 1.2 support simply disconnected rather than sending the supported version number to the client.
A similar problem arose with intermediate nodes ( middlebox ). Due to the fact that TLS did not change much, things like firewalls, NAT and load balancers refused to work with the new version of the protocol.
This phenomenon engineers dubbed ossification (ossification). The fact that some developers do not use the flexibility of the protocol, the introduction of new implementations of it is difficult. As an analogy, industry participants give an example with an old door. If you do not touch it for a long time, the loops rust and it opens with a creak.
/ photo by Christopher Sessums CC
It turns out that the previous protocol is outdated, but it will not work to introduce a new one by default. More on the topic can be read, for example, in last year's study from IEEE ( PDF ).
David Benjamin, working on Chromium, found a solution to the problem. He proposed to mask the first message from a client that supports TLS 1.3, under the message TLS 1.2. And it worked: the aforementioned 3% of servers stopped disconnecting. For intermediary nodes, Kyle Nekritz of Facebook suggested using the same approach. This reduced the number of crashes by 6.5% in Chrome and by 2% in Firefox.
To check if middleboxes are compatible with the new version of the protocol, you can use the test developed in Cloudflare.
According to Eric Rescorla, one of the developers of specifications for TLS and HTTPS, it’s not so difficult to implement TLS 1.3 in general. Engineering Council tried to make this process as simple as possible. TLS 1.3 uses the same keys and certificates as TLS 1.2. This allows the client and server to automatically establish a TLS 1.3 connection if they both support the new version of the protocol.
In addition, there are a number of libraries that will help deploy the protocol faster. For example, at the beginning of last week, Facebook transferred its TLS 1.3 Fizz library to open source . Fizz reduces latency during data translation, as well as the load on the CPU.
The developers have prepared a guide on how to start using Fizz on Ubuntu 16.04 LTS. It is located in the official GitHub repository (there is also a guide for MacOS).
First you need to install the necessary dependencies of folly and libsodium :
Next you need to collect and install folly:
Then you can proceed to install Fizz:
In addition to Fizz, there are other libraries in the network, such as wolfSSL , GnuTLS or rustls .
In order to finally solve the problem of the “ossification” of the protocol, David Benjamin proposed in addition to the official version of the standard to use a number of its variations, which will be released every six weeks (along with releases of new versions of Chrome). Thus, servers and intermediate nodes will be required to comply with all the rules for establishing a connection, otherwise most of the clients will not be able to connect to the services.
Due to this, the developers hope to avoid possible failures of loading web pages, as well as similar problems with future versions of TLS.
It is expected that the overall security in the network after the introduction of TLS 1.3 will increase significantly. And libraries that will facilitate the deployment of a new version of the protocol will have to contribute to mass distribution.
PS Other materials from our corporate IaaS blog:
What we do in IT-GRAD - main areas:
Virtual Infrastructure (IaaS) | PCI DSS Hosting | Cloud FZ-152
/ photo by Charles Dyer CC
TLS 1.3 Features
Over the update of the protocol began to work in 2014. Unofficially, the work on TLS 1.3 ended in March of this year, but it took the engineers a few more months to conduct additional checks.
')
The creators claim that the final version of TLS 1.3 is more secure and productive: in its encryption algorithms, all the known (to date) vulnerabilities of TLS 1.2 are closed, and the process of “handshaking” is twice as fast as its predecessor. The developers also added forward secrecy and new features like 0-RTT.
TLS 1.3 made the largest number of significant changes in the entire history of the protocol. For this reason, some have even suggested calling it TLS 2.0.
Now that the new version of the TLS 1.3 protocol ( RFC 8446 ) is officially approved, it remains to implement it for all connections over the network.
Implementation difficulties
TLS has a kind of backward compatibility. When a connection is established between the client and the server, the supported protocol versions are exchanged and the one that both parties can work with is selected. However, this feature is not used everywhere. With the advent of TLS 1.3, more than 3% of servers with TLS 1.2 support simply disconnected rather than sending the supported version number to the client.
A similar problem arose with intermediate nodes ( middlebox ). Due to the fact that TLS did not change much, things like firewalls, NAT and load balancers refused to work with the new version of the protocol.
This phenomenon engineers dubbed ossification (ossification). The fact that some developers do not use the flexibility of the protocol, the introduction of new implementations of it is difficult. As an analogy, industry participants give an example with an old door. If you do not touch it for a long time, the loops rust and it opens with a creak.
/ photo by Christopher Sessums CC
It turns out that the previous protocol is outdated, but it will not work to introduce a new one by default. More on the topic can be read, for example, in last year's study from IEEE ( PDF ).
David Benjamin, working on Chromium, found a solution to the problem. He proposed to mask the first message from a client that supports TLS 1.3, under the message TLS 1.2. And it worked: the aforementioned 3% of servers stopped disconnecting. For intermediary nodes, Kyle Nekritz of Facebook suggested using the same approach. This reduced the number of crashes by 6.5% in Chrome and by 2% in Firefox.
To check if middleboxes are compatible with the new version of the protocol, you can use the test developed in Cloudflare.
How to simplify implementation
According to Eric Rescorla, one of the developers of specifications for TLS and HTTPS, it’s not so difficult to implement TLS 1.3 in general. Engineering Council tried to make this process as simple as possible. TLS 1.3 uses the same keys and certificates as TLS 1.2. This allows the client and server to automatically establish a TLS 1.3 connection if they both support the new version of the protocol.
In addition, there are a number of libraries that will help deploy the protocol faster. For example, at the beginning of last week, Facebook transferred its TLS 1.3 Fizz library to open source . Fizz reduces latency during data translation, as well as the load on the CPU.
The developers have prepared a guide on how to start using Fizz on Ubuntu 16.04 LTS. It is located in the official GitHub repository (there is also a guide for MacOS).
First you need to install the necessary dependencies of folly and libsodium :
sudo apt-get install \ g++ \ cmake \ libboost-all-dev \ libevent-dev \ libdouble-conversion-dev \ libgoogle-glog-dev \ libgflags-dev \ libiberty-dev \ liblz4-dev \ liblzma-dev \ libsnappy-dev \ make \ zlib1g-dev \ binutils-dev \ libjemalloc-dev \ libssl-dev \ pkg-config \ libsodium-dev Next you need to collect and install folly:
git clone https://github.com/facebook/folly mkdir folly/build_ && cd folly/build_ cmake configure .. make -j $(nproc) sudo make install Then you can proceed to install Fizz:
cd ../.. git clone https://github.com/facebookincubator/fizz mkdir fizz/build_ && cd fizz/build_ cmake configure ../fizz make -j $(nproc) sudo make install In addition to Fizz, there are other libraries in the network, such as wolfSSL , GnuTLS or rustls .
Future protocol
In order to finally solve the problem of the “ossification” of the protocol, David Benjamin proposed in addition to the official version of the standard to use a number of its variations, which will be released every six weeks (along with releases of new versions of Chrome). Thus, servers and intermediate nodes will be required to comply with all the rules for establishing a connection, otherwise most of the clients will not be able to connect to the services.
Due to this, the developers hope to avoid possible failures of loading web pages, as well as similar problems with future versions of TLS.
It is expected that the overall security in the network after the introduction of TLS 1.3 will increase significantly. And libraries that will facilitate the deployment of a new version of the protocol will have to contribute to mass distribution.
PS Other materials from our corporate IaaS blog:
- Cloud technologies in the financial sector: the experience of Russian companies
- What is behind the term vCloud Director - an inside view
- How to place 100% of the infrastructure in the cloud IaaS-provider and not regret it
What we do in IT-GRAD - main areas:
Virtual Infrastructure (IaaS) | PCI DSS Hosting | Cloud FZ-152
Source: https://habr.com/ru/post/420521/
All Articles