r8 - 2018-05-15 - 22:24:47 - SkyeBischoffYou 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 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.18/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.

6.0.6 Liberty Default

For 6.0.6 the CLM packaged Liberty install will set Extended Master Secret to disabled by default. We decided disabling EMS is the best initial option for users migrating to the new Liberty version or Java versions. This allows users to migrate to the new installations without issues, and gives Administrators time to decide on the best security options for their application server and connected proxy/http server. If you desire to enable EMS in your Liberty environment you should read Solution 2 below on how to properly enable EMS.

Solution 1 - Disable EMS

The simplest way to avoid EMS performance or compatibility problems is to disable EMS. For many environments this is an acceptable solution and avoids complex compatibility problems the new EMS setting can cause between the application server and different proxies. Likewise you may want to disable EMS temporarily while your admin and security team determine the correct proxy/http server upgrades required to fully support EMS.

Disabling EMS on Websphere Liberty

To disable EMS in WebSphere Liberty you can add the following JVM argument to the server startup script. 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"

Disabling EMS on WebSphere Application Server

To disable EMS in WebSphere Application Server you can add the following 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

Solution 2 - Enable EMS and Upgrade the proxy

For WebSphere Liberty or WebSphere Application Server, 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 latest SSL libraries and Java instead. For the WebSphere IHS or proxy server, you must upgrade to the latest 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 latest 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. After upgrading your proxy/http server you should also check your application server JVM arguments and ensure useExtendedMasterSecret is enabled as highlighted below. Note if useExtendedMasterSecret is not present in your configurations it will default to enabled.

Enabling EMS on Websphere Liberty

To enable EMS in WebSphere Liberty you can add the following JVM argument to the server startup script. 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=true"

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

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

Enabling EMS on WebSphere Application Server

To enable EMS in WebSphere Application Server you can add the following 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=true" to the Generic JVM Arguments

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: r8 < r7 < r6 < r5 < r4 | More topic actions
 
This site is powered by the TWiki collaboration platformCopyright © by the 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.
Ideas, requests, problems regarding the Deployment wiki? Create a new task in the RTC Deployment wiki project