Transportation Layer Security (TLS) 1.3 protocol provides a new level of privacy and performance compared to previous versions of TLS. The TLS 1.3 protocol (RFC8446) is faster, more secure and removes some obsolete features in TLS 1.2.
TLS 1.3 Benefits:
1. Speed – faster handshake
TLS 1.3 requires only one round-trip, which in turn cuts the connection setup latency in half from TLS 1.2 which required two rounds trips to complete the handshake.
2. More secure
TLS 1.3 has improvements to ensure the confidentiality and integrity of communications. Even if an eavesdropper is able to get a copy of the transaction, they would have a very difficult time trying to decipher it. Conventional SSL communication uses the static Public/ Private Key infrastructure to exchange session keys. However, in case the private keys are compromised, all recorded previous communication between the client(s) and the compromised server can be decrypted using the private key.
- Perfect Forward Secrecy (PFS) employs the use of ephemeral keys to overcome this concern.
PFS is mandatory with TLS 1.3: By generating a unique session key for every session a user initiates, even the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. Knowing the private key of the server no longer allows decrypting the session.
Note — deploying PFS is the best practice that can be adopted even with TLS 1.2
- Parts of the handshake (server certificate values such as CName, SAN) are encrypted. This prevents malicious third parties (that rely on examining server certificates) from eavesdropping on the connection.
3. Removing obsolete features and adding improved functions
TLS 1.3 removes several features such as static RSA handshake and SHA-1 hash function, and adds protocol version downgrade protection, new ciphers, and key exchange protocol. TLS 1.3 is also designed to be backward compatible to TLS 1.2 with an appropriate “supported versions” extension in the connection handshake.
The case for inspecting SSL/TLS traffic
In recent years, the amount of Internet traffic has become the predominant percentage (more than 90% in some deployments) of the total traffic driven by web applications and the lower the cost of deploying encryption with free certificates. A recent Forbes article by Amit Sinha, CTO and EVP of Cloud Operations at Zscaler, outlines the risks of not inspecting encrypted traffic.
Implications of inspecting SSL/TLS traffic
In addition to stopping hackers, SSL inspection is useful when an enterprise wants to know what its employees are intentionally or accidentally sending out of the organization. SSL inspection is also needed for compliance, to ensure that employees are not putting the organization’s confidential data at risk. A multi-layer defense-in-depth strategy that fully supports SSL inspection is essential to ensure enterprises are secure.
The common ways of inspecting SSL and their key considerations are described in the table below.
* See key findings in the SSL performance report on NG firewalls
Zscaler is well positioned for future-proof TLS 1.3 support
Zscaler SSL inspection occurs in two modes: explicit and transparent.
In an explicit proxy deployment, the user's client software is configured (via PAC file or Z App) to send requests directly to Zscaler. In a transparent proxy deployment, user requests are transparently redirected to Zscaler (via GRE, IPsec forwarding methods). In the explicit proxy mode, the client sends an HTTP connect request to Zscaler with the destination address. Zscaler uses this to initiate a connection to the server on behalf of the client. Since Zscaler is in the middle of the conversation with separate connections to the client and the server, it can inspect both sides of the conversation when TLS 1.2 or TLS 1.3 is in use in the explicit proxy mode.
In the transparent proxy mode, Zscaler uses the SNI in the Client Hello that indicates the domain to Zscaler. If a web server hosts multiple domains, SNI ensures that a request is routed to the correct site so that the right SSL certificate can be returned to be able to encrypt and decrypt any content. The Client Hello with SNI is sent unencrypted as the client and server have not exchanged encryption keys yet.
Zscaler can also apply policy based on the hostname in the server certificate. With TLS 1.3, the server certificate in TLS 1.3 is encrypted. Zscaler will still have visibility to the SNI and destination server IP address, which is sufficient information for Zscaler ZENs to establish connections to the server. Unlike appliances that will likely require HW refresh to optimize performance, the Zscaler cloud architecture scales to meet the higher performance requirements of TLS 1.3 and minimizes the impact of complexity in customer deployments.
Perfect Forward Secrecy (PFS)
The "E" in ECHDE stands for “Ephemeral” and refers to the fact that the keys exchanged are temporary, rather than static. ECDHE is used where both the client and the server generate their public-private key pair on the fly when the connection is established. The keys are then signed with the TLS certificate (for authentication) and exchanged between the parties.
Debunking the FUD
There has been a lot of media coverage regarding security solutions (commonly referred to as middle boxes) that will lose visibility due to TLS 1.3. This only applies to devices that do not perform inline scanning and depend on the original private (static) keys to decrypt and inspect the data. These solutions will no longer be able to perform retrospective decryption since PFS (ephemeral keys) are mandatory with TLS 1.3.
Passive middle boxes, which depend on SAN (subject alternative name), CN (common name/hostname), and other certificate information to perform actions, will also no longer be able to function as the server certificate itself will now be encrypted.
These passive SSL inspection devices will also become increasingly blind to a significant portion of TLS 1.2 traffic as SSL clients and servers rapidly adopt PFS ciphers. ECDHE is significantly faster and less resource intensive than DHE, critical criteria, especially for mobile devices.
The Zscaler advantage
Zscaler is a true inline SSL proxy. It terminates the SSL connection established by the client and establishes a new SSL connection to the server; from a client’s perspective, Zscaler becomes the server and from the original SSL server’s perspective, Zscaler becomes the client. Considering that Zscaler is not just inspecting the SSL traffic on the wire, but terminating the connections, Zscaler has full visibility to the CN (Common Name), and other certificate parameters typically not visible to a passive SSL inspection devices.
- Cloud scale: Zscaler has built a custom TCP and SSL stack to handle encrypted traffic on a global scale. With this architectural advantage, impact due to SSL inspection becomes a non-issue. Zscaler inspects traffic in real time, including encrypted traffic, so hackers and their malware can be easily identified.
- Future-proof: TLS 1.2 is widely adopted, continues to provide secure connectivity, and is now mandated by PCI security standards. Zscaler has supported TLS 1.2 for several years and has also extended support for PFS with ECDHE and ECDSA ciphers. With Zscaler, supporting TLS 1.3 becomes a seamless change vs. a major configuration overhaul.
- Simple: The Zscaler security-as-a-service architecture operates seamlessly without imposing new hardware planning requirements or costly hardware upgrades due to TLS 1.3.
Zscaler is committed to providing customers with secure internet connectivity and is uniquely positioned to support TLS 1.3 inspection in a truly scalable, cloud-first architecture. In a future blog, we will explore the status and implications of experimental privacy technologies like ESNI that are not included in the TLS 1.3 standard.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Udayan Palekar is Director of Product Management at Zscaler
