Skip to content

13 tips for securing OpenLiberty

This article covers 13 tips I collected on how to make OpenLiberty a bit more secure. Some tips may refer to making your Java Runtime more secure, others are settings you apply to IBM WebSphere Liberty or OpenLiberty.

Tip 1: Offer TLS1.2 on IBM J9

If you are using the bundled Java 8 JDK from WebSphere Liberty (not OpenLiberty), you might be using IBM J9. IBM J9 is a proprietary JVM which has its own JVM options and does not recognize a lot of options you may know from Oracle’s OpenJDK or Adoptium’s OpenJDK/Temurin Runtimes.

Older versions have TLS1.2 NOT enabled by default, even if you use SSLInstance.get("TLS"). While Hotspot/OpenJDK VMs will return any best matching TLS version, IBM J9 does not in older versions. To enable the OpenJDK/Hotspot behaviour, use this system property prior to SR6 FP25 (8.0.6.25):

-Dcom.ibm.jsse2.overrideDefaultTLS=true

Source: https://www.ibm.com/docs/en/sdk-java-technology/8?topic=customization-matching-behavior-sslcontextgetinstancetls-oracle

Hint: This also works for IBM’s Java 7! https://www.ibm.com/docs/en/sdk-java-technology/7?topic=customization-matching-behavior-sslcontextgetinstancetls-oracle

Tip 2: Prevent older TLS/SSL protocols in Liberty

Ingoing and outgoing connections should not support any version before TLSv1.2. To configure the primary outgoing protocol, add this snippet to your server.xml:

<ssl id="defaultSSLConfig
  sslProtocol="TLSv1.2"
/>

If “defaultSSLConfig” is not your default SSL config, change it accordingly.

Source: https://openliberty.io/docs/21.0.0.12/reference/config/ssl.html

Tip 3: EnabledCiphers: Do not allow all of the ciphers

You might explicitly want to disable less-secure ciphers. To do this, either use a custom list or a HIGH list, the latter being maintained by the OpenLiberty team. You can use it like so:

<ssl id="defaultSSLConfig
  securityLevel="HIGH"
/>

On how to roll your custom configuration, see this article:

Custom Cipher Lists for OpenLiberty

Tip 4: Name your SSL Config

If you have been using your custom ssl config element, did you make it the default? If not, be sure to add it as the default:

<sslDefault
  sslRef="defaultSSLConfig"
/>

Source: https://openliberty.io/docs/21.0.0.12/reference/config/sslDefault.html

Tip 5: Look up Hostnames in certificates

You can force Liberty to verify hostnames in certificates, which is always a good idea. Certificates really should match. Otherwise you might be prone to man-in-the-middle attacks.

<ssl id="defaultSSLConfig"
  verifyHostname="true"
/>
<sslDefault
  httpHostNameVerification="true"
/>

verifyHostname: Specifies whether host name verification for outbound connections using a specific SSL configuration is enabled. If set to true, then all outbound SSL connections that use the specified SSL configuration undergo verification of the target server host name against that server’s certificate. The attribute is set to false by default.

httpHostNameVerification: Specifies whether SSL outbound host name verification is enabled. The default is false. If set to true, then during the outbound SSL handshake requests, the JDK will verify that the returned certificate contains a host name that matches the outbound HTTP request.

Source: https://openliberty.io/docs/21.0.0.12/reference/config/ssl.html and https://openliberty.io/docs/21.0.0.12/reference/config/sslDefault.html

Tip 6: In-House root certificates

If you are working for a large company, you might have your own PKI with your own root certificates. If so, you really should make Liberty know about them. If you have your custom Truststore, you can add it like so:

<ssl id="defaultSSLConfig"
  trustStoreRef="MyTrustStore"
  keyStoreRef="MyKeyStore"
/>

This will be your trustStore config:

<keyStore id="MyTrustStore"
  location="/opt/mycorp/mycorp_truststore.pk12"
  password="{aes}myaespassword"
  type="PKCS12"
/>

Source: https://openliberty.io/docs/21.0.0.12/reference/config/keyStore.html

Tip 7: Ban revoked certificates

Set system properties to check for revocation using CRLs and then also enable OCSP for revocation checking (this is IBM J9):

-Dcom.ibm.jsse2.checkRevocation=true
-Dcom.ibm.security.enableCRLDP=true

Starting with OpenJ9, you can use the OpenJDK options as in every other JVM:

-Dcom.sun.net.ssl.checkRevocation=true
-Dcom.sun.security.enableCRLDP=true

To force it everywhere without JVMs to be able to disable it, you can add ocsp.enable=true to your java.security.

Tip 8: Eagerly disable weak algorithms

Weak algorithms can be disabled alltogether. They key is again the java.security file. Look for this line:

jdk.certpath.disabledAlgorithms=..., RSA keySize < 2048, DSA keySize < 2048, EC keySize < 256

Tip 9: Roll warnings for legacy algorithms

Some algorithms are still okay-ish, but you might want to see a warning when they are being used. The java.security file got you covered, again!

jdk.security.legacyAlgorithms=SHA1, \
  RSA keySize < 3072, DSA keySize < 3072

Tip 10: TLS algorithms

Yes, the very same configuration from tip 8 is also available for TLS. This is the option you want to modify:

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, \
  ..., DH keySize < 2048, EC keySize < 256 ...

Tip 11: You can use ocsp stapling!

OCSP stapling allows any middleware to send ocsp data along, e.g. loadbalancers or proxies. This is enabled by default, but make sure you did not disable it by accident!

-Djdk.tls.client.enableStatusRequestExtension=true

Tip 12: J9 SSL/TLS name confusion

Again, if you are on J9 (not OpenJ9), you can use both TLS_ and SSL_ prefixes for your ciphers. To enable oracle-like names on J9, add this option:

-Dcom.ibm.jsse2.overrideDefaultCSName=true

Now you can use the cipher list you’ve been using on OpenJ9 and Hotspot on J9, too!

Tip 13: 9 out of 10 connections fail? Enable SSL debugging

With all that hardened security, a lot of connections might fail now. To see why this happens, you can now enable SSL debugging like so:

# debug EVERYTHING
-Djavax.net.debug=all
# debug handshakes only
-Djavax.net.debug=ssl:handshake:verbose

Source: https://www.ibm.com/docs/en/sdk-java-technology/8?topic=troubleshooting-debugging-utilities

Conclusion

The list should show you which options are available on Java and on OpenLiberty. Some are set to on by default, others are not. It is always a good idea to check them from now and then and make adjustments when necessary.

Of course all this only makes sense if you do not follow security anti-patterns. Be sure to read it!

Published inHow Tos

Be First to Comment

    Leave a Reply

    Your email address will not be published. Required fields are marked *