OpenSSL supports a set of SSL options and defect workarounds. 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 Options List. Retaining the default value enables one option, which is Don’t insert empty fragments. You can then enable other options that appear in the Available Options list.

Note that when configuring protocol versions, you must ensure that the protocol versions configured for the BIG-IP 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 BIG-IP system to allow.

You can enable or disable ModSSL method emulation. You enable ModSSL method emulation when the OpenSSL methods are inadequate. When you enable this setting, you can then write an iRule, using the HTTP::header insert_modssl_fields command, which inserts some of the ModSSL options as headers into HTTP requests.

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.

You can specify the duration in seconds that the BIG-IP system waits while trying to close an SSL connection, before the connection is reset. The default timeout value for this setting is 10 seconds.

You can specify the amount of time in seconds that the BIG-IP system spends attempting to perform an SSL handshake. The default timeout value for this setting is 10 seconds.

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

The Server Name setting in an SSL profile specifies the name of the specific domain from which the client requests a certificate. This setting supports a feature known as TLS Server Name Indication (TLS SNI), used when a single virtual IP server needs to host multiple domains.

For example, suppose that the BIG-IP system needs to host the two domains domain1.com and domain2.com, on the same HTTP virtual server. Each domain has its own server certificate to use, such as domain1.crt and domain2.crt, and each has different security requirements.

To ensure that the BIG-IP system presents the correct certificate to the browser, you enable SNI, which sends the name of a domain as part of the TLS negotiation. This, in turn, enables the BIG-IP system to select this domain rather than waiting to read the domain name in the request header.

To enable SNI, you configure the Server Name and other TLS-related settings on an SSL profile, and then assign the profile to a virtual server.

Note that the wildcard character (*) is supported within any domain name that you specify.

When you enable the Default SSL Profile for SNI setting on an SSL profile, you are specifying that this is the default SSL profile to use when the client provides either no Server Name Indication (SNI) extension, or provides a non-matching SNI extension.

When assigning multiple SSL profiles to a single virtual server, you can enable this setting on one Client SSL profile only and one Server SSL profile only.

If you enable the Require Peer SNI Support setting on an SSL profile, the domain name of the peer must match the domain name that you specify in the Default SSL Profile for SNI field.

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, this setting is enabled, which means that Local Traffic Manager performs unclean shutdowns of all SSL connections.

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

To enhance system performance, you can enable the use of session tickets, a TLS extension defined in RFC 5077. The use of session tickets is an alternative to the standard session caching mechanism that systems such as the BIG-IP system typically use to resume sessions.

When you enable this feature, the BIG-IP system, acting as a server to terminate SSL connections, sends a special message to the client as part of the SSL handshake. This message includes a session ticket, which contains complete session state information. Sending the session state information to the client removes the need for the BIG-IP system to maintain a server-side cache for storing session information. With session tickets, the entire session state is remembered by the client.

The session state information in the ticket includes the master secret negotiated between the client and the BIG-IP system, as well as the cipher suite used.

By default, when an SSL failure occurs, the BIG-IP system sends an alert message with a numeric code indicating the type of failure. If you do not want alert messages to indicate the specific reason for the failure, for security reasons, you can enable the Generic Alerts setting on an SSL profile. Enabling this setting causes the BIG-IP system to label all failure alerts as handshake failures, with a code of 40. For example, a failure due to a certificate revocation is normally flagged with a code of 48, but with the Generic Alerts setting enabled, the alert is coded as 40.

You can configure Local Traffic Manager to accept connections that are not SSL connections. In this case, connections pass through the BIG-IP system in clear-text format. By default, this setting is disabled.

You can specify the specific hash algorithm that you want the BIG-IP system to use for server key exchange with Elliptic Curve ciphers. Possible choices are SHA1, SHA256, SHA384, or Any. When you select Any, you authorize the system to choose any one of the hash algorithms. Note that in this case, the BIG-IP system chooses SHA1 whenever possible.