Applies To:

Show Versions Show Versions

Manual Chapter: BIG-IP version 9.2 Configuration Guide for Local Traffic Management: Managing SSL Traffic
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


7

Managing SSL Traffic


Introducing SSL traffic management

The BIG-IP® local traffic management (LTM) system offers several features that you can use to intelligently control your SSL traffic. Some of the SSL traffic-management features are:

  • The ability to authenticate clients and servers to maintain secure connections between a client system and the BIG-IP system, and between the BIG-IP system and a target web server
  • The ability to offload SSL certificate-verification tasks from client and server systems
  • iRule commands that provide features such as header insertion and HTTP redirection.
  • Support for Online Certificate Status Protocol (OCSP), for the purpose of obtaining up-to-date certificate revocation status
  • Certificate-based client authorization using a Light-weight Directory Access Protocol (LDAP) server

The primary way that you can control SSL network traffic is by configuring a Client or Server SSL profile. A Client profile is a type of traffic profile that enables the LTM system to accept and terminate any client requests that are sent by way of a fully SSL-encapsulated protocol. As an option, using a Server profile, you can also configure an SSL profile to initiate secure connections to a target web server.

Managing SSL traffic requires you to complete these tasks:

  • Install a key/certificate pair on the LTM system for terminating client-side secure connections.
  • Configure a profile, and then associate that profile with a virtual server. You configure a profile using the Configuration utility.
  • Associate the profile with a virtual server.

As an option, you can write an iRule that gives you the ability to manage individual SSL connections in certain ways. For more information, see Chapter 13, Writing iRules .

Managing client-side and server-side traffic

With the LTM system, you can enable SSL traffic management for either client-side traffic or server-side traffic. Client-side traffic refers to connections between a client system and the LTM system. Server-side traffic refers to connections between the LTM system and a target server system.

  • Managing client-side SSL traffic
    When you enable the LTM system to manage client-side SSL traffic, the LTM system terminates incoming SSL connections by decrypting the client request. The LTM system then sends the request, in clear text, to a target server. Next, the LTM system retrieves a clear-text response (such as a web page) and encrypts the request, before sending the web page back to the client. During the process of terminating an SSL connection, the LTM system can, as an option, perform all of the SSL certificate verification functions normally handled by the target web server. For information on configuring a client-side SSL profile, see Understanding SSL profiles .
  • Managing server-side SSL traffic
    When you enable the LTM system to manage server-side SSL traffic, the LTM system enhances the security of your network by re-encrypting a decrypted request before sending it on to a target server. In addition to this re-encryption, the LTM system can, as an option, perform the same verification functions for server certificates that the LTM system can for client certificates. For information on configuring a server-side SSL profile, see Understanding SSL profiles .

Summarizing SSL traffic-control features

The LTM system includes several important features related to controlling SSL traffic. Foremost among these features are SSL authentication (that is, certificate verification and revocation), as well as encryption and decryption. While most of these features are available through configuration of a Client or Server SSL profile, others are offered through features such as iRulesTM. Table 7.1 summarizes the features related to SSL traffic management; the sections following the table describe these features.

Table 7.1 Summary of the LTM system features related to SSL traffic control
Features
Description
Configuration Tool
Certificate verification
In terminating and initiating SSL connections, the LTM system can perform a full range of certificate verification tasks, including the verification of both client and server certificates. For example, you can define the extent to which the system verifies client certificates: you can configure the system to request client certificates, require them, or ignore them altogether. You can also specify settings such as the depth of certificate chain traversal.
Client and Server SSL profiles
iRules
Certificate revocation
When a client or server presents a certificate to the LTM system, the system can check the revocation status of a certificate as part of the certificate verification process.
Client and Server SSL profiles
OCSP profile
Encryption and decryption
As a way to off-load work from target web servers, the LTM system decrypts incoming client requests. As an added security option, you can configure the profile to re-encrypt a request before forwarding it on to a server. Encryption and decryption of requests and responses are based on particular ciphers that you specify as part of SSL profile configuration.
Client and Server SSL profiles
Authorization
You can control access to system resources by configuring the LTM system in certain ways. For example, you can create an iRule to insert client certificate information into client requests and then grant access based on that information. Also, for environments that include an LDAP database server, the LTM system can grant access to resources by querying the LDAP server using client certificate credentials. You can also limit the number of concurrent TCP connections.
SSL Client Certificate LDAP profile iRules
SSL session persistence
A powerful feature of the LTM system is its ability to enable persistence for SSL sessions. Two types of SSL persistence are available, depending on whether you have configured the LTM system to terminate SSL connections.
Client and Server SSL profiles
SSL Persistence profile
iRules
Other SSL features
In addition to the features listed above, the LTM system allows you to configure other options such as invalid protocol versions, the size and timeout values of the SSL session cache, and SSL shutdown behavior.
Client and Server SSL profiles

 

Understanding certificate verification

Certificate verification is the process of determining whether a client or server can trust a certificate that is presented by a peer (that is, a client or a server). When receiving a request from a client or a response from a server, the LTM system attempts to verify that the certificate presented by the client or server can be trusted.

Signed certificates

A basic security requirement for clients and servers handling SSL connections is that they each present a certificate signed by a trusted Certificate Authority (CA), whenever they communicate with a peer. As an option, you can configure the LTM system to handle the task of verifying client certificates.

When you configure certificate verification on the LTM system, the LTM system must hold a certificate that it can present to clients when processing SSL requests.

Optionally, you can configure the LTM system to verify server responses. In this case, if the server specifically requests a certificate from the LTM system, the LTM system needs to hold a second certificate.

If you configure the LTM system to verify client and server certificates, you must generate and install keys and certificates onto the LTM system before the system can manage SSL traffic. You can do this through the Configuration utility. As an alternative to generating new key/certificate pairs, you can import existing ones. For more information on importing existing key/certificate pairs, see Importing keys, certificates, and archives .

Client-side certificate verification

When a client makes an HTTP request, the LTM system can perform the client certificate verification task that is normally performed by the target server.

When a client presents a certificate to the LTM system, the LTM system uses a client trusted CAs file to determine the Certificate Authorities that it can trust. Using this file is the primary way that the LTM system attempts to verify a client certificate. When you create a client-side profile, the LTM system automatically creates a default client trusted CAs file. You can either use the default file name specified in the profile, or you can specify a different file name. For more information, see Specifying trusted client CAs .

A second factor in client certificate verification is the client certificate CA file, which the LTM system uses to advertise to clients a list of the CAs that the profile trusts. Not that this list could be different from the list of CAs that the LTM system actually trusts. As with the trusted CAs file, the LTM system automatically creates a a default version of this file.

There is also a client chain file, which the LTM system sends to a client as part of the client certificate verification process. The default client chain file is the Client Trusted CAs file. For more information, see Specifying trusted client CAs .

Server-side certificate verification

Server-side verification occurs when you enable a Server SSL profile and set the presentation of a server certificate to require.

When a server presents a certificate to the LTM system, the LTM system uses the server trusted CAs file to determine which Certificate Authorities it can trust. Using this file is the primary way that the LTM system attempts to verify a server certificate. The LTM system automatically creates a default Server Trusted CAs file when you configure a server-side profile. You can either use the default file name specified in the profile, or specify a different file name.

There is also a server chain file, which the LTM system sends to a server as part of the entire server certificate verification process. The default server chain file is the Server Trusted CAs file.

Understanding certificate revocation

The LTM system can check to see if a certificate being presented by a client or server has been revoked. A revoked client certificate indicates to the LTM system that the system should fail to authenticate the client.

The LTM system supports two industry-standard methods for checking the revocation status of a certificate. These two methods are:

  • Certificate revocation lists (CRLs).
    CRLs are a method that the LTM system can use to check on whether a certificate being presented to the LTM system has been revoked. This CRL support is in the form of a CRL file and a CRL path. The LTM system enables you to configure one CRL file and path for the client-side profile, and one CRL file and path for the server-side profile. You configure the use of CRLs through an SSL profile. For more information, see Configuring client or server authentication settings .
  • Online Certificate Status Protocol (OCSP)
    Unlike the use of CRLs, OCSP ensures that the revocation status of a certificate is always up-to-date. You configure OCSP through an Authentication profile. For more information, see Chapter 8, Authenticating Application Traffic .

Understanding encryption/decryption

Another feature of the LTM system is its ability to handle encryption and decryption tasks that a target server normally performs as part of processing a client request. Using a client-side SSL profile, the LTM system decrypts incoming requests before sending them on in plain text to the target server. Using a server-side profile, the LTM system provides an additional level of security by re-encrypting the request before sending it on to the target server.

An LTM system feature related to encryption is the ability to insert into incoming HTTP requests the cipher that the client used to encrypt its request. You can then direct the traffic based on that cipher specification. For more information on specifying ciphers to control the destination of client requests, see Chapter 13, Writing iRules .

Understanding client authorization

Unlike authentication, authorization is not about trusting identity, but about controlling access to system resources. Once the SSL profile has verified that a client or server can be trusted, the LTM system can then control the connection's level and type of access to the destination content.

The LTM system features that support access control for SSL connections are:

  • Inserting client certificate fields into HTTP requests
  • Limiting the number of concurrent client TCP connections
  • Client authorization with an LDAP database server

One of the most useful ways to control a client's access to system resources is to create an iRule that inserts fields of a client certificate as headers into client requests. For example, an iRule can insert the status of a client certificate as a header into a request, and then use the HTTP::header command to select the target server based on that status.

For more information on using this header insertion feature to control the destination of client requests, see Chapter 13, Writing iRules .

Understanding SSL session persistence

There are two types of SSL persistence available that you can implement. The first type is the standard SSL persistence mode, which enables persistence for SSL sessions that do not involve the decryption of SSL requests and the re-encryption of SSL responses. You enable this SSL persistence mode by configuring an SSL persistence profile. For more information, see Chapter 9, Enabling Session Persistence .

The second type of SSL persistence enables persistence for SSL sessions that involve the decryption of requests and re-encryption of responses. In this case, you implement SSL persistence is by inserting SSL session IDs as headers into HTTP requests. You insert session ID headers by writing an iRule. For information on iRules, see Chapter 13, Writing iRules .

Understanding other SSL features

In addition to using the preceding features, you can also perform tasks such as specifying invalid protocol versions, configuring the size and timeout values of the SSL session cache, and configuring SSL shutdown behavior. You can also configure an SSL profile to renegotiate SSL sessions based on timeout values and amount of data transmitted.

Managing keys and certificates

Before you can enable decryption and encryption of SSL connections, you must install one or more SSL certificates on the LTM system. The purpose of these certificates is described in the section Understanding certificate verification .

To ease the task of generating certificate requests and sending them to certificate authorities, the LTM system provides a set of key management screens within the Configuration utility. You access these certificate management screens from the Local Traffic section of the Main tab.

When managing keys, you can:

  • Display information about all existing key pairs and certificates.
  • Create requests for new key pairs and certificates and submit those requests to certificate authorities.
  • Renew certificate requests.
  • Display key and certificate properties.
  • Import and export PEM-formatted keys and certificates.

Displaying information about existing keys and certificates

Summary information about existing key pairs and certificates is available from the Configuration utility. The SSL Certificates screen displays the following information:

  • Status of the certificate (valid, about to expire, or expired)
  • The unique name that you assigned the certificate when creating the request
  • The issuer of the certificate
  • The expiration date

To display information about existing certificates and keys

  1. On the Main tab, expand Local Traffic.
  2. Click SSL Certificates.
    This opens the SSL Certificates screen and lists all certificates installed on the LTM system.
  3. Click a certificate name.
    This displays the properties of that certificate.
  4. If you want to see information about the key that is associated with that certificate, click Key on the menu bar.
    This displays the type and size of the key.

Creating a request for a new certificate and key

Using the Configuration utility, you can either generate a self-signed certificate (usually used for internal test purposes only) or you can create a request for a certificate/key pair, to be sent to a certificate authority. When you send a request to a certificate authority, the certificate authority returns a signed certificate.

You can send a certificate request to a certificate authority in either of two ways:

  • You can copy the text of the newly-generated request from the Configuration utility screen and give it to the certificate authority (using cut and paste).
  • You can download the newly-generated request to a file and transmit the file to the certificate authority.

The way to transmit the request to a certificate authority (either through pasting the text or through a file attachment) is by accessing the certificate authority's web site. The Configuration utility screen for submitting a request for signature by a certificate authority includes links to various certificate authority web sites.

To request a self-signed certificate

  1. On the Main tab, expand Local Traffic.
  2. Click SSL Certificates.
    This displays the SSL Certificates screen.
  3. On the upper-right portion of the screen, click Create.
  4. Type a unique name for the certificate.
  5. For the Issuer setting, select Self.
  6. Configure the Common Name setting, and any other settings you want.
  7. In the Key Properties section, select a key size.
  8. Click Finished.

To request a certificate from a certificate authority

  1. On the Main tab, expand Local Traffic.
  2. Click SSL Certificates.
    This displays the SSL Certificates screen.
  3. On the upper-right portion of the screen, click Create.
  4. Type a unique name for the certificate.
  5. In the Issuer box, select Certificate Authority.
  6. Configure the Common Name setting, and any other settings you want.
  7. Click Finished.
    This displays your certificate request.
  8. To download the request into a file on your system, either:
    • Copy the certificate from the Request Text box.
    • Click the button in the Request File box.
  9. In the Certificate Authorities box, click a certificate authority name.
    This displays the web site for the certificate authority.
  10. Follow the instructions on the web site for either pasting the copied request or attaching the generated request file.
  11. Click Finished.

Renewing a certificate

All certificates include expiration dates. When a certificate expires, you must renew that certificate if you want to continue using it.

To renew a certificate

  1. On the Main tab, expand Local Traffic.
  2. Click SSL Certificates.
    This displays a list of existing certificates.
  3. Click the name of the certificate that you want to renew.
    This displays the certificate properties.
  4. At the bottom of the screen, click Renew.
  5. Modify or retain settings.
    Note that a value for the Common Name setting is required.
  6. Click Finished.

Deleting a certificate/key pair

You can delete certificates and keys that you no longer need.

To delete a certificate

  1. On the Main tab, expand Local Traffic.
  2. Click SSL certificates.
    This displays the list of existing certificates.
  3. Check the Select box to the left of the name of the certificate you want to delete.
  4. At the bottom of the screen, click Delete.
    A confirmation screen appears.
  5. Click Delete.
    This removes the certificate.

Importing keys, certificates, and archives

If you have transferred a key/certificate pair, a certificate, or a key/certificate archive onto the LTM system from another system, and the certificate or archive is in the form of a file or a base-64 encoded text string, you can import this certificate or archive into the Configuration utility. By importing a certificate or archive into the Configuration utility, you ease the task of managing that certificate or archive. You can use the Import SSL Certificates and Keys screen only when the certificate you are importing is in Privacy Enhanced Mail (PEM) format.

To import a key pair, certificate, or archive

  1. On the Main tab, expand Local Traffic.
  2. Click SSL Certificates.
    This displays the list of existing certificates.
  3. In the upper right corner of the screen, click Import.
  4. Select the type of import (Key, Certificate, or Archive).
  5. Select the import method (text or file).
  6. Type the name of the key, certificate, or archive.
  7. Click Import.

Creating an archive

You can create an archive for one or more keys and certificates. You create an archive when you want to export multiple keys and certificates to another system.

To create an archive

  1. On the Main tab, expand Local Traffic.
  2. Click SSL Certificates.
    This displays the list of existing certificates.
  3. Click Archive.
  4. Type a name for your archive file.
    The file will have a .tgz extension.
  5. In the Key List area:
    1. Select a key that you want to archive.
    2. Use the Move button (<<) to transfer the key name to the Enabled box.
  6. In the Certificate List area:
    1. Select a certificate that you want to archive.
    2. Use the Move button (<<) to transfer the certificate name to the Enabled box.
  7. Click the locallb.sslcert.Generate&DownloadArchive button.
  8. Click Finished.

Understanding SSL profiles

As described in Chapter 5, Understanding Profiles , a profile is a group of settings with values that determine the way that the LTM system manages application-specific network traffic. One type of traffic that a profile can manage is SSL traffic. The most basic functions of an SSL profile are to offload certificate validation and verification tasks, as well as encryption and decryption, from your target web servers.

The two types of SSL profiles are:

  • Client profiles
    Client profiles allow the LTM system to handle authentication and encryption tasks for any SSL connection coming into an LTM system from a client system. You implement this type of profile by using the default clientssl profile, or by creating a custom profile based on the clientssl profile.
  • Server profiles
    Server profiles allow the LTM system to handle encryption tasks for any SSL connection being sent from a LTM system to a target server. A server SSL profile is able to act as a client by presenting certificate credentials to a server when authentication of the LTM system is required You implement this type of profile by using the default serverssl profile, or creating a custom profile based on the serverssl profile.
Important

Prior to enabling SSL processing, you must first generate either a valid x509 certificate from a Trusted Certificate Authority or a temporary certificate, and install it on the LTM system. For more information on certificates, see Signed certificates . For instructions on how to generate and install a certificate on the LTM system, see Managing keys and certificates .

The settings that make up a Client or Server SSL profile are organized into three categories: General properties, Configuration, and either Client Authentication or Server Authentication. You can configure these settings at the time that you create an SSL profile or after profile creation by modifying the profile's settings. For specific procedures on configuring a profile, see Chapter 5, Understanding Profiles .

Tip


For any individual SSL connection, you can override the value of an SSL profile setting. You do this by writing an iRule and including those SSL iRule commands that correspond to the settings you want to override. For more information, see Chapter 13, Writing iRules.

Configuring general properties of an SSL profile

This section describes the settings that appear in the General Properties section of a Client SSL Profile or Server SSL Profile screen. For information on other SSL profile settings, see Configuring configuration settings and Configuring client or server authentication settings .

For the procedure on creating or modifying a profile, see Chapter 5, Understanding Profiles .

Table 7.2 shows the general properties that you can specify for a Client or Server SSL profile. For those settings that have default values, you can retain those default settings or modify them. Following this table are descriptions of these general properties.

Table 7.2 General Properties of an SSL profile
General Property
Description
Default Value
Name
Specifies the user-supplied name of the profile.
No default value
Parent Profile
Specifies the system-supplied profile from which a custom profile is derived.
clientssl or serverssl

 

When you configure the general properites of an HTTP profile, you specify a unique name for your profile and you select a parent profile.

Specifying a profile name

To create an SSL profile, you must specify a unique name for the profile. The Name setting is the only setting that you must actively specify when creating an SSL profile; all other settings have default values.

Selecting a parent profile

Every profile that you create is derived from a parent profile. Using the Parent Profile setting, you can configure the default SSL profile as the parent profile, or you can configure another SSL profile that you have already created.

Configuring configuration settings

This section describes the settings that appear in the Configuration section of a Client SSL Profile or Server SSL Profile screen. For information on configuring the other SSL profile settings, see Configuring general properties of an SSL profile , and Configuring client or server authentication settings .

For the procedure to create or modify an SSL profile, see Chapter 5, Understanding Profiles .

Table 7.3 shows the settings you can configure for a Client SSL or Server SSL profile. For those settings that have default values, you can retain those default settings or modify them. Following this table are descriptions of these settings.

Table 7.3 Configurable settings for an SSL profile
Setting
Description
Default Value
Certificate
Specifies the name of the certificate installed on the LTM system for the purpose of terminating or initiating an SSL connection.
default
Key
Specifies the name of the key installed on the LTM system for the purpose of terminating or initiating an SSL connection.
default
Pass Phrase
Specifies the name of the pass phrase used to encrypt the key.
No default value
Confirm Pass Phrase
Confirms the name of the pass phrase used to encrypt the key.
No default value
Chain
Specifies or builds a certificate chain file that a client can use to authenticate the profile. For more information, see Configuring a certificate chain .
No default value
Trusted Certificate Authorities
Configures certificate verification by specifying a list of client or server CAs that the LTM system trusts. For more information, see Specifying trusted client CAs .
No default value
Ciphers
Specifies the list of ciphers that the LTM system supports. For more information, see Specifying SSL ciphers .
Default
Options
Specifies the value All Bugfixes Enabled, which enables a set of industry-related miscellaneous workarounds related to SSL processing. For more information, see Configuring workarounds .
All Bugfixes Enabled
ModSSL Methods
Enables or disables ModSSL method emulation.
Unchecked
Cache Size
Specifies the number of sessions in the SSL session cache.
Note: This setting applies to client-side profiles only.
20000
Cache Timeout
Specifies the timeout value in seconds of the SSL session cache entries.
Note: This setting applies to client-side profiles only.
300
Alert Timeout
Specifies the duration in seconds of the timeout of the SSL session cache.
Indefinite
Renegotiate Period
Forces the specified period of SSL renegotiation.
Indefinite
Renegotiate Size
Forces the specified throughput size, in bytes, of SSL renegotiation.
429496729
Renegotiate Max Record Delay
Forces the maximum record delay of SSL renegotiation.
Note: The Renegotiate Max Record Delay attribute applies to client-side profiles only.
Indefinite
Unclean Shutdown
Configures the LTM system to enable or disable unclean SSL shutdowns.
Checked
Strict Resume
Configures the LTM to enable or disable the resumption of SSL sessions after an unclean shutdown.
Unchecked

 

Before configuring an SSL profile, it is helpful to have a description of certain settings that you might want to change.

Specifying a certificate name

The value of the Certificate setting is the name of the certificate that you installed on the LTM system for the purpose of authenticating client-side or server-side SSL connections. If you have not generated a certificate request nor installed a certificate on the LTM system, you can specify the name of the default certificate, default. For more information on certificates, see Understanding certificate verification .

Specifying a key name

The value of the Key setting is the name of the key that you installed on the LTM system for the purpose of authenticating either client-side or server-side SSL connections. If you have not generated a key request nor installed a key on the LTM system, you can specify the name of the default key, default.

For more information on keys, see Understanding certificate verification .

Configuring a certificate chain

In any client verification process, not only does the LTM system need to authenticate the client, but the client might need to authenticate the LTM system. However, a certificate that the LTM system uses to authenticate itself to a client is sometimes signed by an intermediate CA that is not trusted by that client. In this case, the LTM system might need to use a certificate chain. The profile enables you to specify the name of a specific certificate chain file. Note that the certificate files that make up the chain file must be in PEM format.

Specifying trusted client CAs

For client-side SSL processing, you can configure an SSL profile to verify certificates presented by a client or a server. Using the Trusted Certificate Authorities setting, you can specify a client trusted CAs file name, which the LTM system then uses to verify client or server certificates. If you do not configure a trusted CAs file, the profile 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 LTM system, the system uses the default file name.

Specifying SSL ciphers

For each SSL profile, you can specify the ciphers available for SSL connections. When configuring ciphers, you must ensure that the ciphers configured for the SSL profile match those of the client sending a request, or of the server sending a response.

For example, a client might connect to and successfully establish an SSL connection to an SSL profile that is configured to use both client-side and server-side SSL. After the client sends additional data (such as an HTTP request), the SSL profile attempts to establish an SSL connection to a server. However, the SSL profile might be configured to enable only 3DES ciphers for server-side SSL, and the servers might be configured to accept only RC4 ciphers. In this case, the SSL handshake between the SSL profile and the server fails because there are no common ciphers enabled. This results in the client connection being closed. If the client is using a browser, the user is likely to receive an error message indicating that the web page failed to load.

You can specify a string to indicate the available list of SSL ciphers, or you can use the default cipher string, DEFAULT. For Client SSL profiles, the definition of the DEFAULT cipher string is ALL:!SSLv2:@SPEED. For Server SSL profiles, the definition of the DEFAULT cipher string is COMPAT+HW:@SPEED.

The ciphers that the LTM system supports are:

  • SSLv2
  • SSLv3
  • TLSv1
  • SGC/Set-up
  • All standard protocol extensions and ciphers described in RFC 2246
  • AES ciphers (described in RFC 3268)

We do not recommend use of the SSLv2 cipher unless necessary. Therefore, concerned users should set the cipher string to DEFAULT:-SSLv2.

Note

The LTM system supports the cipherlist format of OpenSSL version 0.9.7.

Tip


In addition to specifying ciphers in an SSL profile, you can insert cipher specifications into the header of an HTTP request and then direct traffic based on those ciphers. For more information, see Chapter 13, Writing iRules.

Configuring workarounds

OpenSSL supports a set of defect workarounds and SSL options. You can enable these workarounds and options as settings of an individual client-side or server-side SSL profile. The default value for the Options setting is All Options Disabled. The value ALL_BUGFIXES enables all workarounds in the set.

Table 7.4 lists and describes the possible workarounds and options that you can configure for an SSL profile.

Table 7.4 Workarounds and other SSL options
SSL Attribute
Description
All Bugfixes Enabled
This option enables all of the defect workarounds that this table describes. It is usually safe to use the All Bugfixes Enabled option to enable the defect workaround options when you want compatibility with broken implementations.
Cipher server preference
When the LTM system chooses a cipher, this option uses the server's preferences instead of the client preferences. When this option is not set, the SSL server always follows the client's preferences. When this option is set, the SSLv3/TLSv1 server chooses by using its own preferences. Due to the different protocol, for SSLv2 the server sends its list of preferences to the client, and the client always chooses the cipher.
Don't insert empty fragments
This option disables a countermeasure against a SSL 3.0/TLS 1.0 protocol vulnerability affecting CBC ciphers. These ciphers cannot be handled by certain broken SSL implementations. This option has no effect for connections using other ciphers.
Ephemeral RSA
This option uses ephemeral (temporary) RSA keys when doing RSA operations. According to the specifications, this is only done when an RSA key can only be used for signature operations (namely under export ciphers with restricted RSA key length). By setting this option, the LTM system always uses ephemeral RSA keys. This option breaks compatibility with the SSL/TLS specifications and can lead to interoperability problems with clients, and we therefore do not recommend it. You should use ciphers with EDH (ephemeral Diffie-Hellman) key exchange instead. This option is ignored for server-side SSL.
Netscape CA DN bug workaround
This option handles a defect regarding system instability. If the system accepts a Netscape browser connection, demands a client cert, has a non-self-signed CA that does not have its CA in Netscape, and the browser has a certificate, then the system crashes or hangs.
Netscape demo cipher change bug workaround
This option deliberately manipulates the SSL server session resumption behavior to mimic that of certain Netscape servers (see the Netscape reuse cipher change bug workaround description). We do not recommend this option for normal use and it is ignored for server-side SSL processing.
Netscape reuse cipher change bug workaround
This option handles a defect within Netscape-Enterprise/2.01 (https://merchant.neape.com), only appearing when connecting through SSLv2/v3 then reconnecting through SSLv3. In this case, the cipher list changes.
First, a connection is established with the RC4-MD5 cipher list. If it is then resumed, the connection switches to using the DES-CBC3-SHA cipher list. However, according to RFC 2246, (section 7.4.1.3, cipher_suite) the cipher list should remain RC4-MD5.
As a workaround, you can attempt to connect with a cipher list of DES-CBC-SHA:RC4-MD5 and so on. For some reason, each new connection uses the RC4-MD5 cipher list, but any re-connect ion attempts to use the DES-CBC-SHA cipher list. Thus Netscape, when reconnecting, always uses the first cipher in the cipher list.
No SSLv2
Do not use the SSLv2 protocol.
No SSLv3
Do not use the SSLv3 protocol.
No session resumption on renegotiation
When the LTM system performs renegotiation as an SSL server, this option always starts a new session (that is, session resumption requests are only accepted in the initial handshake). The system ignores this option for server-side SSL processing.
N0 TLSv1
Do not use the TLSv1 protocol.
Microsoft big SSLV3 buffer
This option enables a workaround for communicating with older Microsoft applications that use non-standard SSL record sizes.
Microsoft IE SSLV2 RSA padding
This option enables a workaround for communicating with older Microsoft applications that use non-standard RSA key padding. This option is ignored for server-side SSL.
PKCS1 check 1
This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect vulnerability to particular SSL server vulnerabilities. We do not recommend this option for normal use. The system ignores this option for client-side SSL processing.
PKCS1 check 2
This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect vulnerability to particular SSL server vulnerabilities. We do not recommend this option for normal use. The system ignores this option for client-side SSL processing.
Single DH use
This option creates a new key when using temporary/ephemeral DH parameters. You must use this option if you want to prevent small subgroup attacks, when the DH parameters were not generated using "strong" primes (for example, when using DSA-parameters). If "strong" primes were used, it is not strictly necessary to generate a new DH key during each handshake, but we do recommend this. You should enable the Single DH use option whenever temporary/ephemeral DH parameters are used.
SSLEAY 080 client DH bug workaround
This option enables a workaround for communicating with older SSLeay-based applications that specify an incorrect Diffie-Hellman public value length. This option is ignored for server-side SSL.
TLS D5 bug workaround
This option is a workaround for communicating with older TLSv1-enabled applications that specify an incorrect encrypted RSA key length. This option is ignored for server-side SSL.
TLS block padding bug workaround
This option enables a workaround for communicating with older TLSv1-enabled applications that use incorrect block padding.
TLS rollback bug workaround
This option disables version rollback attack detection. During the client key exchange, the client must send the same information about acceptable SSL/TLS protocol levels as it sends during the first hello. Some clients violate this rule by adapting to the server's answer. For example, the client sends an SSLv2 hello and accepts up to SSLv3.1 (TLSv1), but the server only understands up to SSLv3. In this case, the client must still use the same SSLv3.1 (TLSv1) announcement. Some clients step down to SSLv3 with respect to the server's answer and violate the version rollback protection. This option is ignored for server-side SSL.

 

Note that when configuring protocol versions, you must ensure that the protocol versions configured for the LTM system match those of the system's peer. That is, protocol versions specified in the client-side SSL profile must match those of the client, and protocol versions specified in the server-side SSL profile must match those of the server. Thus, for both client-side and server-side SSL connections, you can specify the protocol versions that you do not want the LTM system to allow.

You can declare up to two of the three protocol versions to be invalid: SSLv2, SSLv3, and TLSv1. If no protocol versions are specified, the LTM system allows all SSL protocol versions.

Note

We recommend that at a minimum you specify protocol version SSLv2 as invalid.

To specify workaround options, locate the Options setting and select Options List. This displays the Options List setting. From the Options List setting, select any of the options you wish to configure, and click the Enable button.

Configuring the SSL session cache

For client-side profiles only, you can configure timeout and size values for the SSL session cache. Because each profile maintains a separate SSL session cache, you can configure the values on a per-profile basis.

Setting SSL session cache size

Using the Configuration utility, you can specify the maximum size of the SSL session cache. The default value for the size of the SSL session cache is 20,000 entries. A value of 0 disallows session caching.

Note this setting applies to client-side profiles only.

You configure the client-side values for the maximum size of the session cache on a per-profile basis. To specify an SSL session cache size, locate the Cache Size setting and retain the default cache-size value or type a new value.

Setting SSL session cache timeout

Using the Configuration utility, you can specify the number of usable lifetime seconds of negotiated SSL session IDs. The default timeout value for the SSL session cache is 300 seconds. Acceptable values are integers greater than or equal to 5.

Clients attempting to resume an SSL session with an expired session ID are forced to negotiate a new session.

Note this setting applies to client-side profiles only.

You configure the client-side values for the session cache timeout on a per-profile basis. To specify an SSL session cache timeout value, locate the Cache Timeout setting and retain the default cache timeout value or type a new value.

Warning

If the timeout value for the client-side SSL session cache is set to zero, the SSL session IDs negotiated with that profile's clients remain in the session cache until the cache is filled and the purging of entries begins. Setting a value of zero can introduce a significant security risk if valuable resources are available to a client that is reusing those session IDs. It is therefore common practice to set the SSL session cache timeout to a length of time no greater than 24 hours, and for significantly shorter periods.

To specify an SSL session cache timeout, locate the Cache Timeout setting, and retain the default value or, from the list, select Specify, Immediate, or Indefinite. If you select Specify, type a value.

Specifying an alert timeout

The Alert Timeout setting represents the duration in seconds of the timeout of entries in the SSL session cache.

Forcing renegotiation of SSL sessions

Long-lived connections are susceptible to man-in-the-middle attacks. To prevent such attacks, you can force the LTM system to renegotiate SSL sessions, based on either time period or application size. You can also force the LTM system to terminate an SSL session after receiving a specified number of records.

Renegotiating sessions based on a time period

The Renegotiate Period setting forces the LTM system to renegotiate an SSL session after the number of seconds that you specify.

To specify a renegotiation period, locate the Renegotiate Period setting and retain the Indefinite value or select Specify. If selecting Specify, type a value.

Renegotiating sessions based on application data size

The Renegotiate Size setting forces the LTM system to renegotiate an SSL session after the specified number of megabytes of application data have been transmitted over the secure channel.

To specify a renegotiation size, locate the Renegotiate Size setting and retain the default value or type a new value.

Specifying the maximum record delay

While the LTM system waits for the client to initiate a renegotiation, the Renegotiate Max Record Delay setting forces the LTM system to terminate an SSL session after receiving the specified maximum number of SSL records. If the LTM system receives more than the maximum number of SSL records, it closes the connection.

To specify a maximum record delay, locate the Renegotiate Max Record Delay setting and retain the Indefinite value or select Specify. If selecting Specify, type a value.

Configuring SSL shutdowns

With respect to the shutdown of SSL connections, you can configure two settings on the LTM system: Unclean Shutdown and Strict Resume.

Disabling unclean SSL shutdowns

In an unclean shutdown, underlying TCP connections are closed without exchanging the required SSL shutdown alerts. However, you can disable unclean shutdowns and thus force the SSL profile to perform a clean shutdown of all SSL connections by configuring this setting.

This feature is especially useful with respect to the Internet Explorer browser. Different versions of the browser, and even different builds within the same version of the browser, handle shutdown alerts differently. Some versions or builds require shutdown alerts from the server, while others do not, and the SSL profile cannot always detect this requirement or lack of it. In the case where the browser expects a shutdown alert but the SSL profile has not exchanged one (the default setting), the browser displays an error message.

By default, the LTM system performs unclean shutdowns of all SSL connections. To disable unclean shutdowns, locate the Unclean Shutdown setting and clear the check box.

Discontinuing SSL sessions

You can configure the LTM system to discontinue an SSL session after an unclean shutdown. By default, this setting is disabled, which causes the LTM system to resume SSL sessions after an unclean shutdown. If you enable this setting, the LTM system does not resume SSL sessions after an unclean shutdown.

To discontinue SSL sessions after an unclean shutdown, locate the Strict Resume setting and check the box.

Configuring client or server authentication settings

This section describes the settings that appear in the Client Authentication section of a Client SSL Profile screen, or the Server Authentication section of a Server SSL Profile screen. For information on configuring the other SSL profile settings, see Configuring general properties of an SSL profile , and Configuring configuration settings .

For the procedure to create or modify an SSL profile, see Chapter 5, Understanding Profiles .

Table 7.6 lists and describes the authentication settings of a Client or Server SSL profile. For those settings that have default values, you can retain those default settings or modify them. Following this table are descriptions of the settings.

Table 7.6 Authentication settings in an SSL profile
Setting
Description
Default Value
Client or Server Certificate
Configures the SSL profile to either request, require, or ignore certificates presented by a client or a server.
Ignore
Frequency
Specifies whether the profile should authenticate a client once per session, or once per session and upon each subsequent reuse of an SSL session. For more information, see Configuring per-session authentication .
Once
Advertised Trusted Certificate Authorities
Specifies the CAs that you would like to advertise to clients as being trusted by the profile. For more information, see Advertising a list of trusted client CAs .
Note: This attribute applies to client-side profiles only.
No default value
Certificate Chain Traversal Depth
Specifies the maximum number of certificates that can be traversed in a client certificate chain. For more information, see Configuring authentication depth .
9
Authenticate Name
Authenticates a target server based on the Common Name (CN) embedded in a server certificate. For more information, see Configuring name-based authentication .
Note: This attribute applies to server-side profiles only.
No default value
Certificate Revocation List (CRL)
Configures certificate revocation by maintaining a list of revoked client certificates. For more information, see Certificate revocation .
No default values

 

Configuring certificate presentation

By configuring the Client Certificate or Server Certificate setting, you can cause the LTM system to handle authentication of clients or servers in certain ways.

For client-side processing, the possible values of the Client Certificate setting are:

  • 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.
  • Require
    Require a client to present a valid and trusted certificate before granting access.
  • Ignore
    Ignore a certificate (or lack of one) and therefore never authenticate the client. The ignore setting is the default setting, and when used, causes any per-session authentication setting to be ignored. For information on configuring per-session authentication, see Configuring per-session authentication .
  • Auto
    Ignore a client certificate until an authentication module requests one. In this case, the LTM system initiates a mid-session SSL handshake, as though the option were set to request. We recommend this setting only for those connections for which the presentation of client certificate is not required.
Warning

If you are using the LDAP-based client authorization feature, use of the request or ignore options can sometimes cause a connection to terminate. For more information on LDAP-based client authorization, see Chapter 8, Authentication Application Traffic.

Tip


The request option 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 LTM 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 values of the Server Certificate setting 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 setting is the default setting, and when used, causes any per-session authentication setting to be ignored. For information on configuring per-session authentication, see Configuring per-session authentication .

Configuring per-session authentication

With the Frequency setting, you can configure an SSL profile to require authentication either once per SSL session (once), or once upon each subsequent reuse 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 only need to verify a certificate once per session. We recommend 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 reuse of an SSL session.

Advertising a list of trusted client CAs

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 server is likely to trust. You can do this by configuring the Advertised Trusted Certificate Authorities setting.

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 profile trusts. The client certificate CA file solves this problem by allowing the profile to advertise a list of CAs that is different from the actual client trusted CAs file configured as part of certificate verification.

Tip


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 client certificate CA option to match the actual client trusted CAs file. 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.

To configure the profile to send this list, you can specify a PEM-formatted certificate file that contains one or more CAs that a server trusts for client authentication. If no Client Certificate CA file is specified, no list of trusted CAs is sent to a client.

Configuring authentication depth

Using the Certificate Chain Traversal Depth setting, you can configure the maximum number of 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. If the authentication depth value is set to zero, then only the client or server certificate, and one of the chain files, are examined.

Configuring name-based authentication

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

Certificate revocation

The Certificate Revocation List (CRL) setting allows the LTM system to use CRLs to check revocation status of a certificate prior to authenticating a client or server.

To configure CRLs for an SSL profile, you must configure a CRL file, which contains a list of revoked client or server certificates. When specifying a list of revoked certificates, the file that you specify must be a PEM-formatted file.

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, the LTM system 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 issuing the following command from the /config/ssl/ssl.crl directory: openssl crl -in <crlname> -text -noout.

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. For more information, see Chapter 8, Authenticating Application Traffic .

Managing SSL profiles

Using the Configuration utility, you can view SSL profiles and delete any custom profiles that you have created. Note, however, that you cannot delete the default profiles clientssl and serverssl.

For the procedures on creating and modifying SSL profiles, see Chapter 5, Understanding Profiles .

To view or delete an SSL profile

  1. On the Main tab, expand Local Traffic.
  2. Click Profiles.
    The Profiles screen opens.
  3. From the SSL menu, choose Client or Server.
    This displays a list of any existing client-side or server-side profiles.
  4. To delete a profile:
    1. Click the box to the left of the custom profile that you want to delete.
    2. Click Delete.
      A confirmation screen appears.
  5. Click Delete.
    This removes the profile.
  6. To view details of an SSL profile, in the Name column, click the name of the profile that you want to view.
    This displays the profile details.

Tip


When listing existing profiles, you can use the Search box that appears directly above the profile list. With the Search box, you can specify a string to filter the list, thereby showing only those objects that match the string. The default setting is an asterisk (*), which means show all objects.



Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)