Networks are becoming increasingly opaque via encrypted sessions, greatly benefiting end users because it ensures privacy and authenticity of the connection between applications over networks where we must assume zero trust. The bad news is that threat actors are also benefiting from pervasive encryption. At the heart of the matter is how simple and easy it is to encrypt your network session these days due to libraries and code that have implemented versions of the Transport Layer Security (TLS). TLS and its predecessor, Secure Sockets Layer (SSL), which is now prohibited from use by the Internet Engineering Task Force (IETF) – are cryptographic protocols that provide communications security over a computer network. We could go way back to the beginning but to save time, let’s just start with TLS and see how it has changed from its version 1.0 to its current version 1.2, and what we can expect from the March 2018 release of version 1.3. We have invested a lot of time creating analysis techniques that respect the evolving TLS versions, and the security and privacy they guarantee, but at the same time ensuring that these privacy methods don’t allow threat actors to evade detection and become more hidden within your networks. And these concepts are critical to Cisco’s Encrypted Traffic Analytics (ETA).

For those of you who have been surfing in Hawaii since June of last year and might not have heard of Encrypted Traffic Analytics, here is a brief introduction: Encrypted Traffic Analytics is a solution set involving new extended telemetry put through an advanced analytical pipeline producing two valuable outcomes 1) the detection of malicious traffic without decryption and 2) the intelligence to govern your cryptographic policies.

Working our way up to the present (March 2018)

While I could go through an in-depth analysis of the evolution of the protocols, let me just quickly summarize with a timeline of how the discovery of weaknesses drove the evolution of the protocol and the compliance efforts to adhere to a baseline standard of protection:

Before any TLS version, we had SSL, and like all things in time, SSL was found vulnerable to attacks forcing SSL 2.0 to be prohibited in 2011 by RFC 6176. SSL 3.0 was also later prohibited in June 2015 by RFC 7568. We should all thank SSL for helping us evolve transport layer security – pour one out for my fallen homies.
In comes TLS version 1.0 and RFC 2246, but its downfall was that it was living in the past. For compatibility’s sake, it would negotiate back to SSL 3.0 which is a win for compatibility but a loss for security. Please note that the PCI Council has made it mandatory that organizations migrate from TLS 1.0 to TLS 1.1 or higher (1.2 is strongly encouraged) before June 30, 2018 so those of you who are required to be PCI compliant, get on it!
TLS version 1.1 and the current 1.2 made proactive changes to improve the mechanics of what it takes to setup, maintain, and teardown a secure connection over an assumed untrusted network. Yay version 1.2, which is what keeps us safe today.
Version 1.3 has just been approved in March 2018 by the IETF. TLS 1.3 considers traditional attack vectors, but also aims to ensure that pervasive and intrusive monitoring are no longer permitted. This is where it gets interesting because certain systems have gotten used to inspection via being an intermediate (man-in-the-middle) system, and like winter, change is coming folks – ignore at your own peril!

What is TLS 1.3?

TLS 1.3 took about 2 years and 28 drafts from the previous 1.2 version. It’s simpler, faster, and more secure. The cipher suite space has been pruned, and all the cipher suites that support TLS 1.3 use Authenticated Encryption with Associated Data (AEAD) algorithms. Static RSA and Diffie-Hellman key exchanges are now a thing of the past like mySpace. (just kidding, not really), and the remaining key exchange mechanisms ensure forward secrecy. 0-RTT mode was added to allow some application data to be sent in the first set of exchanged handshake messages. Blah blah blah but again, just remember it is simpler, faster, and more secure.

Similar to TLS 1.2, the first message a client sends, the ClientHello, defines the set of TLS parameters supported by the client and gives additional context about the TLS connection. The server responds with a ServerHello, selecting the parameters it supports from the lists provided by the client. (Queue the dramatic soundtrack – minor key) However, it is at this point that TLS 1.3 begins to diverge from earlier versions. The EncryptedExtension message allows the server to encrypt a subset of the ServerHello message that would have been sent in the clear with TLS 1.2. All future messages, including messages related to certificates, are encrypted, and have the same TLS type code as typical 1.2 application data messages.

So if you are following me so far, you can see that not only is this exchange simpler, but parts of it are no longer visible!

What does TLS version 1.3 mean for you?

“Work it harder

Make it better

Do it faster

Makes us stronger”

–Daft Punk 2001

As I said already, TLS 1.3 is simpler, faster, and more secure than version 1.2. These qualities are not really debatable, but what is controversial is where you sit on the Man-In-The-Middle (MiTM) argument (the ability for an intermediate system to relay between the communicating parties who believe they are speaking with one another). There is a group of folks who say they require the ability to MiTM a session in order to “monitor” the communication, and others that say all measures must be taken so that MiTM type of ‘monitoring’ is defeated. No matter where you sit on this issue, TLS version 1.3 is a big win for the latter.

I have always made the assertion that: All encrypted sessions begin unencrypted. The difference is that in TLS 1.3, a lot less is in the clear. For example, in TLS version 1.2 you were able to witness the disclosure of the Subject Alternative Name (SAN) in the Certificate but in 1.3, this is encrypted and not made available for inspection by any intermediate system. There are many documented use-cases similar to this and the argument is never-ending because folks who feel strongly about their position can easily find evidence that supports their argument.

Argue and complain all you want but TLS version 1.3 is here but so is Cisco’s Encrypted Traffic Analytics!

What does TLS version 1.3 mean for Encrypted Traffic Analytics?

The good news is that Encrypted Traffic Analytics does not require TLS 1.2 to be effective, and its techniques work just as well with TLS 1.3. The most impacted part of the telemetry is the Initial Data Packet (IDP) because there will be some missing extensions in the ServerHello (the ClientHello still gives us the same information). The Sequence of Packet Lengths and Times (SPLT) is still in play as well as the hundreds of other machine learning classifiers. And herein you can appreciate the fact that Encrypted Traffic Analytics is based on a multilayered machine learning pipeline, and also that it operates on a global scale correlating contextual information like certificates (local-only solutions would be blinded by the opacity of TLS 1.3).

We made a lot of decisions early in the design of Encrypted Traffic Analytics to be immune to any one major change like this because while an active threat actor might be able to defeat any one measure, defeating a diverse set of detection techniques all at once and all with high accuracy is not practical (as in it is “to boil the ocean” not practical).

Summary

My guess is that folks who have huge investments in being able to see what was visible in TLS 1.2, but is no longer visible in TLS 1.3 are the ones still complaining, now that 1.3 is official. I share the opinion of my team which is that TLS 1.3 is an important step for the security and privacy of the Internet, and it just made Encrypted Traffic Analytics an even more important part of your advanced threat detection strategy.

TLS 1.3 is a welcome change, and it highlights the strengths and the disruptive, future-forward capabilities of the Encrypted Traffic Analytics solution.

Learn more at https://cisco.com/go/eta