TL,DR: using this product strictly as recommended most likely violates your compliance rules. This is not because of the Diffie-Hellman aspect, but I still wouldn't use it, partly because the DH aspect demonstrates an insecure architecture and partly because other aspects of the documentation demonstrates an awful lack of concern for security.
There are several different ways a TLS handshake can work. Considering the common case where the server is willing to talk to anyone, but the client wants to talk to a specific server, the handshake has two functional goals:
- Allow the client to verify that it's talking to the intended server.
- Allow the two parties to agree on a session key (the key exchange part).
The key exchange has a security goal, which is that a man-in-the-middle who is capable of observing and modifying the communication cannot impersonate the server or obtain the session key.
The server first sends its public key to the client, plus some additional data (certificates) which allow the client to verify that the public key is the correct one for this server, thanks to PKI. At this stage, the client knows the public key of the legitimate server (or else it detects that it's been sent a fake key and closes the connection), but it still can't trust what it receives since an attacker might have modified the data.
After this, there are three ways to go. (See also What key exchange mechanism should be used in TLS? for a more technical discussion.)
- Encryption: the client generates a session key and encrypts that with the legitimate server's public key (confirmed by PKI). Only the legitimate server can detect it, a man-in-the-middle can't, because it doesn't have the server's private key. This happens with ciphersuites that have
RSA in their name but not DHE. Apache's category RSA designates these ciphersuites.
- Signature: the client and the server use a Diffie-Hellman to exchange data in such a way that both sides are able to calculate the same session key, but a man-in-the-middle cannot find the intended session key. A man-in-the-middle attacker may be able to modify the data to cause the two sides to calculate different session keys that the attacker knows, however. To avoid this, the server sends a signature of the data exchange during the handshake, in such a way that when the client verifies this signature, it knows that the server used the same data to generate its session key. The attacker cannot fake this signature because it doesn't know the server's private key. This happens with ciphersuites that have
DHE in their name (including ECDHE). The E in DHE stands for “ephemeral”, because the Diffie-Hellman algorithm is used to generate a single-use session key. The signature part may be RSA or ECDSA. Apache's category EDH designates these ciphersuites.
- Key exchange: there are ciphersuites that use static Diffie-Hellman private keys, but basically nobody uses them so I won't discuss them any further.
Now consider what happens if the attacker can observe the traffic but not modify it, and additionally knows the server's private key. With the first method, they can decrypt the packet containing the encrypted session key. With the second method, they can't do anything. An active attacker who knows the server's signing key can impersonate the server during the handshake, which leads to a valid TLS session between the server and the attacker and another valid TLS session between the attacker and the client. But an attacker who can't or won't modify traffic can't do this.
This property of the second method is called perfect forward secrecy (PFS), because if the attacker manages to record traffic and then later manages to obtain the server's key, they still won't be able to decrypt the recorded traffic. They'd need to know the secret parts of the Diffie-Hellman key exchange, but the participants erase them as soon as the handshake is over.
That middlebox apparently wants to monitor the traffic that the server is serving, but not actively forward it. It would need to know the server's private key, otherwise the whole thing is pointless. So the instructions are to disable all the ciphersuites that use ephemeral Diffie-Hellman, i.e. all the ciphersuites with PFS, and keep only the ones RSA-encryption ciphersuites.
This is a terrible way to monitor traffic, because it's degrading security. PFS is not needed to ensure the basic security of TLS, but it is a good thing since it limits the impact of a compromised private key. In particular, a private key becomes useless once the corresponding certificate has expired or has been revoked (assuming that clients correctly check for expiration and revocation). Without PFS, a leaked old backup allows decrypting old traffic. Additionally, this setup requires copying the server's private key to another box, which increases the risk that the private key will leak.
The proper place to monitor traffic would be on the server itself, between the application and the TLS endpoint. I guess this product is designed this way because it makes deployment easier, but it's a terrible design.
In addition to disabling PFS, those instructions enable export ciphers, low-security ciphers such as single DES, and SSLv2. I don't know how old this product is, but even in 2005, which is when Apache 2.2 and RHEL4 (mentioned on the product's web page) came out, all three were obsolete, to be enabled only if you really absolutely had to talk to ancient clients. Enabling any of those three today would violate any cryptographic compliance standard.
