Zeekryption: An Architect’s Guide to Zeek Decryption

Many security professionals rely on Zeek for network security monitoring. But the question keeps coming up—How to decrypt traffic using Zeek?

Summary

Network encryption became prevalent and harder to manipulate in the last decade. As a result, network security tools have lost a fair amount of visibility (although they can still give valuable insights). Naturally, security professionals want to regain that visibility. Due to improved TLS standards, network security monitoring tools like Zeek cannot directly decrypt (dare I say Zeekrypt) modern encrypted network traffic without additional help. Architects can consider several methods allowing Zeek to analyze decrypted traffic.

The SSL Adoption

SSL adoption skyrocketed over the last 5 years. You may be familiar with seeing Google’s Transparency Report showing an increase from 44% of web pages loaded over HTTPS in 2015 in the US, to 95% in May 2020. Needless to say, organizations everywhere have adopted network encryption and often have it turned on by default. Encryption is great, but it led to a huge drop in visibility for the security analyst.

Perfect Forward Secrecy (PFS) and why it breaks passive decryption

Not only did we see this leap in TLS adoption, but we also began to see a larger push towards implementing the feature perfect forward secrecy (PFS). In short, PFS frequently changes the keys between the client and server independent of the server’s private key. Even if attackers (or analysts) captured SSL traffic then later obtained the private key of the server, they would not be able to decrypt the content. Just as it limits attackers, engineers can’t load all of an organization’s private keys into a passive tool such as Zeek and expect to decrypt all the traffic.

Even if PFS was not involved, decrypting traffic on your Zeek sensor should be avoided as it would consume precious system resources. Use Zeek for what it does best—analyze traffic.

That leaves only four ways possible to decrypt and analyze traffic:

1. Obtain all generated keys from the server or client
2. Create a trusted man-in-the-middle.
3. Terminate SSL on reverse proxies or load balancers
4. Tap backend traffic

Method 1: Obtain all generated keys

I mention this more to explain why it is not viable. This method requires obtaining all keys exchanged during a TLS connection and giving them to the tool to decrypt the data. An example of doing this is configuring your web browser to export all SSL keys to a file where Wireshark then picks them up for decryption. But transferring those keys to a passive device in a secure and timely manner is complex, and I am unaware of any enterprise-ready solution that uses this method. It also violates the advice earlier—don’t decrypt on a Zeek sensor. This option works best with a single endpoint, but does not integrate well with Zeek.

Method 2: Trusted Man-in-the-Middle

Security personnel will find implementing a trusted man-in-the-middle a more realistic approach. In this method, administrators install the server’s private key and certificate on a device, such as a firewall or proxy, in-line between the client and server. (Decryption-capable firewalls generally run a proxy under the hood.) The device presents itself to the client as the authentic server to establish a trusted SSL connection between itself and the the client, and a separate SSL connection with itself and the real server. When passing the data between the two sessions, the device can send a copy of the decrypted traffic to Zeek for further analysis.

This can also work without the server private key. Instead, the administrator installs an organization’s trusted root certificate onto the client machine and the private key on the firewall or proxy. When the client attempts to visit an SSL website, the device will generate client-trusted certificates on the fly. The device again establishes separate SSL sessions between the client and real server, then sends a copy of the decrypted traffic to Zeek. The caveat here is you still cannot decrypt all traffic due to encryption features such as HTTP Strict Transport Security (HSTS) or certificate pinning. It also requires a mature public key infrastructure (PKI) to distribute the certificates to the organization’s controlled assets. However, it is difficult if not possible to distribute the certificate to unmanaged machines such as IoT devices.

Method 3: Terminate SSL on Reverse Proxies or Load Balancers

The third variation is similar to method 2, except decryption takes place on reverse proxies or load balancers. In this case, sysadmins install the website certificate and key on the reverse proxy to act as the website gateway. The connection to the actual servers can be SSL or plaintext. Either way, the reverse proxy can send a copy of the now-decrypted traffic to Zeek.

Method 4: Tap backend traffic

The final method requires a tap or span from the backend network to Zeek. This is exactly like method 3 with two differences. The backend network is in plaintext and the tap doesn’t come from the reverse proxy but from the links behind the reverse proxy.

Recommendations for SSL Decryption Zeekcryption

What is the best method? For traffic destined to servers you control (ie incoming traffic), I recommend method 3 or method 4 as it is easier to manage certificates and keys in one location. Method 4 is nice because you don’t have to worry if the right policies are in place to forward the traffic to Zeek, but the drawback is you usually have to adjust your monitoring and scripts to consider X-Forwarded-For headers instead of the typical source IP address. Method 2 does work for traffic destined to your servers, but be prepared to put in a little more effort to make it work.

For traffic from clients you control (ie outgoing traffic), your only enterprise option is method 2. Once setup, this will require at least as much maintenance as URL filtering does for your organization.

Of course, the best method really depends on the organization and its systems. Architects and engineers should adapt the methods as appropriate and accept the trade-offs.

Just as you should let Zeek to what it does best, let the other tools in your network do what they do best. Offload decryption to them and let Zeek analyze the data—Zeekryption.

Note: I do use Zeek, but my views are my own and do not necessarily represent the views and opinions of the Zeek leadership team or the community as a whole.