Disable forward secrecy for a SSL Profile

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.