Switch from sslv3 to tls for outbound transactions

, ,
1

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:

  1. watt.security.ssl.client.ignoreEmptyAuthoritiesList=true is already set.

  2. 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.

  3. enttoollkit.jar file is already present in the servers.

  4. 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

2

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

3

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

4

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

5

@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

6

OK hopefully SAG will help you from here…

Please keep the thread posted.

HTH,
RMG

7

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

8

Thanks Kunal for your valuable point.

Thanks,

9

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

10

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

11

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