Applies To:
Show Versions
BIG-IP AAM
- 14.1.2, 14.1.0
BIG-IP APM
- 14.1.2, 14.1.0
BIG-IP Analytics
- 14.1.2, 14.1.0
BIG-IP Link Controller
- 14.1.2, 14.1.0
BIG-IP LTM
- 14.1.2, 14.1.0
BIG-IP PEM
- 14.1.2, 14.1.0
BIG-IP AFM
- 14.1.2, 14.1.0
BIG-IP DNS
- 14.1.2, 14.1.0
BIG-IP ASM
- 14.1.2, 14.1.0
SSL Traffic Management
About SSL offload
When you want the BIG-IP system to process application traffic over SSL, you can configure the system to perform the SSL handshake that destination servers normally perform. This ability for the BIG-IP system to offload SSL processing from a destination server is an important feature of the BIG-IP system.
The most common way to configure the BIG-IP system is to create a Client SSL profile, which makes it possible for the BIG-IP system to decrypt client requests before sending them on to a server, and encrypt server responses before sending them back to the client.
Within a Client SSL profile specifically, you can specify multiple certificate/key pairs, one per key type. This enables the system to accept all types of cipher suites that a client might support as part of creating a secure connection. The system then decrypts the client data, manipulates any headers or payload according to the way that you configured the Client SSL profile, and by default, sends the request in clear text to the target server for processing.
For those sites that require enhanced security on their internal network, you can configure a Server SSL profile. With a Server SSL profile, the BIG-IP system re-encrypts the request before sending it to the destination server. When the server returns an encrypted response, the BIG-IP system decrypts and then re-encrypts the response, before sending the response back to the client.
About client-side and server-side SSL profiles
You can manage the way that the BIG-IP system processes SSL application traffic by configuring two types of SSL profiles: A Client SSL profile, a Server SSL profile, or both. These profiles affect the way that the system manages SSL traffic passing through the system.
When you configure Client SSL or Server SSL profiles and assign them to a virtual server, the BIG-IP system offloads SSL processing from the destination server. This offloading not only conserves resource on destination servers, but enables the BIG-IP system to customize SSL traffic processing according to your configuration specifications.
Create a custom Client SSL profile
Create a custom Server SSL profile
Create a custom Client SSL profile that supports SM2
F5 has added SM2, SM3, and SM4 Cryptographic Algorithm support for the Chinese market. The algorithms were independently developed by the China State Cryptography Administration, where SM2 is the public key algorithm, SM3 is the hash algorithm, and SM4 is the block cipher algorithm. SM2 is based on the Elliptic Curve Discrete Logarithm Problem (ECDLP). Also see the following sections for details importing, exporting, and managing a certificate and key with SM2 license.
Before you create a customer Client SSL profile that supports SM2, create an SM2 cipher rule and cipher group.
Create an SM2 Cipher Rule
Create an SM2 Cipher Group
Create a Custom Client SSL Profile that supports SM2
Create a custom Client SSL profile that supports C3D
Create a custom Server SSL profile that supports C3D
Assign SSL profiles to a virtual server
About BIG-IP cipher support
The BIG-IP system includes a default cipher string named DEFAULT, which contains a subset of the cipher suites that the BIG-IP system supports.
The full set of cipher suites that the BIG-IP system supports are contained in the NATIVE cipher string. The cipher suites contained in both the DEFAULT and NATIVE cipher string are eligible for hardware acceleration.
The BIG-IP system supports a large set of cryptographic parameters that you can use to modify how the BIG-IP manages SSL/TLS connections.
With TLS 1.2, modifications to cipher suites can be made using the following cryptographic parameters:
- Key exchange algorithms, for example RSA or ECDHE.
- Authentication algorithms, for example RSA or ECDSA.
- Encryption ciphers, for example AES256 or CAMELLIA.
- Message authentication codes, for example SHA256 or SHA384.
Glossary of cipher-related terms
The BIG-IP system supports many cryptographic parameters used to negotiate SSL/TLS connections. The following list will help you understand how these parameters are organized on the BIG-IP system.
- Cipher Group
- A BIG-IP configuration object that specifies a list of cipher rules. The BIG-IP system offers several pre-built cipher groups, such as f5-default, f5-ecc, and f5-secure. You can use a pre-built cipher group or create a new custom cipher group. Cipher Groups can be associated with a Client or Server SSL profile's Cipher option to specify the allowed cryptographic parameters.
- Cipher rule
- A BIG-IP configuration object that specifies a list of cipher suites used to negotiate SSL/TLS connections. The BIG-IP system offers several pre-built cipher rules, such as f5-default, f5-ecc, and f5-secure. You can use a pre-built cipher rule or create a custom cipher rule. Cipher Rules are applied to Cipher Groups.
- Cipher string
- A BIG-IP named object that specifies a list of one or more cipher suites, for example DEFAULT or NATIVE. You can combine cipher strings to create the final cipher string that the BIG-IP system uses to negotiate SSL security parameters with another system. Cipher Strings can be associated with a Client or Server profile's Cipher option to specify the allowed cryptographic parameters.
- Cipher Suites
- A cipher suite is a combination of a key exchange method, authentication method, bulk encryption algorithm, and a message authentication code (MAC). The BIG-IP system uses cipher suites to negotiate the security parameters used to create SSL/TLS connections.
- Rule Audit
- The Rule Audit can be used when creating a custom Cipher Rule to display list of cipher suites contained in the cipher rule.
- Group Audit
- The Group Audit can be used when creating a custom Cipher Group, to display the list of cipher suites that will make up the final Cipher Group.
What is a cipher group?
A cipher group contains a list of cipher rules, and the instructions that the BIG-IP® system needs for building the cipher string it will use for security negotiation. The instructions tell the system which cipher rules to include in the string, and how to apply them (allow, restrict, or exclude, and in what order).
Pre-built cipher groups
The BIG-IP system offers a few pre-built cipher groups that you can choose from to use as is to build your final cipher string, However, it's common to create your own custom cipher group instead.
Custom cipher groups
This illustration shows an example of a custom cipher group. Using this cipher group, the BIG-IP system builds the final cipher string using a user-created custom cipher rule named /Common/my_ecdhe_rsa and the pre-built cipher rule /Common/f5-default.
Notice that the system will exclude from the string any cipher suites defined in the pre-built cipher rule /Common/f5-hw_keys.

About pre-built cipher groups
The BIG-IP system offers a set of pre-built cipher groups, with names containing the prefix f5-. Note that in general, a cipher group contains the cipher suites that you want to allow, restrict, or exclude when the system builds the cipher string used for SSL negotiation.
A pre-built cipher group allows all cipher suites specified in a corresponding pre-built cipher rule to be included in the final cipher string that the BIG-IP system builds for SSL negotiation. A prebuilt cipher group does not restrict the allowed cipher suites in any way, nor does it exclude any cipher suites.
This table lists and describes the pre-built cipher groups on the system.
Cipher group name | Description |
---|---|
f5-aes | Allows all cipher suites specified in the pre-built cipher rule f5-aes. |
f5-default | Allows all cipher suites specified in the pre-built cipher rule f5-default. |
f5-ecc | Allows all cipher suites specified in the pre-built cipher rule f5-ecc. |
f5-hw_keys | Allows all cipher suites specified in the pre-built cipher rule f5-hw_keys. |
f5-secure | Allows all cipher suites specified in the pre-built cipher rule f5-secure. |
About custom cipher groups
This illustration shows an example of a custom cipher group. Using this cipher group, the BIG-IP system builds the final cipher string using a user-created custom cipher rule named /Common/my_ecdhe_rsa and the pre-built cipher rule /Common/f5-default.
Notice that the system will exclude from the string any cipher suites defined in the pre-built cipher rule /Common/f5-hw_keys.

Also notice that the cipher group displays a preview of the final cipher string after the instructions are applied.
Building a custom Cipher Group
You build a final, custom cipher string by creating a cipher group. A cipher group contains the cipher rules and instructions that the BIG-IP system needs for building the cipher string it will use for security negotiation with a client or server system.
What is a cipher rule?
A cipher rule is an object that contains a list of cipher suites. After you create a cipher rule, you specify it within a cipher group. A cipher group is the object that builds the actual cipher string that the system will use during SSL negotiation.
You can use pre-defined cipher rules that the BIG-IP system provides, or you can create your own.
An example of a cipher rule might be one that specifies only cipher suites that use a particular bulk encryption algorithm and key exchange method.
About pre-built cipher rules
Pre-built cipher rules
The BIG-IP system offers a set of pre-built cipher rules, with names containing the prefix f5-. This table lists these cipher rules and the cipher strings they represent.
Cipher rule name | Associated cipher string |
---|---|
f5-aes | AES |
f5-default | DEFAULT |
f5-ecc | ECDHE:ECDHE_ECDSA |
f5-hw_keys | ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-CBC-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH |
f5-secure | ECDHE:RSA:!SSLV3:!RC4:!EXP:!DES |
About custom cipher rules
You can use the following cryptographic parameters to create custom cipher rules:
- Cipher suites
- These represent the bulk encryption and hash algorithms used to negotiate SSL/TLS connections. An example of a cipher suite is ECDHE-RSA-AES128-CBC-SHA.
- DH groups
- In TLS1.3, these are the Elliptic Curve Diffie Hellman (ECDH) key agreement algorithms used to negotiate SSL/TLS connections. The available key agreement curves are: P256, P384, and X25519.
- Signature algorithms
- In TLS1.3, these are the digital signature algorithms for authentication. Examples of signature algorithms are rsa_pkcs1_sha256 and ecdsa_secp256r1_sha256.
Create a custom cipher rule
When you create your own cipher rules for inclusion in a custom cipher group, the BIG-IP system builds a cipher string that includes or excludes the cipher suites and algorithms needed for negotiating SSL connections.
About the DEFAULT and NATIVE cipher strings
The DEFAULT cipher string appears as the default value in the Ciphers setting of the Client SSL and Server SSL profiles and represents a subset of the cipher suites found in the NATIVE cipher suite.
The NATIVE cipher string represents the full set of BIG-IP supported cipher suites.
Both the DEFAULT and NATIVE cipher strings represent cipher suites that are eligible for hardware acceleration.
Viewing cipher suites in the DEFAULT and NATIVE cipher strings
Follow these steps to display the cipher suites associated with the DEFAULT cipher string. This list of cipher suites is also included in the pre-built cipher rule f5-default.
- Using an SSH client application such as PuTTY, access the advanced shell on the BIG-IP system.
- At the system prompt, to view the DEFAULT cipher suites used for client-side negotiation, type the command tmm --clientciphers DEFAULT.
- At the system prompt, to view the DEFAULT cipher suites used for server-side negotiation, type the command tmm --serverciphers DEFAULT.
Best practices for BIG-IP cipher strings
For security and performance reasons, consider the following recommendations:
- When modifying cipher suites, F5 strongly recommends that you append cipher suite modifications to the DEFAULT cipher string.
- Include a cipher string that specifies the ECC key type. Due to their smaller size, ECC keys reduce computing costs while maintaining a similar level of security.
- Disable ADH ciphers but also include the keyword HIGH. To do this, just include both !ADH and :HIGH in your cipher string.
- For AES, DES, and RC4 encryption types, make sure you specify the DHE key exchange method. DHE uses perfect forward secracy, which creates an ephemeral private key for each new secure connection. This ensures the same private key is never used twice.
- When you use DHE, make sure that the SSL private key isn't being shared with a monitoring system or a security device like an intrusion detection or prevention system. And by the way, diagnostic tools like ssldump won't work when you're using Forward Secrecy.
About Diffie-Hellman Ephemeral key exchange
The BIG-IP system supports the Diffie-Hellman Ephemeral key exchange method, as well as other Diffie-Hellman variations. A Diffie–Hellman key exchange method is an alternative to RSA key exchange and allows the client and the BIG-IP system to establish a shared secret session key to use for communication.
About DHE key exchange
Because Diffie-Hellman key exchange methods do not include authentication, use of Diffie-Hellman Ephemeral (DHE) requires that it be paired with an authentication mechanism. The DHE key exchange/authentication pairs that the BIG-IP system supports are:
- DHE-RSA-* (Diffie-Hellman Ephemeral-RSA)
- DHE-DSS-* (Diffie-Hellman Ephemeral-DSS)
- ECDHE-RSA-* (Elliptic Curve Diffie-Hellman Ephemeral-RSA)
- ECDHE-ECDSA-* (Elliptic Curve Diffie-Hellman Ephemeral-DSA)
About Perfect-Forward-Privacy
The Diffie-Hellman Ephemeral (DHE) key exchange method provides Perfect Forward Privacy (PFP). With standard Diffie-Hellman, multiple key exchanges all use the same session key, which can compromise security. By contrast, DHE uses PFP, which generates a disposable key per session and thereby ensures that the same session key is never used twice. No key remains to be disclosed, and if the private key of the server is discovered, past communication remains secure.
Supported Diffie-Hellman variations
The BIG-IP system supports all three Diffie-Hellman key exchange methods. They are:
- Diffie-Hellman Ephemeral (DHE)
- Diffie-Hellman Ephemeral uses temporary public keys. The authenticity of a temporary key can be verified by checking the digital signature included in the key exchange messages. The key exchange messages are signed using either the RSA or DSA algorithms, depending on the cipher being used. For example, DHE-RSA uses RSA to sign the key exchange messages. DHE includes Perfect Forward Secrecy (PFS), which means that a compromise of the system's long-term signing key does not affect the privacy of past sessions. Like FIPS, DHE prevents private key disclosure.
- Diffie-Hellman (DH)
- Diffie-Hellman embeds the system's public parameter in the certificate, and the CA then signs the certificate. That is, the certificate contains the Diffie-Hellman public-key parameters, and those parameters never change.
- Anonymous Diffie-Hellman (ADH)
- Anonymous Diffie-Hellman uses DH, but without authentication. The keys used in the exchange are not authenticated, resulting in keys being susceptible to security attacks.
Viewing a list of supported DHE ciphers
Specifying a Diffie-Hellman key exchange method
Viewing DHE key exchange statistics

Sample profile statistics for key exchange method
About Elliptic Curve encryption
The BIG-IP system supports Elliptic Curve Cryptography (ECC). Because Elliptic Curve key sizes are significantly smaller than those of other key types, ECC is ideally suited for smaller, mobile devices for which key storage is an issue. On the BIG-IP system, ECC works with the SSL offload feature.
About Elliptic Curve cipher support
The BIG-IP system supports multiple ciphers that use Elliptic Curve Cryptography (ECC) encryption with Diffie-Hellman key exchange. On the BIG-IP system, EC is used with DHE to establish the shared secret; however, the subsequent bulk encryption of data cannot be done with any ECC-based algorithm and must be done using conventional crypto algorithms such as AES and 3DES. For example, a typical Elliptic Curve cipher is: ECDHE-RSA-AES128-CBC-SHA.
The specific ECC ciphers that the BIG-IP system supports are:
- ECDHE-RSA-*
- ECDHE-ECDSA-*
- ECDH-ECDSA-*
Because ECC with Diffie-Hellman does not include a mechanism for digitally signing handshake messages, the RSA or DSA algorithms are used to digitally sign the handshake messages to thwart Man-in-the-Middle attacks. For example, an ECDHE-ECDSA-* cipher suite uses the ECC DSA certificate specified in the Client SSL profile to digitally sign the handshake messages.
Viewing ECDH key exchange statistics

Sample profile statistics for key exchange method
Specifying an Elliptic Curve Diffie-Hellman key exchange method
Unsupported cipher suites on the BIG-IP system
For security reasons, these cipher suites are unavailable in the BIG-IP system:
- EXP-EDH-RSA-DES-CBC-SHA
- EXP-ADH-DES-CBC-SHA
- EXP-RC2-CBC-MD5
- EXP-ADH-RC4-MD5
About cipher keywords on the BIG-IP system
There are a few things you should know when specifying keywords to create a BIG-IP cipher string. These things apply whether or not you are creating a cipher string using cipher rules and groups or typing a raw cipher string into an SSL profile.
About the COMPAT cipher string
In previous BIG-IP releases, cipher support included the COMPAT cipher string, allowing the use of OpenSSL cipher suites not natively supported by the BIG-IP. In this release, the COMPAT cipher string has been removed.
If your configuration includes the COMPAT cipher string, it will be replaced with NONE and secure connections relying on these cipher suites will fail.
This change:
- Optimizes the security of your cipher configuration by preventing any OpenSSL cipher suite vulnerabilities from being introduced into the BIG-IP system.
- Changes the meaning of the NATIVE keyword; this keyword now equivalent to the keyword ALL.
Invalid keywords for BIG-IP cipher strings
When you manually configure a cipher string on the BIG-IP system (as opposed to using a cipher group), these keywords are invalid:
- COMPAT
- SSLV2 (a subset of COMPAT)
- RC2 (a subset of COMPAT)
- Any other subsets of COMPAT or SSLv2
If you attempt to specify these keywords within a cipher string, the system displays an error message and prevents you from creating the relevant SSL profile.
Changes to BIG-IP cipher keywords during a system upgrade
During a BIG-IP software upgrade to version 14.0 or higher, the system takes these actions:
- If the system detects the keywords COMPAT, SSLv2, RC2, or any subset of these in an existing cipher string, the system logs a message in the file /var/log/ltm and changes any of these keywords to None.
- The system treats the keyword NATIVE as being equivalent to keyword ALL.
- If a cipher string evaluates to an empty set, the system remaps the string to the default cipher string, represented by the keyword DEFAULT. The default cipher string contains a subset of the cipher suites that are suitable for most SSL connections.