Transport Layer Security (TLS) Renegotiation Issue Readme

1. A security vulnerability in all versions of the Transport Layer Security (TLS) protocol (including the older Secure Socket Layer (SSLv3)) can allow Man-In-The-Middle (MITM) type attacks where chosen plain text is injected as a prefix to a TLS connection. This vulnerability does not allow an attacker to decrypt or modify the intercepted network communication once the client and server have successfully negotiated a session between themselves. This vulnerability has been disclosed at:

   Extended Subset - Authentication Gap in TLS Renegotiation
   Common Vulnerabilities and Exposures

   and a good review is available at:
   Educated Guesswork - Understanding the TLS Renegotiation Attack

2. This release includes an interim fix that disables TLS/SSL renegotiation in the Java Secure Sockets Extension (JSSE) by default. This issue primarily affects the server side of a connection, so this fix should be deployed on the server side, but can also be deployed to the client side if so desired.
3. Applications that require TLS/SSL renegotiation will be impacted. (For example, web servers that initially allow for anonymous client browsing, but later require TLS/SSL authenticated clients on the same connection.) With this fix, applications will not be able to initiate TLS/SSL renegotiation, and will reject all peer-initiated TLS/SSL renegotiation requests.

   Applications attempting to initiate renegotiation (via SSLSocket.startHandshake() or 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.)

4. Renegotiations can be re-enabled for those applications that need it by setting the new system property sun.security.ssl.allowUnsafeRenegotiation to true before the JSSE library is initialized. There are several ways to set this property:
   1. Command Line:

      % java -Dsun.security.ssl.allowUnsafeRenegotiation=true Main

   2. Java Control Panel (Java Plug-in / Java Web Start) - Runtime Environment.
   3. Within the application:

      java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", true);
      

   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.

5. The IETF has recently issued RFC 5746 to address this problem. Oracle will update this interim fix with the industry-approved fix in the next Java SE and Java for Business security updates.
6. If one chooses to disable this interim fix but still wishes to "disable" renegotiations, one can invalidate current sessions ( SSLSession.invalidate()), then call SSLSocket.setEnableSessionCreation(false) or 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.