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 = <whatever ciphers you have listed> to be ssl_server_cipher = !SSLv2 : <whatever 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 = <whatever ciphers you have listed> to be ssl_server_cipher = !SSLv2 : <whatever 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.