EditAttachPrintable
r5 - 2018-05-14 - 15:36:55 - Main.aalairdYou are here: TWiki >  Deployment Web > SecurityWhereToStart > TLSExtendedMasterSecretForWASandLiberty

Configuring TLS Extended Master Secret for WebSphere Application Server and WebSphere Libertynew.png

Authors: HongyanHuo SentellaCystrunk Contributors: JonAgnew AlexBernstein KelvinLow SkyeBischoff
Build basis: All CLM Products 6.0.6 GA

Introduction

The Rational® solution for Collaborative Lifecycle Management (CLM) 6.0.6 release includes Java JDK level V8 SR5 FP11 (8.0.5.11) in WebSphere Liberty, and at least Java JDK level 8.0.5.10 or 7.1.4.20 is recommended for WebSphere Application Server.

This set of Java upgrades includes a new Java Security requirement 1.2 TLS protocol jdk.tls.useExtendedMasterSecret (EMS). Java Extended Master Secret (EMS) requires a full handshake for each SSL/TLS connection between WebSphere Liberty and the proxy servers.

At this time, not all proxy and HTTP servers support support EMS. If you enable EMS on servers that don't support it, CLM products hosted on WebSphere Application Server or WebSphere Liberty might experience performance issues. This article outlines which environments are affected by this problem, how to diagnosis it, and how to configure your server to resolve it.

Affected deployments

WebSphere Application Server and WebSphere Liberty deployments are affected with these JDK levels:
  • V8 SR5 FP10 (8.0.5.10)
  • 7 SR10 FP20 (7.0.10.20)
  • 7 R1 SR4 FP20 (7.1.4.20) and above
The deployments must also have a proxy or web server that does not support or enable Extended Master Secret (EMS), but connects directly to WebSphere Application Server or WebSphere Liberty with SSL.

For example, the default installation of WebSphere Liberty 18.0.0.1 with one of the following configurations is affected:

  • HAProxy 1.5.8/OpenSSL 1.0.2: HAProxy is configured as SSL termination and connects to backend WebSphere Liberty servers using SSL only
  • A legacy web server with underlying SSL libraries or SSL modules that are not EMS-compatible (depending on the SSL configuration with backend WebSphere Liberty servers)

Symptoms

You might see these symptoms after a CLM 6.0.6 WebSphere Liberty upgrade or Java upgrade on any platform:
  • Slow page loading or timeouts
  • Significantly decreased server throughput
  • Increased server CPU utilization on the WebSphere Application Server or WebSphere Liberty server
  • When SSL tracing is enabled on the WebSphere Application Server or WebSphere Liberty server, excessive messages are shown such as "%% Initialized: [Session-, SSL_NULL_WITH_NULL_NULL]", "%% Negotiating: [Session-, ]"

Cause

A full handshake (which is CPU intensive) is required for each SSL/TLS connection between WebSphere Liberty and the proxy servers, when the new EMS security feature is enabled by default on the WebSphere Liberty server JVM, while the proxy server is not. For details, see the IBM APAR IJ05598 at https://www-01.ibm.com/support/docview.wss?uid=swg1IJ05598.

Solution

Option 1a - Add a WebSphere Liberty JVM argument

The simplest solution for WebSphere Liberty is to add a JVM argument to the server startup script to disable EMS. In start-jazz on the Jazz Authorization Server WebSphere Liberty server, you add the following argument to the existing ones:
export JVM_ARGS="... -Djdk.tls.useExtendedMasterSecret=false"

In the server.startup file on the remaining CLM WebSphere Liberty servers, you add the following argument:

JAVA_OPTS="$JAVA_OPTS -Djdk.tls.useExtendedMasterSecret=false"

Option 1b - Add a WebSphere Application Server JVM argument

The simplest solution for WebSphere Application Server is to add a JVM argument to the server's generic JVM arguments. Go to Application servers > server1 > Process definition > Java Virtual Machine and add the following argument:
Add "-Djdk.tls.useExtendedMasterSecret=false" to the Generic JVM Arguments

Option 2 - Upgrade the proxy

For WebSphere Application Server or WebSphere Liberty, you might choose to leave the jdk.tls.useExtendedMasterSecret=true setting (the default) and ensure that your front-end proxy or HTTP server is up to date with the newest SSL libraries and Java instead. For the WebSphere IHS or proxy server, you must upgrade to the newest 8.x or 9.x version that matches your WebSphere Application Server, and upgrade your Java JDK on both your IHS or proxy server and WebSphere Application Server. For other solutions, such as HAProxy, you must download and install the newest version of OpenSSL, or wait for an updated HAProxy for your Linux distribution. Other proxy solutions also require updates to their core product or underlining SSL libraries.

Diagnosis

Option 1 - Support check

To demonstrate the change in behavior without enabling Java SSL debugging, you can run the OpenSSL s_client with the -reconnect option, using a version of OpenSSL that does not support the Extended Master Secret extension. For example, install an older version of OpenSSL such as 1.0.2k-fips from 26 January 2017.

$ openssl version
!OpenSSL 1.0.2k-fips  26 Jan 2017

# Against the old Java, or a new Java with -Djdk.tls.useExtendedMasterSecret=false, you can reuse the session ID to resume the session.
$ openssl s_client -reconnect -connect jontestvm.rtp.raleigh.ibm.com:9643 < /dev/null 2>&1 | grep 'Cipher is'
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384

# Against a new Java that supports the Extended Master Secret extension, the server rejects the client's attempt to resume using the session ID, which forces a full handshake each time.
$ openssl s_client -reconnect -connect jontestvm.rtp.raleigh.ibm.com:9644 < /dev/null 2>&1 | grep 'Cipher is'
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384

Option 2 - Debug check

When SSL tracing or SSL debugging is enabled, in every ClientHello initiated by a proxy server, an attribute called "Extension extended_master_secret" is not present, followed by messages that indicate new key generation and negotiation start and complete before ServerHello. To enable SSL debugging, you can set this JVM argument: -Djavax.net.debug=ssl. Start the server and observe the log.

If excessive handshaking occurs, you will see repetitive messages like the following one and no "Extension extended_master_secret" notification:

*** ClientHello, TLSv1.2
...
***
%% Initialized:  [Session-10387, SSL_NULL_WITH_NULL_NULL]
ssl: ServerHandshaker.setupPrivateKeyAndChain RSA
matching alias: default
ssl: ServerHandshaker.setupPrivateKeyAndChain, chooseEngineServerAlias default
ssl: ServerHandshaker.setupPrivateKeyAndChain, return true
JsseJCE:  Using KeyPairGenerator EC from provider TBD via init
JsseJCE:  Using SecureRandom SHA2DRBG from provider IBMJCE version 1.8
JsseJCE:  Using KeyPairGenerator EC from provider TBD via init
ECDHCrypt:  ECDH KeyPairGenerator  from provider from init IBMJCE version 1.8
%% Negotiating:  [Session-10387, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
JsseJCE:  Using MessageDigest SHA-256 from provider IBMJCE version 1.8
*** ServerHello, TLSv1.2

If the configuration is correct with the newer JDK, after the first full handshake, you will see the "Extension extended_master_secret" notification:

*** ClientHello, TLSv1.2
...
Compression Methods:  {
0
}
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA256withDSA, SHA1withDSA
Extension extended_master_secret
Extension server_name, server_name: [type=host_name (0), value=v-6c26c0cb-ihs.rtp.raleigh.ibm.com]
***
qm: AsynchronousTaskRunner-3 @@ 09:35, WRITE: TLSv1.2 Handshake, length = 260
qm: AsynchronousTaskRunner-3 @@ 09:35, READ: TLSv1.2 Handshake, length = 91
*** ServerHello, TLSv1.2
RandomCookie:
...

Note: If EMS is disabled, the extension is not shown regardless of the SSL configuration.

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r12 | r7 < r6 < r5 < r4 | More topic actions...
 
This site is powered by the TWiki collaboration platformCopyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.