Manual Chapter :
Additional SSL Profile Configuration Options
Applies To:
Show Versions
BIG-IP APM
- 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
BIG-IP Analytics
- 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
BIG-IP LTM
- 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
BIG-IP PEM
- 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
BIG-IP AFM
- 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
BIG-IP DNS
- 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
BIG-IP ASM
- 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
Additional SSL Profile Configuration Options
SSL options and defect workarounds
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.For security reasons, when you enable the Proxy SSL setting, the BIG-IP system automatically disables the
Don’t insert empty
fragments option
. Disabling this option when Proxy SSL is enabled guards against a
particular type of cryptographic attack.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.
F5 Networks recommends that, at a minimum, you specify protocol version SSLv2 as
invalid.
Workarounds and other SSL options
This table lists and describes the possible workarounds and options that you can
configure for an SSL profile.
SSL Attribute |
Description |
|---|---|
Cipher server preference |
When the BIG-IP 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.
This is the default value for the Options list. For security
reasons, this option is not available when you enable the Proxy SSL setting. |
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, Local Traffic Manager 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. |
Microsoft session ID bug |
This option handles a Microsoft session ID problem. |
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 challenge bug |
This option handles the Netscape challenge problem. |
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, 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 SSL |
Do not use the SSL protocol. |
No SSLv2 |
Do not use the SSLv2 protocol. |
No SSLv3 |
Do not use the SSLv3 protocol. |
No session resumption on renegotiation |
When Local Traffic Manager 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. |
No TLS |
Do not use the TLS protocol. |
No 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. |
Passive close |
Specifies that the SSL filter helps prevent packets from getting into the TCP
half-closed state by waiting for a connection shutdown from the server. This is a
workaround for HTTP/1.0 and HTTP/0.9 clients that send an HTTP request followed by a
FIN, which immediately closes the connection for server-SSL-only proxies. Instead of
closing immediately, the proxy waits for the server to close. |
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. |
SSL Ref2 reuse cert type bug |
This option handles the SSL re-use certificate type problem. |
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. |
ModSSL methods
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.ModSSL options for use with iRules
This table lists the options that you can insert into an HTTP request.
Header Type |
Header Name and Format |
Description |
|---|---|---|
Certificate status |
SSLClientCertStatus: [status] |
The status of the client certificate. The value of [status] can be NoClientCert,
OK, or Error. If status is NoClientCert, only this header is inserted into the request. If
status is Error, the error is followed by a numeric error code. |
Certificate version |
SSLClientCertVersion: [version] |
The version of the certificate. |
Certificate serial number |
SSLClientCertSerialNumber: [serial] |
The serial number of the certificate. |
Signature algorithm of the certificate |
SSLClientCertSignatureAlgorithm: [alg] |
The signature algorithm of the certificate. |
Issuer of the certificate |
SSLClientCertIssuer: [issuer] |
The issuer of the certificate. |
Certificate validity dates |
SSLClientCertNotValidBefore: [before]
SSLClientCertNotValidAfter: [after] |
The validity dates for the certificate. The certificate is not valid before or
after the dates represented by [before] and [after] ,
respectively. |
Certificate subject |
SSLClientCertSubject: [subject] |
The subject of the certificate. |
Public key of the subject |
SSLClientCertSubjectPublicKey: [key] |
The type of public key type. The allowed types are RSA ([size] bit), DSA, or
Unknown public key. |
The certificate itself |
SSLClientCert: [cert] |
The actual client certificate. |
MD5 hash of the certificate |
SSLClientCertHash: [hash] |
The MD5 hash of the client certificate. |
SSL session cache size and timeout
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.
SSL session cache size
You can specify the maximum size of the SSL session cache. The default value for the size of
the SSL session cache is 262144 entries. A value of
0
disallows session
caching.SSL session cache timeout
You can specify the number of usable lifetime seconds of negotiated SSL session IDs. The
default timeout value for the SSL session cache is
3600
seconds. If you
specify a timeout value, valid values are integers greater than or equal to 1.Clients attempting to resume an SSL session with an expired session ID are forced to negotiate a new session.
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.
Alert timeout
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.
Handshake timeout
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.
Renegotiation of SSL sessions
Long-lived connections are susceptible to man-in-the-middle attacks. To prevent such attacks,
you can force the BIG-IP system to renegotiate SSL sessions, based on
either time period or application size. You can also force the BIG-IP system to terminate an
SSL session after receiving a specified number of records.
More specifically, you can control, on a per-connection basis, the way that the system responds
to mid-stream SSL reconnection requests. When you enable renegotiation, the system processes
mid-stream SSL renegotiation requests. When you disable renegogiation, the system either
terminates the connection or ignores the request, depending on the system configuration. By
default, renegotiation is enabled.
Sessions based on a time period
You can specify the number of seconds from the initial connect time that the system
renegotiates an SSL session. The options are a number you specify, indefinite, and default. The
default is indefinite, meaning that you do not want the system to renegotiate SSL sessions. Each
time the session renegotiation is successful, essentially a new connection is started. Therefore,
the system attempts to renegotiate the session again in the specified amount of time following
the successful session renegotiation. For example, setting the
renegotiate
period
to 3600
seconds triggers session renegotiation at
least once an hour.Sessions based on application data size
You can force Local Traffic Manager™ to renegotiate an SSL session after
the specified number of megabytes of application data have been transmitted over the secure
channel. The default value for this setting is
Indefinite
.Maximum record delay
You can force Local Traffic Manager™ (LTM) to terminate an SSL session after
receiving the specified maximum number of delayed SSL records. If LTM receives
more than the specified number of delayed SSL records, the system closes the connection. The default value for this setting is
Indefinite
.Secure renegotiation
The Secure Renegotiation setting specifies the method of secure renegotiation for SSL connections. The default value for the Client SSL profile is Require; the default value for the Server SSL profile is Require Strict. If your configuration does not require secure SSL renegotiation, set this value to Request. The possible values for this setting are:
- Request
- Specifies that the system requests secure renegotiation of SSL connections.
- Require
- Specifies that the system requires secure renegotiation of SSL connections. In this mode, the system permits initial SSL handshakes from clients, but terminates renegotiations from unpatched clients.
- Require Strict
- Specifies that the system requires strict secure renegotiation of SSL connections. In this mode, the system refuses new SSL connections to unsecure servers and terminates existing SSL connections to unsecure servers.
Maximum reneogtiations
You can specify the maximum number of SSL records per minute that the system can receive before renegotiating an SSL session. After receiving this number of SSL records, the system closes the connection. This setting applies to client profiles only. By default, the system receives five records per minute before reneogiating the session.
Maximum aggregate renegotiations
You can specify a maximum number of aggregate SSL renegotiations, to ensure that the
configured per-flow maximum renegotiation rate limit is enforced. Specifying a maximum number of
aggregate renegotiations prevents the opening of new connections as a way to bypass the per-flow
limit. Allowed values are from
0
through 0xFFFFFFFF
.Server name
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.
Default SSL Profile for SNI
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.
Require Peer SNI Support
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.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, this setting is enabled, which means that Local Traffic
Manager™ performs unclean shutdowns of all SSL connections.
Strict Resume
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.
About session tickets
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.
Generic alerts
For security reasons, when sending an SSL alert message, the BIG-IP
system sends a generic
handshake failure
message with an alert code of 40, with no detailed
information. This is the default behavior.If you want SSL alert messages to include the specific reason for the failure, you can disable
the
Generic Alerts
setting. In this case, when an SSL failure occurs, the
system sends an alert message with a specific numeric code. For example, an alert message due to
a certificate revocation would show a specific code of 48 instead of the generic code of 40.Acceptance of non-SSL connections
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.
SSL sign hash
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.About SSL handshake limits
A reboot or reset action can sometimes produce an excessive number of SSL handshakes, which can
impact normal BIG-IP system operation. To prevent this from happening, you
can use the
Max Active Handshakes
setting on a Client SSL or Server SSL
profile to limit the number of concurrent handshakes.When the number of active SSL handshakes pertaining to an SSL profile reaches the specified
limit, the system terminates the most recent SSL handshake, and the BIG-IP system displays a
message that the specified handshake limit has been reached. The system also sends an alert
message to other members of the device group.
The default setting is
Indefinite
, which means that there is no limit on
the number of active SSL handshakes that the system allows.About dynamic record
sizing
Dynamic record sizing
is a TLS
performance enhancement, designed to improve application response by preventing bottlenecks
caused by the buffering of TLS record fragments. Without dynamic record sizing, a record that
spans multiple TCP packets can cause buffering, forcing the TCP receiver to wait for all of the
TCP packets to arrive before constructing the original-sized record (typically 16 KB). Other
causes of buffering can include packet loss, packet reordering, or throttling. The result is that
the browser is left to deal with significant bottlenecks that affect performance.With dynamic record sizing, the system dynamically adjusts the size of TLS
records based on the state of the connection. For example, if a connection is idle for awhile, it
might make sense for the system to ensure a single TLS record per packet, where the size of the
TLS record is the TCP maximum segment size (MSS). For connections in another state, such as large
application streams, it might still make sense for a TLS record to span multiple packets.
To specify dynamic record sizing, you log in to the BIG-IP Configuration utility screen, and locate the screen for creating
a Client SSL profile. Then enable the
Allow Dynamic
Record Sizing
check box.About the maximum record size
The
Maximum Record Size
setting on a Client SSL profile defines the
maximum size possible for a TLS record. If you enable dynamic record sizing (for performance
enhancement), then the maximum record size you set is the largest size that the system can use
for a TLS record when that size is needed. If dynamic record sizing is disabled (the default
value), then all record size is static, and the size can be up to the maximum record size you
specify.To set the maximum record size, you log in to the BIG-IP ®Configuration
utility screen and locate the screen for creating a Client SSL profile. Then type a value for the
Maximum Record Size
setting. The default value in kilobytes (KB) is
16384
.
