Hiding undetected: Why security teams can no longer overlook HTTPS decryption

Decrypting HTTPS (TLS/SSL) traffic at the network perimeter is a vital step in protecting against malware and other online threats. Most of today’s web traffic is encrypted and presents an obvious hiding place for threat actors to deliver cyberattacks, since many network security controls aren’t set to inspect encrypted traffic. Consider recent findings from WatchGuard’s Threat Lab in its Q4 2022 Internet Security Report (ISR). While the report showed an apparent decline in overall malware volume, the Threat Lab analysts found a much higher prevalence of malware being delivered over encrypted connections when they looked closer at decrypted HTTPS traffic. These results came from a mere 20 percent of devices decrypting TLS and indicate the other 80 percent would also show malware volume is up, but hidden -- which mirrors findings from previous quarters.

Despite this trend, it’s common for teams not to enable decryption at the firewall due to the complications it can present. The process requires resources to decrypt and then re-encrypt traffic passing through a gateway device, as well as next-gen firewalls (NGFW) or unified threat management (UTM) appliances that use significant computing horsepower, all which impact network performance. Then, introducing decryption while managing the performance of other security tools and their varying uses could be difficult. Today, however, tabletop UTM/NGFW solutions can perform this process at the speed of the incoming WAN connection. So now, users’ main objection is the initial configuration of TLS/SSL decryption, and the need for exceptions for certain applications.

While finding time to configure a more complex policy is understandably difficult for resource-starved IT and security teams, HTTPS decryption is a practice that security teams can no longer overlook. The ISR findings clearly indicate attackers are concentrating on delivering malware over encrypted connections, putting organizations that don’t decrypt traffic at higher risk.

A broad avenue for threat actors

To understand the increased risks that organizations face, one must look at the opportunity encrypted traffic presents malicious actors. Today, almost all web traffic is encrypted, with 95 percent of websites on Google using HTTPS and 99 percent of browsing time in Google Chrome being linked to HTTPS sites, per SSL findings from SerpWatch. If a security team doesn’t decrypt this traffic at the network security gateway, they miss anything it contains, creating a massive blind spot. Additionally, creating an HTTPS-protected site has never been easier with organizations like Let’s Encrypt available, which threat actors can leverage to secure their traffic for free.

Meanwhile, a large portion of cyberattacks happen over the web through encrypted connections. In the Q4 2022 ISR, WatchGuard’s Threat Lab found that a startling 93 percent of malware hides behind TLS/SSL encryption, rising from 82 percent that was reported the previous quarter. Endpoint malware detections also increased by 22 percent. Compounding the matter, 60 percent of the security incidents reported in Verizon’s 2022 Data Breach Investigations Report involved hacks of web applications. Credential theft (or stealing a user’s proof of identity) accounts for many successful cyberattacks -- and the successful phishing attacks that steal those credentials use HTTPS.

Why more security teams don't enable decryption

As mentioned, enabling HTTPS decryption isn’t as simple as flipping a switch; its initial setup is complex and can pose complications to how certain software or web apps operate.

Doing TLS/SSL decryption without breaking the trust chain of digital certificates requires adding a special custom root CA certificate to your browsers and devices, so that they trust the certificate as an intermediary for encrypted traffic. This is what lets your device re-encrypt traffic and allows the trust chain to pass all certificate validations. There are two ways TLS decrypting products allow you to do this -- the hard way and the easy way.

The hard way involves using a custom root CA cert (or a Proxy Authority cert) that comes with TLS decryption products. You can export this certificate and import it into all clients and devices that need TLS/SSL decryption. The downside is that you must get that certificate on all devices you have, sometimes in multiple places (like web browsers). While group policy can push new certs to many devices, installing this special cert on so many devices and browsers can pose too much work. However, if you are a Windows (or Azure) Active Directory user, you likely have an Enterprise CA cert for your domain. Rather than export the product’s cert and struggle getting it to multiple devices, you can simply import the cert to the product that all your devices already trust. This easier method allows most teams to set up decryption in mere hours and less than a day with testing.

However, other complications might surface requiring exceptions. This TLS decryption method only works on devices that provide some control of their certificate store. Some IoT devices in your network may not offer control and must be added as exceptions that bypass TLS/SSL inspection. The most common issues are with websites, applications and programs that leverage additional TLS/SSL protections to prevent man-in-the-middle (MitM) attacks. Mechanisms like HTTP Strict-Transport-Security (HSTS), certificate pinning, or program-specific implementations force your browser or device to only accept the site or domain’s original certificate and not intermediary ones, breaking the validity of that connection when decrypted. For instance, a site like DropBox might decrypt well when visiting via web browser, but the DropBox application won’t work unless it sees the required certificate. You will have to add exceptions to your HTTPS decryption policies over time. Fortunately, most products offer default exceptions and easy ways to add them.

The critical role of decryption

Although HTTPS decryption presents complexities, the reward is worth the effort. Enabling decryption puts security teams in a stronger position to block malicious websites that distribute botnet trojans as well as detect instances of botnet command-and-control (C2) traffic. Otherwise, network malware detection services will not catch these threats. While security teams can block a select number of domains and IPs regardless of whether they’ve enabled decryption, any systems that can recognize C2 communication to new places won’t work without SSL/TLS decryption.

Decryption can also help organizations recognize when they may be leaking personally identifiable information (PII) or credit card information over their network. Unless a company has endpoint data leakage protection solutions in place, data loss prevention software can’t find this data in encrypted traffic without decrypting it first. Lastly, it’s important for organizations not to rely too heavily on endpoint security to catch every threat. While it’s true that endpoint protection helps bolster security, many evasive malware stagers are designed to attempt to disable or bypass local endpoint security controls before delivering the real payload. For effective security, it is better to filter as much malware at a network level first, so teams don’t have to rely on the endpoint to catch everything.

The reality facing security teams is almost all web traffic is encrypted and many cyberthreats leverage encrypted traffic. Not decrypting this traffic and scanning it at a network level significantly reduces a security team’s defense-in-depth options, leaving your organization with a single, last layer of endpoint defense. To bolster and maintain protection, don’t fall into this precarious position and subject your organization to increased risk. The time to decrypt HTTPS traffic for stronger security is now.

Photo Credit: mkabakov/Shutterstock

Corey Nachreiner is Chief Security Officer, WatchGuard.