Shieldx Elastic Cloud Security platform supports TLS 1.3

Elan Anbalagan

Elan Anbalagan

July 17, 2019

When we recently saw TLS 1.3 approved, what we really saw was the introduction of best-of-breed security capabilities end to end. This latest iteration of what was originally known as the SSL protocol addresses security shortcomings from the previous version and significantly reduces latency with abbreviated and simplified handshakes. It’s more secure and it’s faster: win/win.

As you might expect, the ShieldX Elastic Cloud Security platform can transparently proxy TLS 1.3 connections and thus customers may use the platform to secure both server and client workloads with inbound and outbound proxying. ShieldX supports all aspects of the protocol and works with popular implementations such as NGINX, Google Chrome and Mozilla Firefox.

Perfect forward secrecy

A concern for key-exchange frameworks like TLS is whether future compromises of a secret key will expose prior communications. Perfect forward secrecy (sometimes just called forward secrecy) means that your session keys will not be compromised even if the private key of the server is compromised. Forward secrecy thus protects past sessions against future revelations and this is now part of TLS: session setup now only supports key exchange modes that provide forward-secrecy. Key exchange methods that don’t provide forward secrecy (non-ephemeral Diffie-Hellman, for example) are deprecated.

While this is great, one important note is that better encryption makes inspection via an inline proxy essential to prevent encrypted threats from passing into internal infrastructure unnoticed. A previous blog entry, for instance, looked at inline proxy when defending against Petya malware variants.

Improved TLS handshakes

TLS 1.3 does things more efficiently and with greater security. All session handshakes that include sensitive data will now be in encrypted form, supporting encrypted extensions (only “client-hello” and part of “server-hello” are exchanged in clear text). For further simplification, several handshakes such as “server-key-exchange” have been deprecated.

According to one cloud proxy provider, about 60% of web connections are from first-time visitors to a site, a situation which the improved handshakes in 1.3 signficantly speed up. For the 40% of connections where the site was recently visited and the previous connection is being resumed, 1.3 supports 0-RTT (zero-round-trip) reconnection. This decreases the time required in the returning-user scenario by not waiting for certain parts of the handshake to be fully returned before proceeding.

Better key and certificate handling

Several elements of key derivation and certificate exchange have been tidied up in 1.3:

  • A new Key-Update mechanism is a more secure approach to refreshing the symmetric encryption key that doesn’t involve repeating the initial certificate exchange.
  • Packet hashes are included in key calculations, making keys more secure than ever—what was an optional extension in 1.2 is now part of the base protocol.
  • Key derivation/calculation doesn’t use packet fields that are exchanged in clear-text (TLS 1.2 and earlier protocols used to include client random and server random fields to derive keys).
  • The protocol now uses HKDF (The HMAC-based Extract-and-Expand Key Derivation Function) for key derivation. Separate secrets and key blocks are generated/used to exchange SSL handshake and SSL application data.
  • Going forward, available cipher suites have been pared down so that AEAD (authenticated encryption with associated data) ciphers like GCM and CHACHA-POLY are available and other prior options have been removed. AEAD combines both encryption and authentication into one step, rather than using a key and a separate message authentication code (MAC).
  • TLS 1.3 supports a proposed extension that allows certificates to be compressed and exchanged in a new TLS session’s handshake. Since certificates can contain a fair amount of text information, they are good candidates for compression. Reducing the certificate size reduces the number of bytes exchanged and thus reduces latency.

Need for TLS inspection

As hinted above, inline proxy inspection of network traffic becomes more important than ever with TLS 1.3. Network threats continue to evolve, especially in their ability to evade detection and penetrate enterprises. Sending malicious data across encrypted channels is perhaps the easiest way to evade detection because many organizations continue to deploy and operate their security perimeter devices without inline, decrypted packet inspection.

Even in cases where organizations deploy TLS inspection, they frequently use it in tap mode or else enable a non-proxy mode by downgrading the security capabilities of their webservers to use RSA or other non-ephemeral key exchange methods. This not only breaks forward-secrecy, it also endangers end consumers by weakening the security capability offered by the protocol. (In the interest of completeness, note that application detection and classification that works based on the TLS SNI extension will continue to work.)

In almost all cases, though, enabling TLS inspection is an important first step. Using TLS proxy inspection provided by Shieldx Elastic Cloud security platform, enterprises may further leverage our “Indicators of Pivot” feature to detect and block advanced threats and lateral movements inside their network.