A TLS client profile secures connections to TLS servers when the DataPower® Gateway is the TLS client.
About this task
To define a TLS client profile, you must specify the following properties.
- The TLS protocol version to support
- The ciphers in these protocol versions to support
When you configure a profile, you can define the following behavior.
- Whether to send an SNI extension in the
ClientHello
message, which is the
default behavior. You can define the server name to send in the SNI extension.
- Whether a connection is successful when
renegotiation_info
in not included in
the server response. By default, the connection fails because clients that do not support RFC 5746
are vulnerable to man-in-the-middle attacks as documented in CVE-2009-3555.
- Whether to enable compression. By default, compression is not enabled. Compression is dangerous
because the connection becomes vulnerable to CRIME attacks.
- The keystore (identification credentials) for client identity when requested by the server.
- Server validation, which can include server authentication for mutual TLS. By default, server
authentication is not enabled.
- Whether to enable session-caching of TLS sessions. By default, session-caching is not
enabled.
- Elliptic curves to support.
- Flags to fine-tune the validation methods and settings during the handshake.
- Middle box compatibility with TLSv1.3.
- Signature algorithms to advertise and support.
Attention: Do not use the same TLS client profile for IBM® MQ and other protocols. IBM MQ mandates a specific TLS configuration to secure connections
between client and server. For more information, see the IBM MQ documentation.
For mutual authentication, define server certificate validation and the handshake process for
when a client attempts to connect to a server.
- The server sends its certificate.
- Define whether the client validates the hostname in the certificate. For hostname validation,
you can fine-tune the validation methods and settings.
- Define how to handle validation failure.
- When the failure ends the handshake, no additional configuration is needed. On failure
detection, terminate the handshake and log an error
- When the failure is to log an event, processing continues. On failure detection, ignore the
failure but log a warning.
- Define whether to validate the server certificate against the validation credentials.
- Select the validation credentials to validate against.
Remember:
The profile must include at least one cipher suite that matches the associated key material.
- An RSA signing key requires ECDHE_RSA cipher suites.
- An ECDSA signing key requires ECDHE_ECDSA cipher suites.
The profile must include at least one cipher suite that matches the identification credentials.
- When the identification credentials contain RSA keys or certificates, you must specify at least
one RSA cipher suite.
- When the identification credentials contain ECDSA keys or certificates, you must specify at
least one ECDSA cipher suite.
Procedure
- In the search field, enter tls client.
- From the search results, click TLS client profile.
- Click Add.
Define the general settings.
- Define the basic properties - Name, administrative state, and
comments.
- From the Protocols list, select the protocol versions to
support.
- From the Ciphers list, select the cipher suites to support. Make
sure that the displayed order of cipher suites is in the preferred order. Otherwise, change the
sequence order to meet your preference.
- From the Features list, select the TLS client features to
support.
- Use SNI
- Whether to enable SNI to send an SNI extension in the
ClientHello
message. When
enabled, the default configuration, the client sends an SNI extension in the
ClientHello
message to the server with the DNS name that the client attempts to
connect. When enabled, you can use a custom SNI hostname or use the target as the SNI hostname in
the ClientHello
message. By default, the target is used as the SNI hostname in the
ClientHello
message.
- Permit connections without renegotiation
- Whether a connection is successful when
renegotiation_info
in not included in
the server response. The default is for the connection to fail.When enabled, the client sends
renegotiation_info
or
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
and does
not expect the server response to include
renegotiation_info
. If server response
includes
renegotiation_info
, it must match Verify Data. A successful connection
indicates one of the following conditions.
When disabled, the default configuration, the client sends
renegotiation_info
or TLS_EMPTY_RENEGOTIATION_INFO_SCSV
and
expects server response to include matching Verify Data.
- Enable compression
- Whether to enable TLS compression. By default, compression is not enabled. Compression is
dangerous because the connection becomes vulnerable to CRIME attacks. For more information, see
CRIME
attack.
When Use SNI is enabled, define the SNI extension to send in the
ClientHello
message. By default, the target is used as the SNI hostname in the
ClientHello
message.
- Set the Use custom SNI hostname property to use a custom server
name instead of the SNI hostname in the
ClientHello
message.
- In the Custom SNI hostname field, specify the user-defined server
name to send in the SNI extension.
Define the keystore to use for client identity when requested by the
server.
- Optional: From the Identification credentials list,
select the identification credentials that the client uses to identify itself to the server when
requested. Identification credentials are the keystore.
Define server validation, which can include server authentication for mutual TLS. By
default, server authentication is not enabled. For more information, see Authentication flows.
- Set the Validate server hostname property to validate the hostname
in the server certificate during the handshake. You can use the Hostname validation
flags property on the Advanced tab to fine-tune the validation
methods and settings during the handshake.
- Set the Hostname validation fail on error property to terminate
the handshake when hostname validation fails. The default behavior is to ignore the failure, log a
warning, and continue with any configured server certificate validation.
- Set the Validate server certificate property to validate the
server certificate during the handshake.
- To validate the server certificate, select the validation credentials from the
Validation credentials list. Validation credentials are the
truststore.
On the Session-caching tab, you can enable session-caching to
cache TLS sessions and define the behavior of the session. By default, session-caching is not
enabled. For more information, see TLS session cache.
- Set the Enable session caching option.
- In the Session cache timeout field, specify the duration in
seconds that sessions can remain in the cache before they are removed. Enter a value in the range 1
- 86000. The default value is 300.
- In the Session cache size field, specify the maximum number of
sessions the cache can hold. Enter a value in the range 1 - 500000. The default value is
100.
On the Advanced tab, you can define advanced TLS
options.
- From the Elliptic curves list, select the elliptic curves to
support.
- From the Hostname validation flags list, set the flags to
fine-tune the validation methods and settings during the handshake.
- Set the Enable TLSv1.3 compatibility property to enable middle box
compatibility with TLSv1.3. When enabled, dummy CCS messages are sent in TLSv1.3 but appear similar
to TLSv1.2. The effect is that middle boxes that do not understand TLSv1.3 do not drop connections.
Regardless of this setting, CCS messages from peers are ignored in TLSv1.3.
- From the Signature algorithms list, select the algorithms to
advertise and support.
- Click Apply to save changes to the running
configuration.
- Click Save to save changes to the persisted
configuration.