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

At the beginning of the year, in the report on the problems and availability of the Internet 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 data, we are finally ready to talk about the features of this transition.

The chairs of the IETF TLS working group write :
"In short, TLS 1.3 should provide the foundation for a safer and more efficient Internet for the next 20 years."
')
Development of TLS 1.3 took a long 10 years. At Qrator Labs, we, along with the rest of the industry, closely followed the process of creating a protocol from the original project. During this time, it took to write 28 consecutive versions of the draft in order that, in 2019, the world saw a balanced and easy-to-deploy protocol. Active support for TLS 1.3 by the market is already evident: the implementation of a proven and reliable security protocol meets the requirements of the times.

According to Eric Reskorly (Firefox Technical Director and sole author of TLS 1.3) in an interview with The Register :

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

In parallel, in the IETF TLS working group, the preparation of RFCs declaring old versions of TLS (with the exception of TLS 1.2 only) is obsolete and unusable. Most likely, the final RFC will see the light before the end of the summer. This is another signal from the IT industry: the encryption protocols should not be postponed.

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

What has changed in comparison with TLS 1.2?

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

TLS 1.3 includes certain technical advantages - such as a simplified handshake process for establishing 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 outdated and insecure encryption and hashing algorithms that are still allowed (although not recommended) should be used with earlier versions of TLS, including SHA-1, MD5, DES, 3DES, and AES-CBC, has been removed. at the same time adding support for new cipher suites. Other enhancements include more encrypted handshaking elements (for example, certificate information exchange is now encrypted) to reduce the number of prompts to a potential traffic interceptor, as well as improvements in forward secrecy when using certain key exchange modes, so the connection should remain at any time secure, even if the algorithms used to encrypt it are 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 , there were serious controversies in the IETF TLS working group. Even now it is 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 currently embedded in the protocol.

The reasons why this may be needed are set out in a document written by Steve Fenter . The 20-page paper mentions several examples where an enterprise may want to perform out-of-band traffic decryption (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 talk about regulatory requirements, our own product to neutralize applied DDoS attacks (including a solution that does not require disclosure of sensitive and / or confidential information) was created in 2012 with PFS, so our customers and partners will not have any changes in their infrastructure after the upgrade of the server-side TLS version was not required.

Also, since the introduction of the time, no problems related to 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 lies in the fact that usually the progress in the development of protocols in the IETF strongly depends on the results of scientific research, and the state of academic research in the industry of neutralizing distributed denial of service attacks is very poor.

For example, Section 4.4 of the IETF “QUIC Manageability” draft, which is part of the future QUIC protocol suite, can be a good example: it states that “modern methods of detecting and neutralizing [DDoS attacks] usually include passive measurement using data on network streams.

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

Similarly, we do not yet know how manufacturers of equipment for neutralizing 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 of the areas where development can begin is the SMART research group at the IRTF, where researchers can work with the industry to refine their own knowledge of the problem industry and to find new research directions. We are also ready to warmly welcome all researchers, if there are any, you can contact us for questions or suggestions related to DDoS research or to the SMART research team at rnd@qrator.net