Disable forward secrecy for a SSL Profile

I'm attempting to troubleshoot a VIP for which I am unable to decrypt traffic due to these ephemeral ciphers. Is !DHE:!ECDHE still sufficient for the purposes of disabling any and all ciphers that cannot be decrypted with the appropriate private key alone?

ok i understand, thanks a lot for explain me that !

EDH and DHE are confusingly synonymous, and naming is completely dependent on the cipher engine. If you look at the supported ciphers on the BIG-IP:

tmm --clientciphers 'ALL'

You won't see EDH, but you will see DHE. But to your question, EDH and DHE are both the same thing and therefore ephemeral (perfect forward secret). And since the BIG-IP's crypto engine doesn't call it EDH you just need to remove DHE (and ECDHE) from the available ciphers.

Thanks for your answer.

It's because a service use a man in the middle tools and they don't see traffic when i use forward secrecy.. If i use "DEFAULT:!ECDHE:!DHE", this cipher suite (DHE-RSA-AES256-GCM-SHA384) are disable too ? Because the Key Exchange is EDH not DHE.

Forward secrecy is available via DHE and ECDHE ciphers. The last "E" stands for "ephemeral", which is what provides PFS. At a minimum you can simply take the DEFAULT stack and remove these:

DEFAULT:!ECDHE:!DHE

which would leave you with nothing but non-ephemeral RSA ciphers. You can see this list with the tmm --clientciphers command:

tmm --clientciphers 'DEFAULT:!ECDHE:!DHE'

But perhaps the more important question is why? An RSA key exchange algorithm is said to be non-PFS because the RSA keys are used for both authentication and encryption. If an adversary records all of your encrypted messages, and then some time later (potentially many years later) your RSA private key is compromised, every one of those records conversations can be decrypted. That's essentially because the client sends a pre-master secret to the server encrypted with the server's public key. Knowledge of the server's private key can then expose the PMS, the other two random values are always sent in the clear anyway, so any message can be decrypted. With a Diffie-Hellman key exchange, an RSA (or ECDSA) key is only used for authentication, as the client need not encrypt anything to the server for the two parties to derive a share symmetric key. Doing this key exchange for every connection and not storing previous session keys is what makes it ephemeral and perfect forward secret. So then back to the question. It's completely understandable that there may be clients that don't support PFS ciphers, but in an SSL handshake the client will first send what it can support, and the server will choose from one of those ciphers. The BIG-IP's client SSL profile ciphers option is what helps it "pick" from the client's list. If some clients do support PFS ciphers, it's really a best practice to allow them to do that. You can include PFS and non-PFS ciphers in your client SSL profile, and simply prefer PFS ciphers. Any client that doesn't support PFS won't send any in its cipher list.