DDoS Detection, Mitigation, Orchestration, and Threat Intelligence
Consolidated Security & CGNAT
TLS/SSL Inspection
Web Application Firewall
Application Security & Load Balancing
Analytics & Management
CGNAT & IPv6 Migration
It is common knowledge that in August, 2018, Transport Layer Security (TLS) Protocol Version 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 TLS developments, their relevance to middle box SSL 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 SSL decryption solutions.
Some of the major upgrades are as follows:
TLS 1.3 promised major improvements in user privacy. In TLS 1.2, most of the SSL handshake/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 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 this new protocol version 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.
In previous Transport Layer Security (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 1.3 is listed as the only “supported_version.” Attackers can no longer simply “shuffle” the cipher suite preference list and downgrade.
The new 1.3 protocol 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 Transport Layer Security connections or some external source to increase performance and reduce network latency. However, this method introduces certain vulnerabilities, which are discussed in the next section.
As financial services organizations transform operations, leverage more of the cloud and utilize remote workforces, IT’s lack of visibility into encrypted traffic and the malware it may contain puts them at risk for a cyber attack, data exfiltration, and compliance failures.
Learn Why Encryption Is Risky
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. SSL Decryption solutions deployed in the middle are supposed to bypass this traffic onto the servers directly.
While the SSL 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.
Organizations have policies that require them to enforce SSL 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. SSL 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 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.
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 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.
Based on the discussion above, we can say that a widespread implementation of 1.3 as the internet standard will take longer than one might think.
Full Proxy Architecture
A full or active proxy solution that has full control over cipher suite selection has the ability to downgrade 1.3 connections to 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.
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 1.3 on the client side. The client side is already secured within the enterprise perimeter, and therefore no security concerns are raised.
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. The new protocol also comes with its own set of concerns that need to be addressed.
A10 Networks’ Thunder® SSL Insight (SSLi®) is a full-proxy solution that addresses all the challenges introduced by 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, Thunder SSLi 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 1.3 for the server side. This helps improve performance, ensures compliance standards are not violated, and leverages all the advantages of 1.3 for the outside connections. This flexibility makes Thunder SSLi both secure and compliant without any additional patches or upgrades.
