TLS 1.3 – Status, Concerns & Impact

It is common knowledge that in August, 2018, TLS 1.3 was ratified by the Internet Engineering Task Force (IETF), which has made it the new standard for connection security on the internet. The approved version of the RFC is an upgrade of the TLS 1.2 standard, which had been under discussion for over two years by the IETF. TLS 1.3 primarily focuses on the speed and security of connections.

However, TLS 1.3 comes with its own set of challenges and concerns, especially for the network traffic inspection industry.

In this article, we will look at some of the major developments in TLS 1.3, their relevance to middle box decryption solutions, concerns raised by the upgrades introduced, relevance of TLS 1.2 after the ratification of TLS 1.3, and how these changes impact middle box decryption solutions.

What’s New with TLS 1.3?

Some of the major upgrades made in TLS 1.3 are as follows:

Encrypted Server Name Identification (ESNI)

TLS 1.3 promised major improvements in user privacy. In TLS 1.2, most of the SSL/TLS handshake is carried out in clear text. This exposes the server name identification (SNI) in Client Hello or the Subject Alternate Name (SAN) in the server certificate to eavesdropping, exposing, for example, the users’ browsing history. To address this issue, earlier drafts of TLS 1.3 talked about the concept of encrypted SNI (ESNI) in Client Hello, as well as encrypted server certificates in Server-Hello messages.

By the time TLS 1.3 was published, ESNI support was dropped, due to performance overhead and low adoption. However, server certificate encryption was adopted by default. While this fails to provide complete user privacy, it helps the protocol to evolve since most of the handshake is now encrypted and therefore unaffected by compatibility issues with older clients.

TLS Version Negotiation

In previous TLS versions, users were allowed to renegotiate cipher suites by simply rearranging the preference list in the Server Hello. This could lead to downgrade attacks, where an attacker could simply rearrange the cipher suite list and downgrade the client to a vulnerable TLS or SSL version, exploiting their vulnerabilities.
TLS 1.3 disallows renegotiation and uses the “supported_version” and “legacy_version” extensions. Now, TLS 1.2 and older versions are listed as “legacy_versions” when a connection is being established, while TLS 1.3 is listed as the only “supported_version.” Attackers can no longer simply “shuffle” the cipher suite preference list and downgrade.

Zero Round-Trip Time (0-RTT)

TLS 1.3 introduces a new mode called the Zero Round-Trip Time (0-RTT), which saves a round trip during connection setup for certain applications. This method leverages pre-shared keys (PSK) from either previously established TLS connections or some external source to increase performance and reduce latency. However, this method introduces certain vulnerabilities, which are discussed in the next section.

Concerns With TLS 1.3

Privacy Concerns

The financial services and healthcare industries are subject to privacy standards, for example the Health Insurance Portability and Accountability Act of 1996 (HIPAA) which mandates that patient data privacy be maintained. This means that any data going back and forth between a patient and the healthcare data servers needs to be encrypted at all times. Decryption solutions deployed in the middle are supposed to bypass this traffic onto the servers directly.

While the decryption solution can enforce bypass policies based on the SNI information presented by the client, the certificate SAN cannot be determined from an encrypted server certificate, and therefore the decryption solution cannot cross-check the server’s identity.

Consequently, this traffic has to be decrypted to match the SNI with the certificate SAN, and once the traffic is decrypted, the privacy rules are violated, leading to lawsuits and fines. As adoption of TLS 1.3 picks up, these privacy rules would have to be updated accordingly, which itself, would open a Pandora’s box of privacy concerns and other issues.

Performance and Latency Concerns

Organizations have policies that require them to enforce decryption bypass. Previously, decryption solutions could bypass certain types of traffic based on the SNI or certificate SAN. But with TLS 1.3’s encrypted SAN, this process has become more cumbersome. Decryption solutions must now decrypt traffic, even for bypassing. This unnecessarily adds latency, leading to performance degradation in comparison to the alternative, i.e., TLS 1.2.

0-RTT and Replay Attacks

0-RTT is supposed to improve the performance of TLS 1.3, but it is important to note that the use of this mode can introduce vulnerabilities. This includes replay attacks, in which attackers can gain access to the connection information and then use it to resend requests to the server, mimicking real clients. This can be disastrous in the financial sectors as attackers can execute multiple banking transactions where only a single transaction was intended.

TLS 1.3 RFC admits this and mentions that there is no guarantee against replay attacks with 0-RTT. The burden of security has been transferred from the protocol and to the applications, where it is suggested that security mechanisms against replay attacks are introduced.

TLS Version Negotiation and Continued Security

Previously, if a TLS version or cipher suite was not supported by the client or the server, they would negotiate and select a different one from their preference lists. Such flexibility is important so that when new cipher suites or TLS versions are introduced, network outages or security lapses aren’t caused.

TLS 1.3 doesn’t allow “shuffling” of cipher suite preference lists, meaning pseudo-proxy decryption solutions will fail. Such solutions have previously caused serious problems, ranging from network outages to passing traffic through, exposing users to potential attacks.

However, full or active proxy solutions have the ability to negotiate different cipher suites and TLS versions, based on the user’s requirements. A full proxy solution maintains two separate connections, between the client and itself, and between itself and the server. TLS 1.3 supports such solutions and allows for them to have the ability to remove TLS 1.3 from the “supported_version,” letting them use the “legacy_version” list. Full proxy decryption devices provide users with a future proof and resilient solution. Such a downgrade to a “legacy” version or TLS 1.2 is also perfectly acceptable according to RFC 8446.

Why Hasn’t the Internet Switched to TLS 1.3?

Based on the discussion above, we can say that a widespread implementation of TLS 1.3 as the internet standard will take longer than one might think.

Impact of TLS 1.3 on Decryption Solutions

Full Proxy Architecture

A full or active proxy solution that has full control over cipher suite selection has the ability to downgrade TLS 1.3 connections to TLS 1.2 or can have separate versions on the client side and the server side. As mentioned above, this does not violate the TLS 1.3 RFC.

If a new TLS version or cipher suite is introduced into the network, a true full proxy solution doesn’t break the network and ensures continued protection by negotiating different cipher suites.

Privacy and Compliance

With TLS 1.2 support, decryption solutions can remain compliant with privacy standards like HIPAA since they can bypass traffic without decrypting it. By using TLS 1.2, decryption solutions can have access to the SNI and server certificate SAN, making bypassing reliable and easy. It also eliminates the latency introduced by decrypting connections for bypassing with TLS 1.3 on the client side. The client side is already secured within the enterprise perimeter, and therefore no security concerns are raised.

So, What’s the Recommended Best Practice?

Even though TLS 1.3 was ratified in 2018, adoption is very slow because TLS 1.2 is still relevant with no known vulnerabilities. TLS 1.2 is still the protocol of choice for the internet and it is still a valid solution for enterprises. TLS 1.3 also comes with its own set of concerns that need to be addressed.

A10 Networks’ SSL Insight is a full-proxy solution that addresses all the challenges introduced by TLS 1.3, while making the network more resilient and future proof. Such a solution doesn’t violate the RFC and is provisioned in Section 2.2.4 of the TLS 1.3 RFC for TLS use cases, draft 00.

With its full-proxy capabilities, SSL Insight has the ability to negotiate different cipher suites for the client and the server side, and will be able to support the following combinations:

However, as TLS 1.3 use gains traction, based on the discussion above, A10 Networks recommends use of the second scenario, i.e., using TLS 1.2 for the client side, while using TLS 1.3 for the server side. This helps improve performance, ensures compliance standards are not violated, and leverages all the advantages of TLS 1.3 for the outside connections. This flexibility makes SSL Insight both secure and compliant without any additional patches or upgrades.


|

July 17, 2019

About Babur Khan

Babur Nawaz Khan is a Technical Marketing Engineer at A10 Networks. He primarily focuses on A10's Enterprise Security and DDoS Protection solutions. Prior to this, he was a member of A10's Corporate Systems Engineering team, focusing on Application Delivery Controllers. Babur holds a master's degree in Computer Science from the University of Maryland, Baltimore County. READ MORE