In late 2014, we published Security Bulletin: Vulnerability in SSLv3 affects IBM WebSphere Application Server (CVE-2014-3566). As detailed in the bulletin, the IBM WebSphere Application Server could allow a remote attacker to obtain sensitive information, caused by a design error when using the SSLv3 protocol. A remote user with the ability to conduct a man-in-the-middle attack could exploit this vulnerability via a POODLE (Padding Oracle On Downgraded Legacy Encryption) attack to decrypt SSL sessions and access the plaintext of encrypted connections. The intention of this blog entry is to share additional information on common WebSphere Application Server questions and issues related to the fixes and/or workarounds associated with CVE-2014-3566.
The solution implemented for WebSphere Application Server was to disable the SSLv3 protocol and default to the TLSv1 protocol.
This behavior was introduced in the following Fix Packs:
For WebSphere Administrators, it is important to understand and be aware that once this fix level is applied, the SSLv3 protocol will be disabled. This means that any connections made to or from the WebSphere Application Server will no longer support SSLv3 communication requests.
After applying the WebSphere Fix Level, a common issue that causes concern is when the following message is observed in the logs:
javax.net.ssl.SSLHandshakeException: Client requested protocol SSLv3 not enabled or not supported
This typically indicates that a client(s)/server(s) is attempting to initiate communication using SSLv3. After applying the above referenced WebSphere Application Server fix, if you experience handshake errors or connection failures with other applications you will need to ensure they are configured to use TLS and have the appropriate application provided fix in place.
title image (modified) credit: (cc) Some rights reserved by OpenClips