Manual Chapter : SSL Traffic Management

Applies To:

Show Versions Show Versions

BIG-IP DNS

  • 13.1.3, 13.1.1, 13.1.0

BIG-IP Analytics

  • 13.1.3, 13.1.1, 13.1.0

BIG-IP AFM

  • 13.1.3, 13.1.1, 13.1.0

BIG-IP PEM

  • 13.1.3, 13.1.1, 13.1.0

BIG-IP ASM

  • 13.1.3, 13.1.1, 13.1.0

BIG-IP AAM

  • 13.1.3, 13.1.1, 13.1.0

BIG-IP Link Controller

  • 13.1.3, 13.1.1, 13.1.0

BIG-IP APM

  • 13.1.3, 13.1.1, 13.1.0

BIG-IP LTM

  • 13.1.3, 13.1.1, 13.1.0
Manual Chapter

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.

About client certificate constrained delegation

The BIG-IP® system uses Client Certificate Constrained Delegation (C3D) to support complete end-to-end encryption when interception of SSL traffic in a reverse proxy environment is required and when client certificates are used for mutual authentication.

When the BIG-IP receives a client certificate request from a backend server, the BIG-IP sends a forged copy of the client certificate. This maintains a full proxy approach and allows complete end-to-end encryption when intercepting SSL traffic in reverse proxy scenarios.

When enabling C3D and creating your custom Client or Server SSL profiles, follow these requirements:
  • Make sure you have a certificate authority bundle that will contain the root or intermediate CA certificates needed to validate any expected clients.
  • Make sure you have the normal server certificate(s) and key(s) needed for the reverse proxy virtual server.
  • Make sure you have a certificate authority and key that has been enabled to create new certificates (must be RSA and allow certificate creation). This will be used to forge the client certificates.
When creating a custom Client SSL profile with C3D enabled, use these tips to ensure a successful configuration and enablement. See the Creating a custom Client SSL profile section for complete configuration steps.
  • The server certificate and key (and chain, if needed) should be configured in the profile. See Step 8 in Creating a custom Client SSL profile.
  • Client certificate authentication must be set to either request or require so to ensure you are receiving that certificate from the client. See Step 13 in Creating a custom Client SSL profile.
  • Make sure to configure the certificate authority list that you will send to the client and defines the trusted root and intermediate CAs that are accepted and validated against. See Step 14 in Creating a custom Client SSL profile.
  • Enable the C3D feature. See Step 15 and 16 in Creating a custom Client SSL profile.
  • If you are using OCSP, you can select the OCSP object. See Step 17 in Creating a custom Client SSL profile.
  • If you are using OCSP and the OCSP response is unknown, you can select to either drop or ignore it in the Unknown OCSP Response Control field. If you select ignore, the unknown response will still be sent to the server (which may decide to drop it as well). See Step 18 in Creating a custom Client SSL profile.
When creating a custom Server SSL profile with C3D enabled, use these tips to ensure a successful configuration and enablement. See the Creating a custom Server SSL profile section for complete configuration steps.
  • Make sure you have set up and enabled a certificate and key for the server (these certificates can be the default ones, if necessary). See Steps 6 through 8 in Creating a custom Server SSL profile.
  • Set the server authentication frequency to always. This ensures that a new client certificate is used for each conversation. See Step 13 in Creating a custom Server SSL profile.
  • Enable the C3D feature. See Steps 15 through 17 in Creating a custom Server SSL profile.
  • Specify the certificate authority and key used to forge the certificates. See Step 18 and Step 19 in Creating a custom Server SSL profile.
  • Define the certificate lifespan of the forged certificates. See Step 22 in Creating a custom Server SSL profile.
    Note: Because the system does not cache forged certificates, you can set the Certificate Lifespan fields to the expected duration of any single connection.
  • Select the certificate extensions you want to carry over from the original client certificate. Any extensions that are not defined in either the enabled or available extension fields will be stripped from the forged certificate. See Step 23 and Step 24 in Creating a custom Server SSL profile.
  • If you want to add extensions that are not listed above, you can add the object identifier as a custom extension. See Step 24 in Creating a custom Server SSL profile.
Note: Enabling C3D may impact your system performance since the forged client certificates are not cached.
Note: Optionally, you can use OCSP configuration to validate client certificates and need to have a valid OCSP object (configured in the Certificate Management section for both custom client and server SSL profiles).

Creating a custom Client SSL profile

After you have built the cipher string that you want the BIG-IP® to use to negotiate client-side SSL connections, you create a custom client SSL profile. You create the profile when you want the BIG-IP® system to terminate client-side SSL traffic for the purpose of decrypting client-side ingress traffic and encrypting client-side egress traffic. By terminating client-side SSL traffic, the BIG-IP system offloads these decryption/encryption functions from the destination server. When you perform this task, you can specify multiple certificate key chains, one for each key type (RSA, DSA, and ECDSA). This allows the BIG-IP system to negotiate secure client connections using different cipher suites based on the client's preference.
Note: At a minimum, you must specify a certificate key chain that includes an RSA key pair. Specifying certificate key chains for DSA and ECDSA key pairs is optional, although highly recommended.
Note: For detailed information on how to complete the client certificate constrained delegation (C3D) configuration and ensure that your custom client SSL profile is set up properly, see About client certificate constrained delegation before completing your custom profile setup.
  1. On the Main tab, click Local Traffic > Profiles > SSL > Client .
    The Client SSL profile list screen opens.
  2. Click Create.
    The New Client SSL Profile screen opens.
  3. In the Name field, type a unique name for the profile.
  4. From the Parent Profile list, select clientssl.
  5. Select the Custom check box.
    The settings become available for change.
  6. From the Configuration list, select Advanced.
  7. For the Mode setting, select the Enabled check box.
  8. For the Certificate Key Chain setting, click Add.
    1. From the Certificate list, select a certificate name.
      This is the name of a certificate that you installed on the BIG-IP® system. If you have not generated a certificate request nor installed a certificate on the BIG-IP system, and the BIG-IP system is not part of a device service clustering (DSC) configuration, you can specify the name of the existing certificate named default.
      Important: If the BIG-IP system is part of a DSC Sync-Failover group, always select a non-default certificate name, and ensure that this same certificate name is specified in every instance of this SSL profile in the device group. Taking these actions helps to ensure that SSL handshakes are successful after a failover event.
    2. From the Key list, select the name of the key associated with the certificate specified in the previous step.
      This is the name of a key that you installed on the BIG-IP® system. If you have not installed a key on the BIG-IP system, and the BIG-IP system is not part of a device service clustering (DSC) configuration, you can specify the name of the existing key named default.
      Important: If the BIG-IP system is part of a DSC Sync-Failover group, always select a non-default key name, and ensure that this same key name is specified in every instance of this SSL profile in the device group. Taking these actions helps to ensure that SSL handshakes are successful after a failover event.
    3. From the Chain list, select the chain that you want to include in the certificate key chain.
      A certificate chain can contain either a series of public key certificates in Privacy Enhanced Mail (PEM) format or a series of one or more PEM files. A certificate chain can contain certificates for Intermediate certificate Authorities (CAs).
      Note: The default self-signed certificate and the default CA bundle certificate are not appropriate for use as a certificate chain.
    4. For the Passphrase field, type a string that enables access to SSL certificate/key pairs that are stored on the BIG-IP system with password protection.
      This setting is optional. For added security, the BIG-IP system automatically encrypts the pass phrase itself. This pass phrase encryption process is invisible to BIG-IP® system administrative users.
    5. Click Add.
  9. In the Certificate Key Chain setting, click Add again, and repeat the process for all certificate key chains that you want to specify.
    At a minimum, you must specify an RSA certificate key chain.
    The result is that all specified key chains appear in the text box.
  10. To enable OCSP stapling, select theOCSP Stapling check box.
    To enable OCSP stapling, you must first create an OCSP Stapling profile. See Creating an OCSP stapling profile for detailed steps.
  11. If you want to Notify Certificate Status to Virtual Server, select the check box.
  12. For the Ciphers setting, specify a cipher group or cipher string by choosing one of these options.
    Note: If you specified an ECDSA certificate key chain in the Certificate Key Chain setting, you must include the cipher string ECDHE_ECDSA in the cipher group or cipher string that you specify in the Ciphers setting. (At a minimum, you should specify a cipher group or string such as DEFAULT:ECDHE_ECDSA.) This is necessary to ensure successful cipher negotiation when the BIG-IP system is offered an ECDSA-based certificate only.
    Option Description
    Cipher Group

    Select an existing cipher group from the list when you want to use a system-defined or custom cipher group to define the ciphers that the BIG-IP system uses for negotiating SSL connections. Here's an example of the Ciphers setting where we've selected a custom cipher group that we created earlier.

    Cipher String

    Type a cipher string in the box if you want to manually specify a cipher string instead of selecting a cipher group. For security and performance reasons, consider following these recommendations:

    • Always append ciphers to the DEFAULT cipher string.
    • Type a cipher string that includes the ECC key type, because its shorter length speeds up encryption and decryption while still offering virtually the same 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 Forward Privacy, which creates a key that it throws away after each session so that the same session key never gets 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. Also, diagnostic tools like ssldump won't work when you're using Forward Secrecy.
    • Disable EXPORT ciphers by including !EXPORT in the cipher string.
    • If you can live with removing support for the SSLv3 protocol version, do it. This protocol version is not secure. Simply include :!SSLv3 in any cipher string you type.

    Here's an example of the Ciphers setting where we have opted to manually type the cipher string DEFAULT:ECDHE-RSA-AES-128-GCM-SHA256:!ADH:!EXPORT:HIGH:

  13. For the Client Authentication area, select the Custom check box.
  14. For Client Certificate list, specify whether you want to ignore, require, or request the client certificate authentication.
  15. If you are enabling C3D, from the Trusted Certificate Authorities list, you must select a trusted CA bundle.
  16. Select the Custom check box for the Client Certificate Constrained Delegation area.
    The settings become available for change.
    Note: See About client certificate constrained delegation prior to enabling C3D.
  17. For the Client Certificate Constrained Delegation setting, select Enabled.
  18. From the OCSP list, select the object that the BIG-IP system's SSL should use to connect to the OCSP responder and check the client certificate status.
    You can click the + icon to open the create-new OCSP object screen. See Creating an OCSP stapling profile for detailed steps.
  19. For the Unknown OCSP Response Control list, specify the action the system takes when the OCSP object returns an unknown status:
    • If you want the connection to be dropped, retain the default value Drop.
    • If you want the connection to ignore the unknown status and continue, Select Ignore.
  20. Click Finished.
After performing this task, you can see the custom Client SSL profile in the list of Client SSL profiles on the system.
To use this profile, you must assign it to a virtual server. See Assigning SSL profiles to a virtual server for detailed information.

Creating a custom Server SSL profile

With a Server SSL profile, the BIG-IP® system can perform decryption and encryption for server-side SSL traffic.
Note: For detailed information on how to complete the client certificate constrained delegation (C3D) configuration and ensure that your custom server SSL profile is set up properly, see About client certificate constrained delegation before completing your custom profile setup.
  1. On the Main tab, click Local Traffic > Profiles > SSL > Server .
    The Server SSL profile list screen opens.
  2. Click Create.
    The New Server SSL Profile screen opens.
  3. In the Name field, type a unique name for the profile.
  4. From the Parent Profile list, select serverssl.
  5. From the Configuration list, select Advanced.
  6. Select the Custom check box.
    The settings become available for change.
  7. From the Certificate list, select the name of an SSL certificate on the BIG-IP system.
    Important: If the BIG-IP system is part of a DSC Sync-Failover group, always select a non-default certificate name, and ensure that this same certificate name is specified in every instance of this SSL profile in the device group. Taking these actions helps to ensure that SSL handshakes are successful after a failover event.
  8. From the Key list, select the name of an SSL key on the BIG-IP system.
    Important: If the BIG-IP system is part of a DSC Sync-Failover group, always select a non-default key name, and ensure that this same key name is specified in every instance of this SSL profile in the device group. Taking these actions helps to ensure that SSL handshakes are successful after a failover event.
  9. In the Pass Phrase field, type a pass phrase that enables access to the certificate/key pair on the BIG-IP system.
  10. From the Chain list, select the name of an SSL chain on the BIG-IP system.
  11. For the Ciphers setting, specify a cipher group or cipher string by choosing one of these options.
    Note: If you specified an ECDSA certificate key chain in the Certificate Key Chain setting, you must include the cipher string ECDHE_ECDSA in the cipher group or cipher string that you specify in the Ciphers setting. (At a minimum, you should specify a cipher group or string such as DEFAULT:ECDHE_ECDSA.) This is necessary to ensure successful cipher negotiation when the BIG-IP system is offered an ECDSA-based certificate only.
    Option Description
    Cipher Group

    Select an existing cipher group from the list when you want to use a system-defined or custom cipher group to define the ciphers that the BIG-IP system uses for negotiating SSL connections. Here's an example of the Ciphers setting where we've selected a custom cipher group that we created earlier.

    Cipher String

    Type a cipher string in the box if you want to manually specify a cipher string instead of selecting a cipher group. For security and performance reasons, consider following these recommendations:

    • Always append ciphers to the DEFAULT cipher string.
    • Type a cipher string that includes the ECC key type, because its shorter length speeds up encryption and decryption while still offering virtually the same 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 Forward Privacy, which creates a key that it throws away after each session so that the same session key never gets 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. Also, diagnostic tools like ssldump won't work when you're using Forward Secrecy.
    • Disable EXPORT ciphers by including !EXPORT in the cipher string.
    • If you can live with removing support for the SSLv3 protocol version, do it. This protocol version is not secure. Simply include :!SSLv3 in any cipher string you type.

    Here's an example of the Ciphers setting where we have opted to manually type the cipher string DEFAULT:ECDHE-RSA-AES-128-GCM-SHA256:!ADH:!EXPORT:HIGH:

  12. Select the Custom check box for Server Authentication.
    The settings become available for change.
  13. From the Frequency list, select either once or always.
  14. From the OCSP list, select the OCSP object that the BIG-IP system's SSL should use to connect to the OCSP responder and to check the server certificate status. You can click the + icon to open the create-new OCSP object screen.
    The OCSP stapling object can be added in both forward and reverse proxy configurations. When the server SSL Forward Proxy property is set to Enabled, the forward proxy OCSP object is used to validate and staple the web server's certificate status. When the server SSL Forward Proxy property is set to Disabled, the reverse proxy OCSP object is used to reset the client connection if the web server certificate has been revoked.
  15. Modify the other settings in this area of the screen as required.
  16. Select the Custom check box for the Client Certificate Constrained Delegation section.
    The settings become available for change.
    Note: See About client certificate constrained delegation prior to enabling C3D.
  17. From the Client Certificate Constrained Delegation setting, select Advanced.
  18. From the Client Certificate Constrained Delegation list, select Enabled.
  19. From the CA Certificate list, select the name of the certificate file that is used as the certification authority certificate.
  20. From the CA Key list, select the name of the key file that is used as the certification authority key.
  21. In the CA Passphrase field, type the passphrase of the key file that is used as the certification authority key.
    Note: This should be the passphrase corresponding to the specified CA Key.
  22. For the Confirm CA Passphrase field, type the identical passphrase.
  23. For the Certificate Lifespan fields, type the lifespan of the certificate generated that is using the SSL client certificate constrained delegation.
    The default is 1 day, 0 hours.
  24. To define the extensions of the client certificates to be included in the generated certificates, from the Certificate Extensions list, select Extensions List.
  25. For the Certificate Extensions List setting, click Disable or Enable to add or remove available extensions.
    • Basic Constraints: Uses basic constraints to indicate whether the certificate belongs to a CA.
    • Extended Key Usage: Uses Extended Key Usage, typically on a leaf certificate, to indicate the purpose of the public key contained in the certificate.
    • Key Usage: Provides a bitmap specifying the cryptographic operations that may be performed using the public key contained in the certificate; for example, it could indicate that the key should be used for signature but not for enciphering.
    • Subject Alternative Name: Allows identities to be bound to the subject of the certificate. These identities may be included in addition to, or in place of, the identity in the subject field of the certificate.

    You can also add extensions in the Custom extension field. Type in the extension name and click Add.

  26. Click Finished.
To use this profile, you must assign it to a virtual server. See the Assigning SSL profiles to a virtual server section for detailed information.

Assigning SSL profiles to a virtual server

The final task in the process of implementing SSL profiles is to assign the SSL profile to a virtual server. If the relevant virtual server does not yet exist, you can assign the SSL profile (or profiles) to the virtual server when you create it.
Note: For a reverse proxy Virtual Server, ensure you attach both the created client and server SSL profiles. You will not be able to enable Client Certificate Constrained Delegation (C3D) if this step is not completed. See the About client certificate constrained delegation section for more detailed information on enabling C3D.
  1. On the Main tab, click Local Traffic > Virtual Servers .
    The Virtual Server List screen opens.
  2. Click the name of a virtual server.
  3. From the Configuration list, select Advanced.
  4. For the SSL Profile (Client) setting, from the Available list, select the name of the Client SSL profile you previously created and move the name to the Selected list.
  5. For the SSL Profile (Server) setting, from the Available list, select the name of the Server SSL profile you previously created and move the name to the Selected list.
  6. Click Update to save the changes.

Support for multiple key types

For client-side traffic specifically, you can configure a Client SSL profile to specify multiple certificate key chains on the BIG-IP® system, one for each key type: RSA, DSA, and ECDSA. By configuring a Client SSL profile with different digital certificates and keys, the system can accept all types of cipher suites that clients might request as part of creating a secure connection. The system supports OCSP stapling for all certificate and key types.

Important: To ensure successful negotiation, the BIG-IP system requires you to specify an RSA-based certificate key chain at a minimum, to accommodate any RSA-based ciphers that the client presents. However, F5 Networks highly recommends that you also specify DSA and ECDSA certificate key chains.

About OCSP stapling

When you create a Client SSL profile, you can specify Online Certificate Status Protocol (OCSP) stapling to improve the certification response time. OCSP stapling is when a TLS server (acting as OCSP client) asks the OCSP server for a valid revocation status of its TLS certificate ahead of time and "staples" the signed OCSP response to the TLS handshake. The TLS client sees the stapled OCSP response and verifies the signature, thus validating the TLS server’s certificate and eliminating the round trip at the client for fetching the certificate status. It also helps protect the identity of the client.

By default, OCSP stapling is disabled. You can can create an OCSP stapling profile and then enable it from within a Client SSL profile. There is no default OCSP Stapling profile, so you must create one that specifies the parameters you want to use. For example, the default OCSP stapling profile setting is to use a DNS resolver to fetch the OCSP response, and you must specify the DNS resolver to use. Alternatively, you can choose to use a proxy server to fetch the OCSP response, and then you must specify the proxy server pool.

Creating an OCSP stapling profile

Before you start this task, be sure that you have configured a proxy server pool or a DNS resolver.
When you create an OCSP stapling profile and assign it to a client SSL profile, you speed up the time it takes for the client to get the certificate revocation status of the BIG-IP® system.
  1. On the Main tab, click System > Certificate Management > Traffic Certificate Management > OCSP .
  2. Click Create.
    The new OCSP Stapling Profile screen opens.
  3. In the Name field, type a unique name for the OCSP stapling profile.
  4. For the Use Proxy Server setting, specify how to fetch the OCSP response:
    • If you want the BIG-IP system to use the Proxy Server Pool, select the check box. Use this when there are one or more servers that can act as a proxy an HTTP request to an external server and fetch the response.
    • If you want to use the DNS Resolver, clear the check box. Use this when the OCSP responder can be reached on one of the BIG-IP system interfaces.
  5. In the Proxy Server Pool or DNS Resolver field, select the proxy server pool or DNS resolver used for fetching the OCSP response.
  6. In the Route Domain field, select the route domain for fetching an OCSP response using HTTP forward proxy.
  7. In the Concurrent Connections Limit field, type the maximum number of connections per second allowed for the OCSP certificate validator.
    The default value is 50 connections.
  8. In the Responder URL field, type the name of a URL that will override the OCSP responder URL obtained from the certificate's AIA extension.
    This must be an HTTP or HTTPS-based URL.
  9. In the Timeout field, type a time interval for the BIG-IP system to wait before dropping the connection to the OCSP responder.
  10. From the Trusted Responders list, select the name of a certificate to use to verify the response from the OCSP responder.
  11. In the Clock Skew field, type a value for the maximum tolerable absolute difference between the clocks of the responder and the BIG-IP system.
  12. In the Status Age field, type a value for the maximum allowed lag time in the OCSP response that the BIG-IP system accepts.
    If you type 0, the validation is skipped. The default value is 86400.
  13. To have the system check the responder's certificate for the OCSP signing extension for the Options setting, select the Strict Responder Certificate Checking check box.
  14. From the Timeout list, select a value that specifies the lifetime of the OCSP response.
    The default is Indefinite, indicating that the response validity period takes precedence.
  15. In the Error Timeout field, type a value for how long a BIG-IP system will cache an error response.
    The default value is 3600 seconds.
    Note: The Error Timeout must be greater than Connection Timeout.
  16. From the Certificate list, select a certificate corresponding to the key used for signing the OCSP request.
  17. From the Key list, select a key to use to sign an OCSP request.
  18. In the Passphrase field, type the passphrase of the key used to sign an OCSP request.
  19. From the Hash Algorithm list, select the hash algorithm used to sign an OCSP request.
    The default is SHA256.
    Note: This is not the algorithm used in the certificate itself. It is what the OCSP responder will use when validating the request.
  20. Click Finished.
After you create an OCSP profile, make sure you enable the OCSP Stapling setting from within the relevant Client SSL profile.

Viewing OCSP stapling statistics

You can use the OCSP stapling statistics to view output such as the number of successful cache requests, the number of Good, Revoked, and Unknown certificate status statistics, and the number of internal, connection, and response errors based on the OCSP definitions in the configuration.
  1. On the Main tab, click System > Certificate Management > Traffic Certificate Management > OCSP > Statistics .
    The System OCSP statistics screen opens.
  2. From the Statistics Type list, verify that OCSP is selected.
  3. From the Data Format list, select how the system presents the statistics information.
    Option Description
    Normalized (default) Rounds values to the nearest whole number.
    Unformatted Presents the actual value, including all decimal places.
  4. From the Auto Refresh list, select a time interval to automatically update the statistics display screen information.
    The default is Disabled.
    When you specify an automatic-refresh interval, the system presents a Stop button for halting the operation, and counts down the seconds to the next update.
    Note: Short automatic-refresh intervals may negatively affect system performance.
The BIG-IP system displays output such as the number of successful cache requests, the number of Good, Revoked, and Unknown certificate status statistics, and the number of internal, connection, and response errors based on the OCSP definitions in the configuration. Click Reset to clear the OCSP statistics display screen information.

About BIG-IP cipher support

The BIG-IP® system supports a large set of cipher suites that you can choose from to build the cipher string used for security negotiation.

Supported cipher suites include various combinations of encryption algorithms and authentication mechanisms, including RSA (Rivest Shamir Adleman), DSA (Digital Signature Algorithm), and ECDSA (Elliptic Curve Digital signature Algorithm).

The system includes a default cipher string represented by the keyword DEFAULT, which contains a subset of the cipher suites that the BIG-IP system supports.

Glossary of cipher-related terms

This list defines terms for cipher-related features that the BIG-IP ® system supports.

Cipher suite
A combination of authentication, encryption, message authentication code (MAC), and key exchange algorithms that the BIG-IP system can offer to a client and server system when negotiating security for an SSL network connection.
Cipher string
A string that contains the cipher suite or suites that the BIG-IP system can use to negotiate security for an SSL connection.
Cipher rule
A named BIG-IP configuration object that contains a cipher string. The BIG-IP system offers several pre-built cipher rules. Examples are f5-default, f5-ecc, and f5-secure, which represent the cipher strings DEFAULT, ECDHE:ECDHE_ECDSA, and ECDHE:RSA:!SSLV3:!RC4:!EXP:!DES, respectively.
Cipher group
A named BIG-IP configuration object that specifies one or more cipher rules, with instructions for how you want the BIG-IP system to apply those rules to an SSL connection. The BIG-IP system offers several pre-built cipher groups, such as f5-default, f5-ecc, and f5-secure, where each cipher group includes one corresponding pre-built cipher rule. You can use a pre-built cipher group, or you create a custom cipher group.
Cipher audit
The actual cipher suites that the BIG-IP system can offer to a client or server system as part of negotiating an SSL connection, after resolving any mismatches.

About the DEFAULT cipher suite

Some of the cipher suites that the BIG-IP system supports are included in a default cipher string that you can specify using the keyword DEFAULT. The keyword DEFAULT represents a set of ciphers that are suitable for most SSL connections.

The DEFAULT keyword appears as the default value in the Ciphers setting of the Client SSL and Server SSL profiles.

Important: We strongly recommend that you use the default cipher string and, for added security, append other cipher suites to it.

View cipher suites in cipher string DEFAULT

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 list of cipher suites currently included in the cipher string represented by the keyword DEFAULT, for both client-side and server-side SSL connections.

  1. Using an SSH client application such as PuTTY, access the advanced shell on the BIG-IP system.
  2. At the system prompt, for client-side negotiation, type the command tmm --clientciphers DEFAULT. For server-side negotiation, type tmm --serverciphers DEFAULT.

About the COMPAT, SSLv2, and RC2 keywords

BIG-IP® system version 14.0 does not support the OpenSSL cipher stack. As a result, the keyword NATIVE represents the only TLS stack in use and is equivalent to the keyword ALL.

Invalid keywords in BIG-IP cipher strings

When configuring a cipher string on the BIG-IP system, you cannot use these keywords because they are invalid:

  • COMPAT
  • SSLV2 (subset of COMPAT)
  • RC2 (subset of COMPAT)
  • Any other subsets of COMPAT or SSLv2

In BIG-IP version 14.0 and higher, 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.

Important: If you have an SSL profile in a previous BIG-IP version and then upgrade to version 14.0, the system automatically resolves the issue for you.

Changes to cipher keywords during a BIG-IP system upgrade

During a BIG-IP software upgrade to version 14.0, 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 cipher suites that are suitable for most SSL connections.

Unsupported cipher suites

These cipher suites are unavailable in BIG-IP version 14.0:

  • EXP-EDH-RSA-DES-CBC-SHA
  • EXP-ADH-DES-CBC-SHA
  • EXP-RC2-CBC-MD5
  • EXP-ADH-RC4-MD5

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, disallow, and so on, 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.

What is a cipher rule?

A cipher rule is an object that contains cipher-related information such as an encryption algorithm and a key exchange method. The BIG-IP system will use one or more cipher rules within a cipher group, to build the cipher string that the system will use to negotiate SSL security parameters with a client or server system.

You can use pre-defined cipher rules that the BIG-IP system provides, or you can create your own. In either case, after you decide which cipher rules you want to use, you then specify the cipher rules within a cipher group, which is the object that builds the actual cipher string that the system will use during SSL negotiation. Then you just need to specify the cipher group within a Client SSL or Server SSL profile, and assign the profile to a virtual server.

An example of a cipher rule might be one that specifies only ciphers that use a particular bulk encryption algorithm and a key exchange method.

Best practices for BIG-IP cipher strings

For security and performance reasons, consider the following recommendations:

  • Always append cipher suites to the default cipher string, respresented by the keyword DEFAULT.
  • Don't use any of the keywords COMPAT, SSLv2, and RC2 in a cipher string. These keywords are invalid and resolve to a value of None.
  • Instead of using the keyword NATIVE, use ALL. These keywords are equivalent, so use of NATIVE is unecessary.
  • Include a cipher string that specifies the ECC key type, because its shorter length speeds up encryption and decryption while still offering virtually the same 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 Forward Secrecy, which creates a key that it throws away after each session so that the same session key never gets 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.
  • Disable EXPORT ciphers by including !EXPORT in the cipher string.
  • If you can live with removing support for the SSLv3 protocol version, do it. This protocol version is unsecure. Simply include :!SSLv3 in any cipher string you build.

Create partial cipher strings to include in a custom cipher string

When you create your own cipher rules for a custom cipher group, the BIG-IP® system can build a cipher string that includes or excludes the cipher suites you need for negotiating SSL connections.

  1. On the Main tab, click Local Traffic > Ciphers > Rules .
    The screen displays a list of pre-built cipher rules.
  2. Click Create.
  3. In the Name field, type a name for the cipher rule.
    Note: Never include the prefix f5- in a cipher rule name. This prefix is reserved for pre-built cipher rules only.

    For example:

  4. In the Cipher String field, type a cipher string that represents one or more cipher suites.

    For example:

  5. Click Finished.
The cipher rule now appears within any custom cipher group, in the list of available cipher rules.

Build a custom cipher string

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.

  1. On the Main tab, click Local Traffic > Ciphers > Groups .
    The screen displays a list of pre-built cipher groups.
  2. Click Create.
  3. In the Name field, type a name for the cipher group.
    Note: Never include the prefix f5- in a cipher rule name. This prefix is reserved for pre-built cipher groups only.
  4. 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.
  5. 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.

  6. In the Available Cipher Rules list, select the boxes for the cipher rules you want to allow for negotiating security for SSL connections.
    Important: 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:

  7. 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:

  8. 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.
  9. Using the Move button, move the selected cipher rules to the Restrict the Allowed list to the following box.
  10. 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.
  11. Using the Move button, move the selected cipher rules to the Exclude the following from the Allowed list box.
  12. 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.
  13. In the Cipher Audit area of the screen, view the cipher string that the BIG-IP system will construct based on the selections you made in the previous steps.
  14. 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.

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.

Note: Elliptic Curve ciphers with DSA are not included in the DEFAULT cipher suite.

Specifying the use of Elliptic Curve ciphers

Use this task to modify an existing Client SSL profile to enable support for Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.
  1. 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.
  2. In the Name column, click the name of the profile you want to modify.
  3. Select the Custom check box.
    The settings become available for change.
  4. For the Ciphers setting, click Cipher String and type DEFAULT:ECDHE.
  5. 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.

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.
  1. Access the system prompt on the BIG-IP system.
  2. 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

Sample profile statistics for key exchange method

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 cipher support

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 ciphers 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)
Note: For DHE, the DEFAULT cipher suite includes Elliptic Curve cipher suites only. DHE ciphers for RSA and DSS encryption are not included.

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.
  1. Access the advanced shell on the BIG-IP system.
  2. At the system prompt, type the command tmm --clientciphers ciphers .
    1. For example, to see a list of DHE+DES ciphers, type tmm --clientciphers DHE:DHE_DSS
      The BIG-IP system displays the list of all DHE+DES ciphers that the BIG-IP system supports:
      Supported DHE ciphers on the BIG-IP system

      Supported DHE+DES ciphers on the BIG-IP system

    2. To see a list of ECDHE ciphers, type tmm --clientciphers ECDHE:ECDHE_ECDSA.
      The BIG-IP system displays the list of all ECDHE ciphers that the BIG-IP system supports:
      Supported ECDDHE ciphers on the BIG-IP system

      Supported ECDHE ciphers on the BIG-IP system

Specifying the use of Diffie-Hellman ciphers

Use this task to modify an existing Client SSL profile to enable support for Diffie-Hellman key exchange.
  1. 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.
  2. In the Name column, click the name of the profile you want to modify.
  3. Select the Custom check box.
    The settings become available for change.
  4. To specify DHE ciphers:
    1. From the Configuration list, select Advanced.
    2. For the Ciphers setting, click Cipher String and type DHE:DHE_DSS.
  5. 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.
  1. Access the system prompt on the BIG-IP system.
  2. 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

Sample profile statistics for key exchange method

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.

Client and server certificate authentication

There are several settings that you can configure on an SSL profile to manage client-side SSL authentication.

Requirement for a client certificate

You can cause Local Traffic Manager™ to handle authentication of clients or servers in certain ways. For client-side processing, the possible behaviors are:

Ignore
Ignore a certificate (or lack of one) and therefore never authenticate the client. The Ignore option is the default, and when used, causes any per-session authentication setting to be ignored.
Require
Require a client to present a valid and trusted certificate before granting access.
Request
Request and verify a client certificate. In this case, the SSL profile always grants access regardless of the status or absence of the certificate.
Warning: If you are using the LDAP-based client authorization feature, use of the Request or Ignore values can sometimes cause a connection to terminate.
Tip: The Request value works well with the header insertion feature. Configuring the SSL profile to insert client certificate information into an HTTP client request, and to authenticate clients based on the Request option, enables the BIG-IP® system or a server to then perform actions such as redirecting the request to another server, sending different content back to the client, or performing client certificate or session ID persistence.

For server-side processing, the possible behaviors are:

Require
Require a server to present a valid and trusted certificate before granting access.
Ignore
Ignore a certificate (or lack of one) and therefore never authenticate the server. The Ignore value is the default setting, and when used, causes any per-session authentication setting to be ignored.

Frequency of authentication

You can configure an SSL profile to require authentication either once per SSL session (once), or once upon each subsequent re-use of an SSL session (always). The default setting for this option is once.

Whether you set this value to once or always depends on your application. A well-designed web application should need to verify a certificate only once per session. F5 recommends for performance reasons that you use the default setting (once) whenever possible.

You can modify the SSL profile to require authentication not only once per session, but also upon each subsequent re-use of an SSL session.

Certificate chain traversal depth

You can use the Certificate Chain Traversal Depth setting of an SSL profile to configure the maximum number of CA certificates (intermediate CA certificates and/or root CA certificates) that can be traversed in the certificate chain. The default value is 9. If a longer chain is provided, and the client has not been authenticated within this number of traversals, client or server certificate verification fails.

Any certificates installed as part of a CA certificate bundle are trusted. All certificates sent by the peer are not trusted, and the BIG-IP system rejects v1/v2 intermediate certificates presented by the peer. The process of certificate chain building starts from a leaf certificate and ends when the issuer CA certificate is trusted.

Trusted certificate authorities

For client-side and server-side SSL processing, you can use the Trusted Certificate Authorities setting on an SSL profile to configure an SSL profile to verify certificates presented by a client or a server. You can specify a client trusted CAs file name, which the BIG-IP® system then uses to verify client or server certificates. If you do not configure a trusted CAs file, the system uses a default file.

The trusted CAs file that you specify for certificate verification contains one or more certificates, in Privacy Enhanced Mail (PEM) format. Built manually, this file contains a list of the client or server certificates that the SSL profile will trust. If you do not specify a trusted CAs file, or the specified trusted CAs file is not accessible to the BIG-IP system, the system uses the default file name.

Advertised certificate authorities

For client-side profiles only, if you intend to configure the SSL profile to require or request client certificates for authentication, you will want the profile to send to clients a list of CAs that the BIG-IP® system is likely to trust.

This list, known as the Client Certificate CA file, is different from the client Trusted CAs file. This is because, in some cases, you might have a client that does not possess a valid client certificate, in which case you might not want to reveal the actual list of CAs that the BIG-IP system trusts. The client certificate CA file solves this problem by allowing the BIG-IP system to advertise a list of CAs that is different from the actual client trusted CAs file configured as part of certificate verification.

Although the contents of the Client Certificate CA file can differ from that of the Client Trusted CAs file, it is best, for compatibility reasons, to set the Advertised Certificate Authorities setting to match the Trusted Certificate Authorities setting. This is because modern browsers might not permit SSL session negotiation to proceed if the peer that requests the client certificate does not provide a list of trusted CAs.

Note: The maximum size of native SSL handshake messages that Local Traffic Manager™ allows is 14304 bytes. Consequently, if the SSL handshake is negotiating a native cipher and the total length of all messages in the handshake exceeds this byte threshold, the handshake can fail. Although typical use does not cause message length to exceed this threshold, we recommend that when configuring a Client SSL profile to request or require client certificates, you avoid specifying large numbers of certificates through the Advertised Certificate Authorities setting. This minimizes the number of certificates that must be exchanged during a Client SSL handshake.

Name-based authentication

For server-side profiles only, Local Traffic Manager™ supports name-based authentication, which guards against man-in-the-middle attacks. When you configure the Authenticate Name setting for a server-side profile, Local Traffic Manager checks the name against the Common Name (CN) listed in the certificate that the target server presents to the BIG-IP® system. If the name attribute that you specify does not match the CN in the server certificate, Local Traffic Manager closes the connection. An example of a CN is www.f5.com.

Certificate revocation

The Certificate Revocation List (CRL) setting of an SSL profile allows Local Traffic Manager™ to use CRLs to check revocation status of a certificate prior to authenticating a client or server.

Important: CRL files can become outdated, and might need to be updated as often as every day, or as seldom as every 30 days. If your CRL file is out-of-date, Local Traffic Manager rejects all certificates, both valid and invalid. For this reason, it is important to keep your CRL files up-to-date at all times. You can do this by accessing the CRL in the /config/ssl/ssl.crl directory and then using the openssl crl command. For more information, see http://www.openssl.org/docs/.

As an alternative to using CRLs, you can use the Online Certificate Status Protocol (OCSP) feature, which ensures up-to-date information on certificate revocation status.