Hidden Gems series - part 6

Ann_Marie_Bond · June 29, 2015, 11:14am

Issue 2, 2

Secure communications in webMethods Integration Server

Welcome to another Hidden Gem, where we will highlight a lesser-known but valuable feature of the webMethods suite. There are many such hidden gems that you might not have stumbled upon in training or documentation. These gems could make your life easier or your implementation even better. This edition’s hidden gem describes the Java® Secure Sockets Extension (JSSE) feature, introduced in webMethods Integration Server 9.5, and how you can configure it for enhanced security.

What is JSSE?

JSSE is a feature of the Java run-time that implements the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols for secure network communications. It encompasses a set of packages that includes functionality for data encryption, server authentication, message integrity and more.

Why JSSE?

A core tenet of a secure application is protecting the transport layer for inbound and outbound connections. webMethods Integration Server supports TLS and its predecessor, SSL, as cryptographic protocols to provide communications security over a network. These protocols enable webMethods Integration Server to encrypt the data of network connections via public key cryptography.

By default, webMethods Integration Server uses Entrust, a commercial security toolkit for Java®, to implement TLS/SSL. While this has been satisfactory for many years, there have been advances in the protocol and a number of vulnerabilities identified with older versions that make moving to a newer implementation a good idea.

Therefore, Integration Server 9.5 and later versions provide an option to use JSSE in addition to the internal provider for TLS/SSL connections.

Really, really strong crypto

Assuming you are in a country that allows it, you can download an extra policy file for JSSE from the Java website. This policy allows much higher strength cryptography to be used. If you don’t have this policy file, you’re limited to 128-bit Advanced Encryption Standard (AES) encryption. The strongest available using the policy file is now 256-bit AES encryption. You can tell if you have the strongest policy installed by reviewing the Integration Server log. If you see the following message, the policy file is not installed:

[ISS.0025.0041I] FIPS mode not initialized
[ISS.0025.0050I] The JCE Unlimited Strength Jurisdiction Policy File was not found. Please install it

Once the policy is installed in the jre/lib/security directory and the server is restarted, you will see this message:

[ISS.0025.0041I] FIPS mode not initialized
[ISS.0025.0049I] The JCE Unlimited Strength Jurisdiction Policy File was 

found

Installing this file does not mandate 256-bit cryptography; it just allows it to be used if both client and server support it.

Setting up HTTPS ports to use JSSE

To enable JSSE on an HTTPS port, simply select the "Use JSSE" radio button on the port configuration as shown in Figure 1.

Figure 1: JSSE is enabled for use on an HTTPS port as a default setting in Integration Server 9.7.

Note: This setting is the default as of Integration Server 9.7

After the port is enabled, you can use any modern browser (Firefox®, Internet Explorer® 11+, Chrome™ 30+) and connect with the most secure cryptography available. Figure 2 shows RSA with 128-bit AES crypto using SHA-256 signatures.

Figure 2: Connect with the most secure cryptography available.

Advanced settings

While the default settings for JSSE are good for most environments, there are custom settings that allow finer control of this feature.

To restrict which version of TLS/SSL is supported, you can set the enabledProtocols property. The default is to allow all TLS 1.0 and later:

watt.net.jsse.client.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2
watt.net.jsse.server.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2

Cipher suite lists allow fine-grained control of exactly which algorithms should be used on a particular connection. This may be needed if the default list is not acceptable for compliance reasons. Cipher suite names can be found in TLS/SSL documents (i.e., RFC 2246, RFC 4346, and RFC 5246 section A.5). Note that TLS 1.1 and 1.2 cipher suites are only available on Java 7 and later. The properties used to limit cipher suites in JSSE are:

watt.net.jsse.client.enabledCipherSuiteList=default
watt.net.jsse.server.enabledCipherSuiteList=default

For legacy (non-JSSE) ports, the following properties apply:

watt.net.ssl.client.cipherSuiteList=default
watt.net.ssl.server.cipherSuiteList=default

For example, to use a particular cipher, set the following statement:

watt.net.jsse.server.enabledCipherSuiteList=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

This is a server-wide setting that affects all ports configured to use JSSE.

Debugging

Typically things can go wrong when first getting TLS/SSL/HTTPS ports running. Fortunately, JSSE provides a Java® Development Kit (JDK) debug setting to provide more information about TLS/SSL connections. To apply the setting, add javax.net.debug=SSL to the watt.config.systemProperties setting and restart the Integration Server as shown in Figure 3.

Figure 3: Start the JDK debug setting to evaluate TLS/SSL/HTTPS ports and connections.

For more information on debugging and JSSE, read the Java Secure Socket Extension (JSSE) Reference Guide.

Discuss your security best practices with your webMethods community colleagues on the Tech Community ESB and Integration Server group.