Using and hardening TLS

Secure communications are a cornerstone of system security. It is now widely acknowledged that even corporate private networks should not be trusted with sensitive data, which includes interactions among the components of distributed applications. TLS, when used correctly, provides confidentiality (attackers cannot read sensitive data), integrity (attackers cannot change data), and authentication (attackers cannot impersonate parts of the system) for network communications.

TLS can be enabled for many Enterprise Server components, including:

The MLDAP ESM Module can also usually use TLS with its LDAP connection, though that is actually under the control of third-party software (the LDAP server and the LDAP provider library). Similarly, XA resources accessed over the network often support TLS connections.

Enabling TLS for these various components is covered by your product Help.
Note: TLS is very complex; Micro Focus strongly recommends that you have some technical knowledge of TLS and related technologies.

Here are some recommendations for hardening TLS:

Setting listener default TLS parameters

TLS options and parameters can be configured for each listener, but you can also set defaults for them in the mf-server.dat file. See To configure TLS default properties for listeners in your product Help for more information.

TLS protocol versions

The TLS (formerly SSL) protocol has gone through a number of protocol revisions.

The older SSLv2 and SSLv3 protocols are insecure and are not supported by Enterprise Server.

Currently TLS protocol versions are TLSv1.0, TLSv1.1, TLSv1.2, and TLSv1.3. By default, Enterprise Server components support all four TLS versions, for interoperability and backward compatibility. TLSv1.0 and TLSv1.1 are insecure and deprecated, and are disabled by default beginning with release 8.0.

Unless there is a pressing need to interoperate with peers which only support old versions of TLS, Micro Focus recommend disabling TLSv1.0 and TLSv1.1 where possible. For listeners and other components which provide a TLS protocol configuration field this can be performed by setting the protocol list to -ALL+TLS1.2+TLS1.3. See Configuring a TLS Protocols List in your product Help for more information.

Cipher suites and parameters

As with the TLS protocols, the default set of cipher suites permitted by Enterprise Server is intended for interoperability, not hardening. For TLSv1.2, if it is not necessary to support older peer systems, Micro Focus recommends either of the following options:
  • Set the cipher suite list to ALL:@SECLEVEL=3. This will enable only the suites which meet "security level 3", which requires strong algorithms and Perfect Forward Secrecy.
  • Set the cipher suite list to -ALL:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256. This is a collection of best-in-class cipher suites for TLSv1.2. Add other suites if required for interoperability.

The DH minimum group size option determines how large ephemeral Diffie-Hellman keys must be. The default for this is 2048 bits, which should provide adequate security. This can be changed to 4096, but most clients will permit the use of Elliptic Curve Diffie-Hellman (ECDH), so this setting rarely applies.

There is no need to change the TLSv1.3 cipher suite list or the list of permitted elliptic curves for hardening purposes.

Honor server cipher list

This option should be enabled. It lets the server determine the preference order of cipher suites. This is important because servers are more strictly administered, and because an attacker in a privileged position might be able to tamper with the cipher-suite list offered by the client and downgrade the conversation to the weakest suite the server offers. This option will likely be enabled by default in a future product release.