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=trueHint: 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:
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=trueStarting with OpenJ9, you can use the OpenJDK options as in every other JVM:
-Dcom.sun.net.ssl.checkRevocation=true
-Dcom.sun.security.enableCRLDP=trueTo 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 < 256Tip 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 < 3072Tip 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=trueTip 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=trueNow 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:verboseSource: 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!