At the beginning of the year, in the report on internet issues and availability for 2018-2019, , it was inevitable that TLS 1.3 would be adopted. Some time ago, we rolled out version 1.3 of the Transport Layer Security protocol and, after gathering and analyzing data, we are finally ready to discuss the features of this transition.
Chairs of the IETF TLS working group :
"In short, TLS 1.3 should provide the foundation for a more secure and efficient Internet for the next 20 years."
Development took a long 10 years. At Qrator Labs, along with the rest of the industry, we closely followed the protocol’s development from the initial draft. During this time, 28 consecutive draft versions were written until a balanced and deployable protocol saw the light of day in 2019. Active market support for TLS 1.3 is already evident: the implementation of this tested and reliable security protocol meets the demands of the times.
According to Eric Rescorla (Technical Director of Firefox and sole author of TLS 1.3), :
"It's a complete replacement for TLS 1.2, using the same keys and certificates, so that clients and servers can automatically communicate over TLS 1.3 if both support it," he said. "There is already good support at the library level, and Chrome and Firefox enable TLS 1.3 by default."
Simultaneously, the IETF TLS working group is finishing , declaring old versions of TLS (except for TLS 1.2) obsolete and unusable. The final RFC is likely to be published by the end of summer. This is yet another signal to 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: . It is clear that the adoption and support of the updated protocol will — and is already — happening rapidly. The understanding of how fundamental encryption has become in the modern world has spread widely.
What has changed compared to TLS 1.2?
From :
"How TLS 1.3 makes the world better?"
TLS 1.3 includes specific technical advantages, such as a simplified handshake process for establishing a secure connection, and allows clients to resume sessions with servers more quickly. These measures aim to reduce latency during connection establishment and the number of failed connections on weak channels, which are often used as justification for providing only unencrypted HTTP connections.
Equally important is the removal of support for multiple outdated and insecure encryption and hashing algorithms that are still permitted (though not recommended) for use with earlier versions of TLS, including SHA-1, MD5, DES, 3DES, and AES-CBC, while simultaneously adding support for new cipher suites. Other enhancements include more encrypted elements of the handshake (for example, certificate information exchange is now encrypted) to reduce cues for potential traffic interceptors, as well as improvements in forward secrecy when using certain key exchange modes, ensuring that communications remain secure at all times, even if the algorithms used for their encryption are compromised in the future.
Development of Modern Protocols and DDoS
As you may have already read, during the development of the protocol , in the IETF TLS working group . It is already clear that individual enterprises (including financial institutions) will need to change the way they secure their networks to adapt to the now-integrated .
Reasons why this may be necessary are outlined in a paper, . In the 20-page paper, several examples are mentioned where an enterprise may want to perform out-of-band traffic decryption (which PFS does not allow) for the purposes of monitoring, compliance, or protecting against application-level DDoS attacks (L7).
While we are definitely not ready to discuss regulatory requirements, our own product for mitigating application DDoS attacks (including a solution, Sensitive and/or confidential information was created in 2012 with PFS in mind, so our clients and partners did not need to make any changes to their infrastructure after the server-side TLS version update.
Also, there have been no problems related to transport encryption since the implementation. Officially: TLS 1.3 is production-ready.
However, there is still an issue related to the development of next-generation protocols. The problem lies in the fact that the progress in the development of protocols in the IETF heavily depends on the results of scientific research, and the state of academic research in the field of mitigating distributed denial-of-service attacks is quite dire.
A good example can be found in of the IETF draft 'QUIC Manageability', which is part of the upcoming QUIC protocol suite: it states that 'modern methods of detection and mitigation of [DDoS attacks] generally include passive measurement using network flow data.'
The last point is rarely found in real corporate environments (and is only partially applicable to Internet service providers), and in any case is hardly a 'general case' in the real world — yet it frequently appears in scientific publications, usually not backed by testing across the full spectrum of potential DDoS attacks, including application-layer attacks. The latter, due to the global deployment of TLS, clearly cannot be detected through passive measurement of network packets and flows.
Similarly, we still do not know how DDoS mitigation hardware manufacturers 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 for an upgrade.
Setting the right goals for directing scientific research is a serious task for DDoS mitigation service providers. One area where development can begin is at IRTF, where researchers can collaborate with industry to refine their knowledge in the problem area and explore new research directions. We also warmly welcome any researchers who might be interested — feel free to reach out to us with questions or proposals related to DDoS research or the SMART research group at
Source: habr.com
