At the beginning of the year, in the 2018-2019 Internet Challenges and Accessibility Report 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.
IETF TLS Working Group Chairs :
"In short, TLS 1.3 should provide the foundation for a more secure and efficient Internet for the next 20 years."
Development took 10 long years. We at Qrator Labs, along with the rest of the industry, have closely followed the process of creating the protocol from the initial draft. During this time, it took 28 consecutive draft versions to be written in order to eventually see the light of day in 2019, 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 time.
According to Eric Rescorla (Firefox CTO and sole author of TLS 1.3) :
"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's already good support at the library level, and Chrome and Firefox enable TLS 1.3 by default."
Parallel to the IETF Working Group TLS ends declaring older versions of TLS (except TLS 1.2 only) 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: updating encryption protocols should not be postponed.
A list of current TLS 1.3 implementations is available on Github for anyone looking for the most appropriate library: . It is clear that the adoption and support of an updated protocol will be - and is already underway - rapid steps. Understanding how fundamental encryption has become in the modern world has spread quite widely.
What has changed since TLS 1.2?
Of :
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 intended to reduce connection set-up latency and the number of failed connections on weak links, which are often used as an excuse for providing only unencrypted HTTP connections.
Just as importantly, support for several legacy and insecure encryption and hashing 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, has been removed. while adding support for new cipher suites. Other enhancements include more encrypted handshake elements (for example, the certificate information exchange is now encrypted) to reduce hints to a potential eavesdropper, as well as improvements to forward secrecy when using certain key exchange modes so that communication at all times must remain secure, even if the algorithms used to encrypt it are compromised in the future.β
Development of modern protocols and DDoS
As you may have read, during the development of the protocol , in the IETF TLS working group . It is already clear that individual businesses (including financial institutions) will have to change the way they secure their own network in order to accommodate the now built-in protocol. .
The reasons why this may be required are set out in the document, . The 20-page paper mentions several examples where an enterprise may want to decrypt out-of-band traffic (which PFS does not allow), for monitoring, compliance, or application layer (L7) DDoS protection purposes.
While we're definitely not prepared to speculate about regulatory requirements, our own applied DDoS mitigation product (including sensitive and/or confidential information) was created in 2012 with PFS in mind, so our customers and partners did not need to make any changes in their infrastructure after updating the TLS version on the server side.
Also, for the time that has passed since the implementation, no problems related to transport encryption have been identified. Official: 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 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 would be IETF draft "QUIC Manageability", which is part of the forthcoming QUIC protocol suite: it states that "current methods for detecting and mitigating [DDoS attacks] typically involve passive measurement using network flow data."
The latter is, in fact, very rare in real enterprise environments (and only partially applicable to ISPs), and in any case is unlikely to be a "general case" in the real world - but constantly appears in scientific publications, usually not supported by testing. the full range of potential DDoS attacks, including application layer attacks. The latter, due to at least the worldwide deployment of TLS, obviously cannot be detected in any way by passive measurement of network packets and flows.
Likewise, we don't yet know how manufacturers of DDoS mitigation equipment 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 direction is a big challenge for DDoS mitigation service providers. One of the areas in which development can be started is β at the IRTF, where researchers can collaborate with industry to refine their own knowledge of a problematic industry and explore new areas of research. We also extend a warm welcome to all researchers, if any - we can be contacted for questions or suggestions related to DDoS research or the SMART Research Group at
Source: habr.com