|Issue||Remedy the SSLv3 and TLS renegotaion vulnerability CVE 2009-3555.|
|Resolution||Upgrade to SSL-J 5.1.1. |
This release of SSL-J includes the addition of three new security properties associated with changes to address the SSLv3 and TLS renegotiation vulnerability
? com.rsa.ssl.server.compatibility.securerenegotiation (default: enabled)
When enabled, renegotiation is possible only with clients which have been
updated to address the SSLv3 and TLS renegotiation vulnerability.
? com.rsa.ssl.client.compatibility.securerenegotiation.requireupdatedpeer (default: disabled)
? com.rsa.ssl.server.compatibility.securerenegotiation.requireupdatedpeer (default: disabled)
The requireupdatedpeer properties control whether the initial handshake
should be aborted if the peer has not been updated to address the SSLv3 and TLS
renegotiation vulnerability. These default to disabled as interoperability problems
would otherwise result.
What will happen when a non-mitigated application attempts to communicate with an application that has the renegotiation vulnerability remediation fix applied to it (that is, an unfixed application attempting to communicate with a fixed application)?
It depends how the patched server has been configured. (See security properties explained above.)
Given the above description, by default, unpatched clients can connect to patched servers, and visa versa, but not renegotiate the TLS connection. Renegotiation is allowed if both sides of the connection are patched.
|Legacy Article ID||a50424|