Now officially: TLS 1.3 is recognized as standard
Earlier we wrote that the Internet Engineering Council (IETF) approved the 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 protocol is 1.3 (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 to 3% of the server with support for TLS 1.2 just tore connection instead of sending client supports the version number.
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 generally not so difficult to implement TLS 1.3. 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, for example, wolfSSL , GnuTLS or rustls .
In order to finally solve the problem of the “ossification” of the protocol, David Benjamin proposed to use in addition to the official version of the standard 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 would simplify the deployment of a new version of the protocol should 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 protocol is 1.3 (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 to 3% of the server with support for TLS 1.2 just tore connection instead of sending client supports the version number.
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 generally not so difficult to implement TLS 1.3. 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, for example, wolfSSL , GnuTLS or rustls .
Future protocol
In order to finally solve the problem of the “ossification” of the protocol, David Benjamin proposed to use in addition to the official version of the standard 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 would simplify the deployment of a new version of the protocol should 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 hidden 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