We have included TLS 1.3. Why you should do the same

At the beginning of the year, in the report on problems and Internet accessibility for 2018-2019, we already wrote that the spread of TLS 1.3 is inevitable. Some time ago, we ourselves deployed version 1.3 of the Transport Layer Security protocol and, after collecting and analyzing the data, we are finally ready to talk about the features of this transition.

The chairpersons of the IETF TLS working group write :
“In short, TLS 1.3 should provide the foundation for a more secure and efficient Internet for the next 20 years.” TLS 1.3

developmenttook a long 10 years. We at Qrator Labs, along with the rest of the industry, have been closely following the process of creating the protocol from the initial project. During this time, it was necessary to write 28 consecutive versions of the draft so that in the end, in 2019, the world saw a balanced and easy-to-deploy protocol. The active support of TLS 1.3 by the market is already obvious: the implementation of a proven and reliable security protocol meets the requirements of the times.

According to Eric Rescorla (CTO of Firefox and sole author of TLS 1.3) in an interview with The Register :

“This is a complete replacement for TLS 1.2 using the same keys and certificates, so the client and server can automatically communicate over TLS 1.3 if both support it,” he said. “There is already good library support, and Chrome and Firefox include TLS 1.3 by default.”

In parallel, the IETF TLS working group is finalizing the preparation of an RFC that declares older versions of TLS (except for TLS 1.2 only) obsolete and unusable. Most likely, the final RFC will be released before the end of summer. This is another signal of the IT industry: updating encryption protocols should not be postponed.

A list of current implementations of TLS 1.3 is available on Github for anyone looking for the most suitable library: https://github.com/tlswg/tls13-spec/wiki/Implementations . Obviously, adopting and supporting the updated protocol will be - and is already underway - quick steps. Understanding how fundamental encryption has become in the modern world has spread quite widely.

What has changed compared to TLS 1.2?

From a note from the Internet Society :
“How does TLS 1.3 make the world a better place?”

TLS 1.3 includes certain technical advantages - such as a simplified handshake process to establish a secure connection - and also allows clients to resume sessions with servers faster. These measures are designed to reduce the connection setup delay and the number of failed connections on weak channels, which are often used as an excuse to provide only unencrypted HTTP connections.

Equally important, support for several legacy and insecure encryption and hash algorithms that are still allowed (although not recommended) to be used with earlier versions of TLS, including SHA-1, MD5, DES, 3DES and AES-CBC, is eliminated. while adding support for new cipher suites. Other enhancements include more encrypted handshake elements (for example, certificate information exchange is now encrypted) to reduce the amount of hints to a potential traffic interceptor, as well as improvements in forward secrecy when using certain key exchange modes, so that communication at all times should remain "safe, even if the algorithms used to encrypt it will be compromised in the future."

Development of modern protocols and DDoS

As you may have already read, during the development of the protocol and even after , serious contradictions arose in the IETF TLS working group . It is now obvious that individual enterprises (including financial institutions) will have to change the way they secure their own network in order to adapt to the perfect forward secrecy protocol that is now integrated into the protocol .

The reasons why this may be required are outlined in a paper written by Steve Fenter.. In a 20-page paper, several examples are mentioned when an enterprise may want to decrypt out-of-band traffic (which PFS does not allow) in order to monitor, comply with regulatory requirements or provide protection against DDoS attacks at the application level (L7).



Although we are definitely not ready to discuss regulatory requirements, our own product for neutralizing applied DDoS attacks (including a solution that does not require the disclosure of sensitive and / or confidential information) was created in 2012 with PFS in mind, so there are no changes to our clients and partners in After upgrading the server-side version of TLS, their infrastructure was not required.

Also, since the time of implementation, no problems associated with transport encryption have been identified. Officially: TLS 1.3 is ready for use in production.

However, there is still a problem associated with the development of next-generation protocols. It consists in the fact that usually the progress in the development of protocols in the IETF is highly dependent on the results of scientific research, and the state of academic research in the industry of neutralizing distributed denial of service attacks is very deplorable.

So, a good example is section 4.4.the IETF draft “QUIC Manageability”, which is part of the future QUIC protocol suite: it states that “modern methods for detecting and neutralizing [DDoS attacks] typically include passive measurement using network flow data.”

The latter, in fact, is very rare in real corporate environments (and only partially applicable to Internet providers), and in any case is hardly a “common case” in the real world - but it constantly appears in scientific publications, usually not supported by testing the entire spectrum of potential DDoS attacks, including application-level attacks. The latter, by virtue of at least the global deployment of TLS, obviously cannot be detected by the passive measurement of network packets and flows.

Similarly, we do not yet know how manufacturers of equipment for the neutralization of DDoS will adapt to the realities of TLS 1.3. Due to the technical complexity of supporting the out-of-band protocol, it may take some time to upgrade.

Setting the right goals for research is a major challenge for DDoS neutralization service providers. One area where development can begin is the SMART research team at IRTF, where researchers can work with the industry to refine their knowledge of the problem industry and find new research directions. We are also ready to warmly welcome all researchers, if there are any - you can contact us with questions or suggestions related to DDoS studies or with the SMART research group atrnd@qrator.net