Creating a TLS client profile

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.
  1. The server sends its certificate.
  2. Define whether the client validates the hostname in the certificate. For hostname validation, you can fine-tune the validation methods and settings.
  3. 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.
  4. Define whether to validate the server certificate against the validation credentials.
  5. 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

  1. In the search field, enter tls client.
  2. From the search results, click TLS client profile.
  3. Click Add.

Define the general settings.

  1. Define the basic properties - Name, administrative state, and comments.
  2. From the Protocols list, select the protocol versions to support.
  3. 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.
  4. 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.

  1. Set the Use custom SNI hostname property to use a custom server name instead of the SNI hostname in the ClientHello message.
  2. 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.

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

  1. 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.
  2. 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.
  3. Set the Validate server certificate property to validate the server certificate during the handshake.
  4. 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.

  1. Set the Enable session caching option.
  2. 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.
  3. 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.

  1. From the Elliptic curves list, select the elliptic curves to support.
  2. From the Hostname validation flags list, set the flags to fine-tune the validation methods and settings during the handshake.
  3. 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.
  4. From the Signature algorithms list, select the algorithms to advertise and support.
  5. Click Apply to save changes to the running configuration.
  6. Click Save to save changes to the persisted configuration.