Documentation Contents

Transport Layer Security (TLS) Renegotiation Issue

In the fall of 2009, a flaw was discovered in the SSL/TLS protocols. A fix to the protocol was developed by the IETF TLS Working Group, and current versions of the JDK contain this fix. This section describes the situation in much more detail, along with interoperability issues when communicating with older implementations that do not contain this protocol fix.

The vulnerability allowed for man-in-the-middle (MITM) attacks where chosen plain text could be injected as a prefix to a TLS connection. This vulnerability did not allow an attacker to decrypt or modify the intercepted network communication once the client and server have successfully negotiated a session between themselves.

Additional information is available at CVE-2009-3555 (posted on Mitre's Common Vulnerabilities and Exposures List, 2009).

Phased Approach to Fixing This Issue

The fix for this issue was handled in two phases:


Note: Applications that do not require renegotiations are not affected by the Phase 2 default configuration. However applications that require renegotiations (for example, web servers that initially allow for anonymous client browsing, but later require SSL/TLS authenticated clients):


Description of the Phase 2 Fix

The SunJSSE implementation reenables renegotiations by default for connections to peers compliant with RFC 5746. That is, both the client and server must support RFC 5746 in order to securely renegotiate. SunJSSE provides some interoperability modes for connections with peers that have not been upgraded, but users are strongly encouraged to update both their client and server implementations as soon as possible.

With the Phase 2 fix, SunJSSE has three renegotiation interoperability modes. Each mode fully supports the RFC 5746 secure renegotiation, but has these added semantics when communicating with a peer that has not been upgraded:

The three mode distinctions only affect a connection with a peer that has not been upgraded. Ideally, strict (full RFC 5746) mode should be used for all clients and servers; however, it will take some time for all deployed SSL/TLS implementations to support RFC 5746, because the interoperable mode is the current default.

The following table contains interoperability information about the modes for various cases in which the client and/or server are either updated to support RFC 5746 or not.

Interoperability Information
Client Server Mode
Updated Updated

Secure renegotiation in all modes.

Legacy Footnote 1 Updated
Updated Legacy Footnote 1
  • Strict
    If the server does not respond with the proper RFC 5746 messages, then the client will immediately terminate the connection (SSLHandshakeException or handshake_failure).
  • Interoperable
    Initial connections from legacy servers are allowed (missing RFC 5746 messages), but renegotiations will not be allowed by the server. Footnote 2 Footnote 3
  • Insecure
    Connections and renegotiations with legacy servers are allowed, but are vulnerable to the original MITM attack.
Legacy Footnote 1 Legacy Footnote 1 Existing SSL/TLS behavior, vulnerable to the MITM attack.

Footnote 1 "Legacy" means the original SSL/TLS specifications (that is, not RFC 5746).

Footnote 2 SunJSSE Phase 1 implementations reject renegotiations unless specifically reenabled. If renegotiations are reenabled, then they will be treated as "Legacy" by the peer that is compliant with RFC 5746, because they do not send the proper RFC 5746 messages.

Footnote 3 In SSL/TLS, renegotiations can be initiated by either side. Like the Phase 1 fix, applications communicating with a peer that has not been upgraded in Interoperable mode and that attempt to initiate renegotiation (via SSLSocket.startHandshake() or SSLEngine.beginHandshake()) will receive an SSLHandshakeException (IOException) and the connection will be shut down (handshake_failure). Applications that receive a renegotiation request from a peer that has not been upgraded will respond according to the type of connection in place:

The following system properties are used to set the mode:

Values of the System Properties for Setting the Interoperability Mode
Mode allowLegacyHelloMessages allowUnsafeRenegotiation
Strict false false
Interoperable (default) true false
Insecure true true

Caution: Do not reenable the insecure SSL/TLS renegotiation, as this would reestablish the vulnerability.


For information about how to configure a specific mode by setting a system property, see How to Specify a java.lang.System Property.

Workarounds and Alternatives to SSL/TLS Renegotiation

All peers should be updated to RFC 5746-compliant implementation as soon as possible. Even with this RFC 5746 fix, communications with peers that have not been upgraded will be affected if a renegotiation is necessary. Here are a few suggested options:

Implementation Details

RFC 5746 defines two new data structures, which are mentioned here for advanced users:

Either of these can be used to signal that an implementation is RFC 5746-compliant and can perform secure renegotiations. For more relevant technical discussions, see the IETF email discussion from November 2009 to February 2010.

RFC 5746 enables clients to send either an SCSV or RI in the first ClientHello. For maximum interoperability, SunJSSE uses the SCSV by default, as a few TLS/SSL servers do not handle unknown extensions correctly. The presence of the SCSV in the enabled cipher suites (SSLSocket.setEnabledCipherSuites() or SSLEngine.setEnabledCipherSuites()) determines whether the SCSV is sent in the initial ClientHello, or if an RI should be sent instead.

SSLv2 does not support SSL/TLS extensions. If the SSLv2Hello protocol is enabled, then the SCSV is sent in the initial ClientHello.

Description of the Phase 1 fix

As previously mentioned, the Phase 1 Fix was to disable renegotiations by default until a fix compliant with RFC 5746 could be developed. Renegotiations could be reenabled by setting the sun.security.ssl.allowUnsafeRenegotiation system property. The Phase 2 fix uses the same sun.security.ssl.allowUnsafeRenegotiation system property, but also requires it to use RFC 5746 messages.

All applications should upgrade to the Phase 2 RFC 5746 fix as soon as possible.

Allow Unsafe Server Certificate Change in SSL/TLS renegotiations

Server certificate change in an SSL/TLS renegotiation may be unsafe:

  1. if endpoint identification is not enabled in an SSL/TLS handshaking; and
  2. if the previous handshake is a session-resumption abbreviated initial handshake; and
  3. if the identities represented by both certificates can be regarded as the same.

Two certificates can be considered to represent the same identity:

  1. If the subject alternative names of IP address are present in both certificates, they should be identical; otherwise,
  2. if the subject alternative names of DNS name are present in both certificates, they should be identical; otherwise,
  3. if the subject fields are present in both certificates, the certificate subjects and issuers should be identical.

Starting with JDK 8u25, unsafe server certificate change in SSL/TLS renegotiations is not allowed by default. The new system property jdk.tls.allowUnsafeServerCertChange, can be used to define whether unsafe server certificate change in an SSL/TLS renegotiation should be restricted or not.

The default value of this system property is "false".


Caution: DO NOT set the system property to "true" unless it is really necessary, as this would re-establish the unsafe server certificate change vulnerability.



Oracle and/or its affiliates Copyright © 1993, 2024, Oracle and/or its affiliates. All rights reserved.
Contact Us