The Alert Logic® network intrusion detection system (IDS) requires a different configuration to decrypt Diffie-Hellman. To explain why Diffie-Hellman cannot be decrypted in the same manner, it is necessary to discuss the elements involved and describe how Diffie-Hellman secures communication between two parties. This article also details the math supporting Diffie-Hellman.
In This Article
- Network Intrusion Detection
- SSL/TLS Session Key
- Why the Network IDS Does Not Support Diffie-Hellman
- How to Find Out if a Server Supports Diffie-Hellman
- The Math Behind 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.
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. It may seem a bit ironic that Alert Logic solutions require the use of less robust protocols so that they can perform their function of detecting threats, but the trade-off is considered justified. The benefit of being able to inspect and detect threats in encrypted traffic outweighs any possible downsides to not using Diffie-Hellman.
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.
nmap --script ssl-enum-ciphers -p <port> <IP address/hostname>
$ nmap --script ssl-enum-ciphers -p 443 10.54.42.11
Starting Nmap 7.31 ( https://nmap.org ) at 2017-01-19 14:53 CST
Nmap scan report for 10.54.42.11
Host is up (0.00058s latency).
PORT STATE SERVICE
443/tcp open https
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| cipher preference: server
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
|_ least strength: C
MAC Address: 12:34:56:78:9A:BC (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 0.45 seconds
The Math Behind Diffie-Hellman
The following is the math that is used by the Diffie-Hellman key exchange protocol to calculate a key. This shows that the two values needed (c and d) to calculate the key are never shared; therefore, the protocol is not susceptible to a man-in-the-middle intercepting the key or all the values needed to calculate it.
Alice picks two prime numbers g and p and shares them with Bob.
Alice then picks a secret number c and calculates A = gc mod p. And Alice shares the number A with Bob. Bob then picks his own secret number d and calculates B = gd mod p. And Bob shares the number B with Alice.
Alice takes B and calculates kA = Bc mod p.
And Bob takes A and calculates kB = Ad mod p.
A = gc mod p
B = gd mod p
kA = Bc mod p
kB = Ad mod p
Since B = gd mod p
Bc mod p = gdc mod p
Since A = gc mod p
Ad mod p = gcd mod p
Therefore, kA = kB
Any third party observer will be unable to derive the shared key.