The What and The Why of TLS Inspection

Connecting to nearly any web page today, you’re more often to see a URL that begins with “https://” instead of “https://”. Wondered what the “S” is for? It stands for “secure”, but more importantly, it identifies that the connection is taking place over a secure channel using the Transport Layer Security (TLS) protocol.

But what is TLS, and beyond that, what’s a TLS inspection? Let’s take a quick look at what TLS is, and then dive into how TLS inspection can be used to see past “invisible traffic” and help your firewall do its job effectively.

What is TLS?

TLS (Transport Layer Security) is the evolution of SSL (Secure Socket Layer). SSL evolved into TLS, now in version 1.3. While many people use SSL and TLS interchangeably, they are technically different protocols – and here in 2021 when someone says SSL, they most often mean TLS.

TLS creates a secure end-to-end encrypted tunnel between two points, (in theory) denying the ability of bad actors to surveil your traffic without your permission. The purpose of TLS is to achieve the “Confidentiality” component of the C-I-A triad, without TLS encryption on your web browsing session, someone could potentially see what you are doing, or even compromise your device.

How does a TLS session work?

A TLS session is established by a handshake process initiated by a client (like your web browser) using TCP port 443, instead of the common TCP port 80 for HTTP traffic. The client starts by telling the server it wants to set up an encrypted session. After the handshake, they share what’s known as an asymmetric cipher: a one-way secret code to establish a public key. Once the public key is accepted, this establishes the symmetric cipher. Once the connection is established, you have a highly secure system that’s well trusted within the industry.

What is TLS inspection?

Understanding how TLS works on your traffic will also give you some insight into the challenges it creates for network security. Seems counterintuitive, right? Malicious actors are particularly adept at covering their own tracks, actually using security technology to hide the things they are trying to do on your network. Ironically, TLS provides them a great way to do it.

How? The TLS encryption is allowing the content of that stream to essentially appear invisible, unable to be inspected by your firewall. Think of it like a letter. Your firewall can see the outside of the envelope, but it has no idea what’s written on the inside. And once this traffic is invisible, intruders can put anything they want into that stream.

Let’s say an attacker is trying to exploit your network and launch a ransomware attack. When a user clicks a link to an unencrypted site in a phishing email, a network firewall that’s able to recognize this attack signature should block it before breaking through to your network. However, if the link leads to an encrypted site, the attacker can make the attack “disappear”. By encrypting the attack/session using TLS, the firewall can’t see it. And you can’t block what you can’t see.

This is where TLS inspection comes into play. It’s a great leap forward in perimeter security and defense, allowing the firewall to inspect all TLS traffic coming and going on your network, and continuously monitoring traffic flows for malicious activities. Let’s look at how that works.

What does a TLS inspection look like?

While you can technically do TLS inspection on any device you manage that sits between the end user and their applications, TLS inspection is mainly done on the firewall. In order for a network firewall to conduct TLS inspections, it has to be able to insert itself, unencrypted, into the communication path. In other words, the firewall needs to open the envelope, read what is inside, seal it up, and send it on its way. Oddly enough, there’s a malicious hack that does exactly this: the “man in the middle attack”. In a man in the middle attack, the threat actor poses as the relay between two communicating devices and intercepts communication flowing between them. A classic example of this is a rogue access point posing as a legitimate access point on your network – by impersonating the legit access point, the rogue AP can intercept all data the endpoint is sending.

A firewall with TLS inspection capability is essentially doing just this: acting as a man in the middle towards its own data stream. The difference here is that as the network administrator is in control, not an attacker.

In modern browsers, there are security protections in place to prevent man in the middle attacks, and the same protections can make enabling TLS inspection on your firewall more difficult—but this is a good thing. If you’ve ever seen a warning like the one below, it’s likely because the device’s TLS certificate is expired or not signed by an authorized Certificate Authority (CA). In other words, you can’t just open the envelope without anyone noticing!

To do TLS inspection right, your firewall must present a valid certificate to the end device. Often this means installing a root certificate on your endpoints so that they trust the firewall, avoiding the security message above and allowing the firewall to act as a proxy for any SSL/TLS sessions that are initiated.

Once the sessions have been proxied by the firewall, it’ll intercept all traffic, decrypt the SSL/TLS session, and send it to its inspection engines to check for malware or other attack vectors. It then re-encrypts the packet and sends it along to its destination. Today’s modern security appliances, with fast processors and quick memory, can perform these inspections without any delay to the end-user.

Pros and cons of TLS inspection

Pros

• Identifying threats. You can’t protect what you can’t see! The ability to identify threats, with the growth of HTTPS over a majority of web traffic, is becoming more and more of a priority. There are estimates that more than 70% of all web traffic coming into your production networks today is encrypted, and it won’t be long until that number is near 100%. So if you’re not doing a TLS inspection, then you’re not seeing this traffic. Once these threats are identified, they can be dealt with and proper protections can be implemented.
• Data loss prevention. What data is leaving your network? Should it be leaving? Where’s it going and why? Many times, security threats are initiated from inside your network, leaving you blind to these transfers of critical company information going out. So, this inspection requirement runs both ways.
• Identifying unapproved applications. Are there applications using the network that shouldn’t be? Maybe they shouldn’t be entering the network at all? From wasted bandwidth to legal and ethical concerns for the company, the simple fact is there are types of traffic that can become a serious liability to the company at large.

Cons

• Performance. While most next-generation firewalls can perform TLS inspection, decrypting, processing, and re-encrypting all of that traffic can be resource intensive! If your firewall isn’t properly sized to do TLS inspection on your network, network performance could suffer for users.
• Privacy. The purpose of encrypting traffic over TLS is privacy. By introducing TLS inspection into your network, you’re breaking this assumption. While there’s often a legitimate need to decrypt traffic, network administrators need to ensure that they are still in compliance with their organization, industry, and country’s legal frameworks around personal privacy. One example I often cite is personal banking. While there may be a policy in place not to do personal banking on employer or network devices, some people do. As a network administrator, you need to be careful you’re not infringing on personal privacy regulations if you do inspect that traffic.
• Connectivity. As a network manager, the goal of good performance is going to include resolving specific connectivity issues. As well, some applications have security designed to work only when they are presented with the exact TLS certificate they’re expecting (the Auvik collector is a prime example). Or, you may be more familiar with the Apple Store, which will not work with TLS inspection. For these types of applications, your choice is to disable TLS inspection or your application simply won’t work.
• Cost considerations. Implementing TLS inspection may require more advanced and more expensive hardware. And it may demand better-trained engineers to set up and make good use of it. But this cost may be low compared to the potential cost of a major breach. It all depends on how much your data is ultimately worth to your peace of mind, and your company’s bottom line.

---

Depending on what your use case is for TLS inspection, you may want to take a look at alternatives that don’t require a ‘man in the middle’ setup. For example, Auvik TrafficInsights leverages machine learning and traffic classifications to detect applications, like Dropbox, Netflix, or Slack, are in use on your network, without the need to decrypt traffic.