Switch from sslv3 to tls for outbound transactions

Kunal_Dey1 · November 19, 2014, 8:57am

Hi

We are using webMethods 7.1.3 version at patch IS_7.1.3_Core_Fix12 on OS Windows Server 2008 R2 in production environment.
One of our partners has disabled SSLV3 because of the poodle bug. So they have asked us to switch from SSLV3 to TLS for sending outbound messages. Presently we are using HTTPS for sending outbound messages to that partner.

Error description:
iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: handshake failure

We have already tried the following:

watt.security.ssl.client.ignoreEmptyAuthoritiesList=true is already set.
watt.net.ssl.client.handshake.maxVersion=tls
watt.net.ssl.client.handshake.minVersion=sslv2

watt.net.ssl.client.handshake.maxVersion=tls
watt.net.ssl.client.handshake.minVersion=tls
Both these settings have already been tried and they are giving the same error.
enttoollkit.jar file is already present in the servers.
watt.ssl.iaik.clientAllowUnboundRenegotiate=false
watt.ssl.iaik.serverAllowUnboundRenegotiate=false
These settings are still false

Following are the ssl debug logs for different levels of handshake version:

SSL Debug logs when watt.net.ssl.client.handshake.minVersion=sslv2

ssl_debug(2): Starting handshake (iSaSiLk 3.03)…
ssl_debug(2): Sending secure renegotiation cipher suite
ssl_debug(2): Sending v2 client_hello message, requesting version 3.1…
ssl_debug(2): Received alert message: Alert Fatal: handshake failure
ssl_debug(2): SSLException while handshaking: Peer sent alert: Alert Fatal: hand
shake failure
ssl_debug(2): Shutting down SSL layer…

SSL Debug los when watt.net.ssl.client.handshake.minVersion=tls

ssl_debug(1): Starting handshake (iSaSiLk 3.03)…
ssl_debug(2): Starting handshake (iSaSiLk 3.03)…
ssl_debug(3): Starting handshake (iSaSiLk 3.03)…
ssl_debug(3): Sending secure renegotiation cipher suite
ssl_debug(2): Sending secure renegotiation cipher suite
ssl_debug(1): Sending secure renegotiation cipher suite
ssl_debug(3): Sending v3 client_hello message, requesting version 3.1…
ssl_debug(1): Sending v3 client_hello message, requesting version 3.1…
ssl_debug(2): Sending v3 client_hello message, requesting version 3.1…
ssl_debug(3): Received alert message: Alert Fatal: handshake failure
ssl_debug(1): Received alert message: Alert Fatal: handshake failure
ssl_debug(2): Received alert message: Alert Fatal: handshake failure
ssl_debug(3): SSLException while handshaking: Peer sent alert: Alert Fatal: hand
shake failure
ssl_debug(1): SSLException while handshaking: Peer sent alert: Alert Fatal: hand
shake failure
ssl_debug(2): SSLException while handshaking: Peer sent alert: Alert Fatal: hand
shake failure
ssl_debug(3): Shutting down SSL layer…
ssl_debug(1): Shutting down SSL layer…
ssl_debug(2): Shutting down SSL layer…

The customer has already confirmed that there are no changes in certificates or IP/URLs.

Any information regarding this will be highly appreciated.

Thanks and Regards
Kunal Dey

rmg · November 19, 2014, 4:00pm

This is a known security issue.

Please open a ticket with SAG tech support and check if they support 7.13 in their scope for this poodle bug issue as they doing it for 8.x and 9.x TEST patch released.

HTH,
RMG

Tong_Wang · November 19, 2014, 5:29pm

The default cipher suite used by WM is very limited, especially lacking the ones for TLS. The failure you are seeing is because both system can’t find a common cipher, I believe.

You can check if 7.1.3 has this server extended setting:
watt.net.ssl.client.cipherSuiteList
(I use it successfully in 8.0.1 & later)
If yes, you can try to use this setting value:
watt.net.ssl.client.cipherSuiteList=TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA,SSL_RSA_EXPORT1024_WITH_RC4_56_SHA,SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5,TLS_RSA_WITH_RC4_128_SHA,TLS_DH_DSS_WITH_AES_128_CBC_SHA,TLS_DH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DH_anon_WITH_AES_128_CBC_SHA,TLS_DH_DSS_WITH_AES_256_CBC_SHA,TLS_DH_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DH_anon_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_IDEA_CBC_SHA,SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA,SSL_DH_DSS_WITH_DES_CBC_SHA,SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA,SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA,SSL_DH_RSA_WITH_DES_CBC_SHA,SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,SSL_DHE_DSS_WITH_DES_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,SSL_DHE_RSA_WITH_DES_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_WITH_RC4_128_MD5,SSL_DH_anon_WITH_DES_CBC_SHA,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_NULL_MD5,SSL_RSA_WITH_NULL_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV

rmg · November 19, 2014, 7:17pm

There is a recent patch released for 8.x and 9.x systems to enable TLS Inbound and I believe for outbound side TLS is always exists may be extended setting below should help for 7.x systems.

HTH,
RMG

Kunal_Dey1 · November 20, 2014, 8:15am

@RMG and Tong Wang: Thank You very much for the prompt replies.
@RMG: A ticket has already been raised with SAG and they are currently working on the issue.
@Tong Wang: I am afraid that the particular extended setting: watt.net.ssl.client.cipherSuiteList is not available for 7.1.3.
Please let me know in case you can think of anything else.

Regards
Kunal Dey

rmg · November 20, 2014, 8:56pm

OK hopefully SAG will help you from here…

Please keep the thread posted.

HTH,
RMG

Kunal_Dey1 · January 16, 2015, 9:58am

Hi All

The issue was resolved by setting the property(extended setting): watt.net.ssl.client.strongcipheronly=true.
This is not expected behavior as the description of this property states that when the value is “false”(default), the server will first try to establish a connection using strong cipher(128 or higher) and in case it can’t do so it will fall back to a weaker cipher(64, 56, or 40 bit). In case it is “true” it will only try to establish a connection using a strong cipher and if it fails it will disconnect rather than use a weak cipher. We are following up with SAG regd. the behavior of this particular property and I will update the thread once we receive a reply.
In any case thanks to everyone for all the useful help and suggestions. It is much appreciated.

Warm Regards
Kunal Dey

MR_as173d · January 16, 2015, 11:24am

Thanks Kunal for your valuable point.

Thanks,

Holger_von_Thomsen · January 16, 2015, 6:37pm

Please apply SCG_7.1.3_Entrust_Fix6 and IS_7.1.3_Core_Fix27 (avaliable via Update Manager).

These have been released to exactly address this poodle issue.

Check the related KB-Article on Empower for details.

Regards,
Holger

Anooja_G · January 30, 2015, 8:00pm

Hi All,

We have also received the same request to move from ssl to tls for one of our partners. We are using webMethods 7.1.1 version at patch IS_7.1.1_Core_Fix19. Is anyone aware if there are any fixes for this version to address the poodle issue?

I will open a ticket with SAG support also.

Regards
Anooja

Holger_von_Thomsen · February 5, 2015, 7:55pm

Hi Anooja,

I doubt that SAG will create any further Fixes for this issue for any other versions than those that already exists.

These are:
wM 7.1.3
wM 8.2.1
wM 8.2.2
wM 9.0.1
wM 9.5.1
wM 9.6.0
wM 9.7.0

You should consider updating to at least 7.1.3 as this is the minimum version required for a regular migration to 9.5.1.

Check for the following KB-Article in Empower Knowledgebase:
#1760581: webMethods Integration Server - POODLE Vulnerability for wM7.x, 8.x and 9.x IS, Broker and MWS

Also check the depending security advicory on Empower:
https://empower.softwareag.com/Products/Security/poodle.asp

Regards,
Holger