Enabling SSL/TLS Renegotiation in Java

All the crazy SSL servers seem to come my way - ones that only support weird combinations of protocols and ciphers, ones that require client certificates stored on PKCS#11 hardware, and ones that require SSL renegotiation.

Turns out that Sun has recently disabled SSL/TLS renegotiation in Java by default as a workaround for SSL/TLS renegotiation vulnerability. This becomes a problem when trying to test an HTTPS server that actually requires renegotiation. Burp suite reacts to it with an error message saying "javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message" or, if I enable only TLSv1, with a message saying "javax.net.ssl.SSLHandshakeException: renegotiation is not allowed". I expect that other Java-based proxies, such as WebScarab behave in a similar way.

Fortunately, renegotiation can be explicitly enabled by setting the Java system property system property sun.security.ssl.allowUnsafeRenegotiation to true. For example, to run Burp suite we can do :

java -Dsun.security.ssl.allowUnsafeRenegotiation=true -jar burpsuite_pro_v1.3.04.jar


According to Transport Layer Security (TLS) Renegotiation Issue Readme, TLS renegotiation behaviour was changed in the following releases:

JDK and JRE 6 Update 22
JDK and JRE 5.0 Update 26
SDK and JRE 1.4.2 Update 28

It should be noted that if in 2014 you still need to allow unsafe renegotiations in your TLS sessions, you need to seek professional help on how to make your application to be RFC 5746 compliant.

Enabling unsafe renegotiations is a patently dangerous risk, that flies in the face of many industry and vendor best practices with regards to TLS security.