A Threat Actor’s Playground: Why Security Teams Must Decrypt HTTPS Traffic

Decrypting HTTPS (TLS/SSL) traffic at the network perimeter has become an essential practice in protecting against malware and other online security threats. Our recent analysis of malware trends and internet attacks in Q2 2023 showed that 95% of malware arrives over encrypted connections, illustrating the importance of inspecting this traffic. Additionally, malware is designed to be evasive and difficult for other security layers to catch. Enabling HTTPS decryption can pay dividends by detecting and blocking malware threats before they reach your endpoints.

Yet many security teams do not enable decryption at the firewall due to the potential complications it can present. Decrypting and then re-encrypting traffic passing through a gateway requires considerable compute resources, including next-gen firewalls (NGFW) or unified threat management (UTM) appliances, and can impact network performance. While it’s understandable that IT and security teams might want to avoid these impacts, the increased risks that organizations face have made HTTPS decryption a practice that teams simply can no longer overlook.

Encrypted traffic serves as a threat actor’s playground

Encrypted traffic presents a massive opportunity for threat actors to deliver their attacks, posing increased risks to organizations. Today, almost all web traffic is encrypted, with 95% of websites on Google using HTTPS and 99% of browsing time in Google Chrome being linked to HTTPS sites, per SSL findings from SerpWatch. If this traffic isn’t decrypted at the network security gateway, it’s impossible to know what it contains, creating an enormous blind spot for incoming attacks.

Why security teams may avoid decryption

Admittedly, enabling HTTPS decryption isn’t a simple practice; its initial setup is complex and can interfere with how certain software or web apps operate.

Performing TLS/SSL decryption without breaking the trust chain of digital certificates requires adding a unique custom root CA certificate to your browsers and devices so that they trust the certificate as an intermediary for encrypted traffic. This allows your device to re-encrypt traffic and the trust chain to pass all certificate validations. TLS decrypting products will enable you to do this in two primary ways: the hard way or the easy way.

The hard way involves using a custom root CA cert (or a Proxy Authority cert) 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 unique cert on numerous devices and browsers can be burdensome. 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 to get it to multiple devices, you can import the cert to the product that all your devices already trust. This easier method allows most teams to set up decryption in a few hours and less than a day with testing.

Unfortunately, there are other complications that may require 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 only to accept the site or domain’s original certificate and not intermediary ones, breaking the validity of that connection when decrypted.

The payoff of decryption

Despite the complexities that HTTPS decryption can present, the return is worth the investment. Security teams can more capably block malicious websites that distribute botnet trojans and detect instances of botnet command-and-control (C2) traffic when decryption is enabled. Network malware detection services alone 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 TLS/SSL decryption.

Decryption also helps organizations identify when they may be leaking personally identifiable information (PII) or credit card information via their network. Unless a company has endpoint data leakage protection solutions, data loss prevention software won’t find this data in encrypted traffic without decryption.

Security teams face a new reality: almost all web traffic is encrypted, and many cyber threats lurk in that encrypted traffic. For a modern, layered cybersecurity defensive strategy to work effectively, it’s important not to place too much of a burden on any one layer. Filtering as much malware at the network level first mitigates risks and ensures that you’re not overly reliant on the endpoint to catch all threats. In other words, the lack of decryption and scanning effectively weakens other layers of security. To strengthen and maintain protection, don’t subject your organization to increased risk and vulnerability. Make HTTPS decryption a standard practice for more robust security.

Corey Nachreiner is the chief security officer (CSO) of WatchGuard Technologies.

Related articles: