and a good review is available at:
Educated Guesswork - Understanding the TLS Renegotiation Attack
Applications attempting to initiate renegotiation (via
SSLEngine.beginHandshake()) will receive a
SSLHandshakeException (IOException) and the connection will be shutdown.
Applications that receive a renegotiation request from the peer will respond according to the type of connection in place:
TLSv1: A warning Alert message of type "no_renegotiation(100)" will be sent to the peer and the connection will remain open.
SSLv3: The application will receive a
SSLHandshakeException, and the connection will be closed. ("no_renegotiation" is not defined in the SSLv3 spec.)
sun.security.ssl.allowUnsafeRenegotiationto true before the JSSE library is initialized. There are several ways to set this property:
% java -Dsun.security.ssl.allowUnsafeRenegotiation=true Main
Note that TLS/SSL renegotiation will not occur unless both client and server have enabled renegotiations.
WARNING: It is risky to re-enable TLS/SSL renegotiation, as the vulnerability is once again present.
SSLSession.invalidate()), then call
SSLEngine.setEnableSessionCreation(false). This approach still allows renegotiations to occur, but since only existing valid sessions can be resumed, there are no valid sessions to resume, and new sessions can't be created, renegotiations will necessarily fail.
A side effect of this approach is that sessions can't be resumed on later connections, thus each new connection must do a complete handshake from scratch. That is, abbreviated handshakes on later connections are not possible.
For information on how the TLS Renegotiation issue has been resolved, please see TLS Renegotiation Issue README.