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.
For TLS 1.2 and TLS 1.3, you can configure all or some of the cryptographic
parameters:
Ciphersuites.
Key exchange algorithms, for example RSA, DH, or ECDHE.
Signature algorithms, for example RSA or ECDSA.
Encryption primitives, for example AES128 or CAMELLIA.
Hash algorithms, for example SHA256.
Message authentication codes, for example HMAC-SHA256 or
HMAC-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
.
Also notice that the cipher group displays a preview of the final cipher
string after the instructions are applied.
To create a custom SM2 cipher group to use when
creating a custom client SSL profile that supports SM2, see the
Create a custom Client
SSL profile that supports SM2
section for task details. This section also provides
information on creating a custom SM2 cipher rule.
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.
Descriptions of the pre-built cipher groups
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
Before starting this task, make sure you've confirmed the need to create a custom
cipher string instead of using a pre-built 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.
To create a custom SM2 cipher group to use when creating a custom client SSL
profile that supports SM2, see the
Create a custom Client SSL profile that
supports SM2
section for task details. This section also provides
information on creating a custom SM2 cipher rule.
On the Main tab, click
Local Traffic
Ciphers
Groups
.
The screen displays a list of
pre-built cipher groups.
Click
Create
.
In the
Name
field, type a name for
the cipher group.
Never include the prefix
f5-
in a cipher rule
name. This prefix is reserved for pre-built cipher groups
only.
If you created any custom rules, then in the
Cipher Creation area of the screen in the
Available Cipher Rules
list,
verify that the custom rules appear in the list.
For each cipher rule in the
Available Cipher Rules
list,
click the plus sign to view the cipher suites included in the rule.
For example,
this shows the cipher suites included in the pre-built cipher rule named
/Common/f5-ecc
.
In the
Available Cipher Rules
list,
select the boxes for the cipher rules you want to allow for negotiating security
for SSL connections.
We strongly recommend that you select the cipher rule
/Common/f5-default
, and for added security, select other
cipher rules, too.
Here's an
example of a list of available cipher rules that you might see within a
cipher group. Notice that we've selected both a pre-built cipher rule and a
custom cipher rule:
In the
Group Details
setting, move the selected cipher rules to the
Allow the following
box.
Here we see
that we're instructing the BIG-IP system to allow, during security
negotiation, the cipher suites contained in the selected cipher
rules:
Again from the
Available Cipher Rules
list,
select the boxes for the cipher rules you want to restrict the allowed cipher
rules to when negotiating security for SSL connections.
Move the selected cipher rules to the
Restrict the Allowed list to the
following
box.
If you want to exclude any cipher rules from the
allowed list, then from the
Available Cipher Rules
list, select the boxes for the rules you
want to exclude.
Move the selected cipher rules to the
Exclude the following from the Allowed
list
box.
From the
Order
list, select the order
that you want the BIG-IP system to use when negotiating SSL connections.
The choices are:
Default
,
Speed
,
Strength
,
FIPS
, and
Hardware
.
In the
Cryptographic Parameters
box, view the
cipher suites that the BIG-IP system will use to construct the final cipher string, based on the selections you
made in the previous steps.
Click
Finished
.
After you complete this task, the BIG-IP system has a custom cipher group that the
BIG-IP system will use to build the final cipher string.
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.
DH Groups and Signature Algorithms allow modification of TLS
1.2 and 1.3 key agreements and signature algorithms respectively.
To create a custom SM2 cipher rule to use when creating a custom client SSL profile that
supports SM2, see the
Create a custom Client SSL profile that supports SM2
section for task details.
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.
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 TLS 1.2 and 1.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 TLS 1.2 and 1.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.
To create a custom SM2 cipher rule to use when creating a custom client SSL
profile that supports SM2, see the
Create a custom Client SSL profile that
supports SM2
section for task details.
On the Main tab, click
Local Traffic
Ciphers
Rules
.
The screen displays a list of
pre-built cipher rules.
Click
Create
.
In the
Name
field, type a name for
the cipher rule.
Never include the prefix
f5-
in a cipher rule
name. This prefix is reserved for pre-built cipher rules only.
For
example:
In the
Cipher Suites
field, type one
or more cipher suites.
For
example:
In the
DH Groups
field, type one or more Elliptic Curve Diffie-Hellman key exchange algorithms, separated by commas (:).
The available named groups (formerly known as
curves
) are:
secp256r1
,
secp384r1
, and
X25519
. You can also type a special keyword,
DEFAULT
, which represents the recommended set of named groups.
For example, you can specify
secp256r1:X25519
.
In the
Signature Algorithms
field, type one or more signature algorithms, separated by commas (:), that you want to include in the cipher rule. You can also type a special keyword,
DEFAULT
, which represents the recommended set of signature algorithms.
The available signature algorithms are:
DSA-SHA1
,
DSA-SHA256
,
DSA-SHA384
,
DSA-SHA512
,
ECDSA-SHA1
,
ECDSA-SHA256
,
ECDSA-SHA384
,
ECDSA-SHA512
,
RSA-PKCS1-SHA1
,
RSA-PKCS1-SHA256
,
RSA-PKCS1-SHA384
,
RCS-PKCS1-SHA512
,
RSA-PSS-SHA256
,
RSA-PSS-SHA384
, and
RSA-PSS-SHA512
.
For example, you can specify
RSA_PKCS1_SHA256:ECDSA_P256_SHA256
.
Click
Finished
.
The cipher rule now appears within any custom cipher group, in the list of available cipher rules.
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.
We strongly recommend that you use the default cipher string and, for added security, append
other cipher suites to it.
Viewing cipher
suites in the DEFAULT and NATIVE cipher strings
Before you use this command, confirm that your BIG-IP user account grants you access to
the advanced shell.
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 key
exchange methods, when paired with RSA and DSS authentication, are not included in the
cipher rule
f5-default
nor in the
cipher keyword
DEFAULT
.
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
Before using this command, confirm that your user account grants you access to the advanced shell.
You perform this task when you want to display a specific set of ciphers that the
BIG-IP system supports.
Access the advanced shell on the BIG-IP system.
At the system prompt, type the command
tmm --clientciphers
ciphers
.
For example, to see a list of DHE+DES ciphers, type
tmm --clientciphers DHE:DHE_DSS
. To see a list of ECDHE ciphers, type
tmm --clientciphers ECDHE:ECDHE_ECDSA
.
Specifying a Diffie-Hellman key exchange method
Use this task to modify an existing Client SSL profile to enable support for
Diffie-Hellman key exchange.
On the Main tab, click
Local Traffic
Profiles
SSL
Client
or
Local Traffic
Profiles
SSL
Server
.
The Client SSL or Server SSL profile list screen opens.
In the Name column, click the name of the profile
you want to modify.
Select the
Custom
check box.
The settings become available
for change.
To specify DHE ciphers:
From the
Configuration
list,
select
Advanced
.
For the
Ciphers
setting,
click
Cipher
String
and type
DHE:DHE_DSS
.
Click
Update
.
After you perform this task and assign the profile to a virtual server, the BIG-IP uses the DHE key exchange method to establish secure communication with the relevant client or server.
Viewing DHE key exchange statistics
You can use the Traffic Management Shell (tmsh) to view statistics about the use
of Diffie-Hellman ciphers in SSL negotiation.
Access the system prompt on the BIG-IP system.
From the BIG-IP system prompt, type
tmsh show ltm profile client-ssl
profile_name
.
An example of a name for a profile that specifies DHE ciphers is
my_dhe_profile
.
After you type this command, the BIG-IP system displays output such as the following. In this example, the profile statistics show that Diffie-Hellman Ephemeral (DHE) with RSA certificates has been used once:
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.
Elliptic
Curve ciphers with DSA are not included in the
DEFAULT
cipher suite.
Viewing ECDH key exchange statistics
You can use the Traffic Management Shell (tmsh) to view statistics about the use
of Elliptic Curve Diffie-Hellman ciphers in SSL negotiation.
Access the system prompt on the BIG-IP system.
From the BIG-IP system prompt, type
tmsh show ltm profile client-ssl
profile_name
| grep ECDH.
An example of a name for a profile that specifies DHE ciphers is
my_ecdh_profile
.
After you type this command, the BIG-IP system displays output such as the
following. In this example, the profile statistics show that ECDH with RSA certificates
has been used six times:
Sample profile statistics for key exchange method
Specifying an Elliptic Curve Diffie-Hellman key exchange method
Use this task to modify an existing Client SSL profile to enable support for
Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.
On the Main tab, click
Local Traffic
Profiles
SSL
Client
or
Local Traffic
Profiles
SSL
Server
.
The Client SSL or Server SSL
profile list screen opens.
In the Name column, click the name of the profile
you want to modify.
Select the
Custom
check box.
The settings become available
for change.
For the
Ciphers
setting, click
Cipher
String
and type
DEFAULT:ECDHE
.
Click
Update
.
After you perform this task and assign the profile to a virtual server, the BIG-IP
system uses the ECDHE key exchange method to establish secure communication with the
relevant client or server.
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.
If you have an SSL profile in a previous BIG-IP version and
then upgrade to version 14.0 or higher, the system automatically resolves the issue
for you.
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.
