Potential security vulnerability if using EMS with SSL

Potential security vulnerability if using EMS with SSL

book

Article ID: KB0108162

calendar_today

Updated On:

Products Versions
TIBCO Enterprise Message Service -
Not Applicable -

Description

Description:
TIBCO is aware of a potential security vulnerability in the OpenSSL library we utilize in EMS. The potential exploit is low risk but we are working on an interim workaround for you in addition to integrating the patch which became available from the OpenSSL organization today (10/12/2005) into our builds.

Basicly the exploit involves a man in the middle attacker first causing the TLS and SSLV3 handshakes to fail and cause the server and client to fall
back to SSLV2 where there are known vulnerabilities.

On an internal trustworthy network there is probably very little reason to be concerned. On untrusted networks, you can remove the +SSLv2 assertion in the default server SSL configuration file.
    In the file tibemsd.conf change the line
        ssl_server_ciphers = &ltwhatever ciphers you have listed>
    to be
        ssl_server_cipher = !SSLv2 : &ltwhatever cyphers you have listed>
You should also disable SSLv2 in factories.conf of tibemsdssl.conf if you are using these files to determine what ciphers to use.

Alternatively, you can list only TLS ciphers in the java client SSL configuration files. This way if the TLS handshake failed it would not fail over to the SSLv2 alternate because the clients would not support it.

Issue/Introduction

Potential security vulnerability if using EMS with SSL

Environment

Product: TIBCO Enterprise Message Service Version: OS: --------------------

Resolution

TIBCO is aware of a potential security vulnerability in the OpenSSL library we utilize in EMS. The potential exploit is low risk but we are working on an interim workaround for you in addition to integrating the patch which became available from the OpenSSL organization today (10/12/2005) into our builds.

Basicly the exploit involves a man in the middle attacker first causing the TLS and SSLV3 handshakes to fail and cause the server and client to fall
back to SSLV2 where there are known vulnerabilities.

On an internal trustworthy network there is probably very little reason to be concerned. On untrusted networks, you can remove the +SSLv2 assertion in the default server SSL configuration file.
    In the file tibemsd.conf change the line
        ssl_server_ciphers = &ltwhatever ciphers you have listed>
    to be
        ssl_server_cipher = !SSLv2 : &ltwhatever cyphers you have listed>
You should also disable SSLv2 in factories.conf of tibemsdssl.conf if you are using these files to determine what ciphers to use.

Alternatively, you can list only TLS ciphers in the java client SSL configuration files. This way if the TLS handshake failed it would not fail over to the SSLv2 alternate because the clients would not support it.