Alert Logic and Diffie-Hellman

The Alert Logic® network intrusion detection system (IDS) monitors and analyzes network traffic and generates alerts in response to activity that either matches known patterns of malicious activity or is anomalous. To perform this analysis, Alert Logic must have the ability to monitor and decrypt network traffic. While Diffie-Hellman is often used and enabled by default as an encryption protocol, using Diffie-Hellman prevents Alert Logic from monitoring and decrypting the traffic, therefore preventing detection of malicious activity.

To explain why Diffie-Hellman cannot be decrypted, it is necessary to discuss the elements involved and describe how Diffie-Hellman secures communication between two parties. This article also details recommendations from Alert Logic to allow visibility into traffic within trusted zones of your environment, making detection of malicious activity possible.

In This Article

• Network Intrusion Detection
• SSL/TLS Session Key
• Why the Network IDS Does Not Support Diffie-Hellman
• Options for Encryption with Alert Logic
• How to Find Out if a Server Supports Diffie-Hellman

Network Intrusion Detection

The network IDS has the capability to decrypt and inspect HTTPS/TLS traffic for connection endpoints (servers) within the customer's environment. This capability does not inspect traffic from clients inside the environment to endpoints outside the customer's environment, such as when desktop users connect to external secure websites. This type of traffic inspection is outside the scope of an IDS solution and is often done by HTTPS/TLS inspection solutions that insert themselves as an inline middleman (proxy) between clients and servers.

In order to address the complexity of detecting attacks, Alert Logic has invested heavily in machine learning that highlights the types of attacks difficult to do with signatures. One huge area of improvement has been enabled by capturing wider vectors of telemetry data that allows Alert Logic to inspect a broader set of potentially malicious activity. The importance of this improvement in detection is that as attackers get smarter, more visibility and telemetry are needed to detect a breach or signs of attack.

Telemetry signatures are used solely to gather data. Alert Logic takes the data in, analyzes it, and then works out how to better improve our coverage. The signatures are short-lived, typically lasting one to two weeks. This is not possible without getting access to the network traffic.

SSL/TLS Session Key

In the context of SSL/TLS, a session key is an ephemeral key used to encrypt and decrypt traffic that is sent over an SSL/TLS connection.

Most key agreement protocols, like the RSA protocol, work by sharing the session key by sending it from one party to the other over the network. The session key is encrypted with the public key of the server and can only be decrypted with the server private key. Anything that has the private key can decrypt the session key and use it to decrypt the rest of the traffic that is part of the session. Therefore, having the certificate and private key for a server allows the network IDS and web application IDS to inspect SSL/TLS traffic.

Why the Network IDS Does Not Support Diffie-Hellman

The Diffie-Hellman key agreement protocol, however, does not share the session key nor does it share all the values needed to compute the session key. Instead, it relies on a special mathematical relationship among several shared values and some secret (unshared) values that allows each party to independently compute the session key. This is what allows Diffie-Hellman to provide perfect forward secrecy and prevent man-in-the-middle attacks. So even if a third-party has the private key and inspects all the values shared between the client and server, it will not have all the values needed to compute the session key, and therefore will not be able to decrypt the traffic sent during the session.

This is why Diffie-Hellman is not supported as a key exchange protocol for the network IDS and web application IDS or any other solution that needs to passively inspect encrypted traffic. For a solution to be able to decrypt traffic that is using Diffie-Hellman, the solution would need to intercept and terminate the connection handshake and act as a middleman or proxy. This is what HTTPS inspection tools do. But the network IDS is not an inline solution, so it does not intercept connections.

Diffie-Hellman is the most secure key exchanged protocol and as such, it will generally be enabled by default. However, using Diffie-Hellman to encrypt all traffic eliminates the ability for monitoring, which is a key component of a modern security approach. When traffic is encrypted via Diffie-Hellman in trusted zones, such as your data center, you lose visibility to detect potentially malicious traffic inside the network.

Options for Encryption with Alert Logic

To allow for monitoring of internal traffic, Alert Logic recommends using a method of encryption in your trusted zones that allow inspection of traffic while limiting the ability to eavesdrop on traffic, such as the RSA protocol. It is ultimately up to you to determine your approach to encryption and where or whether to use the Diffie-Hellman protocol. However, Alert Logic recommends using one of the following options (listed in preferred order) to enable Alert Logic to capture SSL traffic and monitor for malicious activity:

1. Terminate the SSL with Diffie-Hellman at a load balancer, reverse-proxy, WAF or CDN, and then downgrade the cipher suites on the server to be RSA. Then upload the SSL certificate and key in the Alert Logic console to allow Alert Logic to decrypt the traffic successfully.
2. Terminate the SSL with Diffie-Hellman at a load balancer, reverse-proxy, WAF or CDN to the web server, so that the traffic is unencrypted in HTTP for monitoring.
3. (Not recommended if any other options are possible) Downgrade the cipher suites internally and externally to be RSA, with no usage of Diffie-Hellman. Then upload the SSL certificate and key in the Alert Logic console to allow Alert Logic to decrypt the traffic successfully. Note that downgrading the cipher suite may have compliance implications and whilst this is an option, it is not a recommendation.

If none of these options are suitable due to your organization policies, note that Alert Logic will be unable to provide event analysis on any traffic that is encrypted with the Diffie-Hellman key exchange protocol.

How to Find Out if a Server Supports Diffie-Hellman

One way to see if a server or endpoint supports Diffie-Hellman is to use the nmap tool with the option for the ssl-enum-ciphers script, as shown in the example below, to list all supported cipher suites. All cipher suites that list DH, DHE, or ECDHE use Diffie-Hellman.

Example