Start of changes for service refresh 6 fix pack 25

Transport Layer Security (TLS) Renegotiation Issue

A weakness exists in some implementations of Transport Layer Security (TLS) handshake negotiation. IBM addressed this vulnerability in previous releases of the IBM® SDK. In service refresh 6, fix pack 20, the solution changed to match the reference implementation.

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. See CVE-2009-3555 for details of the vulnerability. To address this vulnerability, the IETF published RFC 5746 Transport Layer Security (TLS) - Renegotiation Indication Extension. RFC 5746 defines a mechanism to implement TLS/SSL handshake renegotiation securely. Use of RFC 5746 replaced the industry-wide interim solution of disabling all renegotiation that is implemented after the weakness was discovered.

Interoperability modes

IBM JSSE2 re-enables 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. IBM JSSE2 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.

IBM JSSE2 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:

Strict mode: Requires both client and server be upgraded to RFC 5746 and to send the proper RFC 5746 messages. If not, the initial (or subsequent) handshaking will fail and the connection will be terminated.
Interoperable mode (default): Use of the proper RFC 5746 messages is optional; however, legacy (original SSL/TLS specifications) renegotiations are disabled if the proper messages are not used. Initial legacy connections are still allowed, but legacy renegotiations are disabled. This is the best mix of security and interoperability, and is the default setting.
Insecure mode: Permits full legacy renegotiation. Most interoperable with legacy peers but vulnerable to the original MITM attack.

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.

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.

Table 1. Interoperability Information
Client	Server	Mode
Updated	Updated	Secure renegotiation in all modes.
Legacy ¹	Updated	Strict If clients do not send the proper RFC 5746 messages, then initial connections will immediately be terminated by the server (`SSLHandshakeException` or `handshake_failure`). InteroperableInitial connections from legacy clients are allowed (missing RFC 5746 messages), but renegotiations will not be allowed by the server. ²³ Insecure Connections and renegotiations with legacy clients are allowed, but are vulnerable to the original MITM attack.
Updated	Legacy ¹	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. ² ³ Insecure Connections and renegotiations with legacy servers are allowed, but are vulnerable to the original MITM attack.
Legacy ¹	Legacy ¹	Existing SSL/TLS behavior, vulnerable to the MITM attack.

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

² IBM JSSE2 interim implementations reject renegotiations unless specifically re-enabled. If renegotiations are re-enabled, 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.

³ In SSL/TLS, renegotiations can be initiated by either side. 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:

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 an SSLHandshakeException, and the connection will be closed (handshake_failure). The no_renegotiation alert is not defined in the SSLv3 specification.

The following system properties are used to set the mode:

com.ibm.jsse2.allowUnsafeRenegotiation controls whether legacy (unsafe) renegotiations are permitted.
com.ibm.jsse2.allowLegacyHelloMessages allows the peer to perform the handshake process without requiring the proper RFC 5746 messages.

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

Attention: Do not re-enable 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. 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:

Restructure the peer to not require renegotiation.

Renegotiations are typically used by web servers that initially allow for anonymous client browsing but later require SSL/TLS authenticated clients, or that may initially allow weak cipher suites but later need stronger ones. The alternative is to require client authentication or strong cipher suites during the initial negotiation. There are a couple of options for doing so:

If an application has a browse mode until a certain point is reached and a renegotiation is required, then you can restructure the server to eliminate the browse mode and require all initial connections be strong.
Break the server into two entities, with the browse mode occurring on one entity, and using a second entity for the more secure mode. When the renegotiation point is reached, transfer any relevant information between the servers.

Both of these options require a fair amount of work, but will not reopen the original security flaw.

Set renegotiation interoperability mode to "insecure" using the system properties.

See the information earlier in this topic for how to set the system properties.

Implementation Details

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

A pseudo-cipher suite called the Signaling Cipher Suite Value (SCSV), "TLS_EMPTY_RENEGOTIATION_INFO_SCSV"
A TLS extension called the Renegotiation Info (RI).

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, IBM JSSE2 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

Safe and unsafe server certificate change in SSL/TLS renegotiations

Two system properties are available to define whether unsafe server certificate change in an SSL/TLS renegotiation should be restricted:

com.ibm.jsse2.renegotiation.peer.cert.check=[OFF | ON]

Use this property to change the renegotiation ability of IBM JSSE2 to require the peer support that is specified in RFC 5746. This requirement is only practical after all the required communication partners have implemented RFC 5746.

Table 3. Behavior of com.ibm.jsse2.renegotiation.peer.cert.check
Value of com.ibm.jsse2.renegotiation.peer.cert.check	Result
`OFF` (default)	Stops the IBM JSSE2 client or IBM JSSE2 server performing an identify check against the certificate from the peer. The result is to allow the peer certificate to change during renegotiation.
`ON`	Causes the IBM JSSE2 client or IBM JSSE2 server to perform a comparison against the certificate from the peer. The reason is to ensure that the certificate does not change during renegotiation. The comparison is applicable to both secure and non-secure renegotiations.

jdk.tls.allowUnsafeServerCertChange=[false | true]

This property was added to address Oracle security fix 8037066. Use this property to allow unsafe server certificate change in renegotiation. However, the property takes effect only when com.ibm.jsse2.renegotiation.peer.cert.check is set to OFF. If com.ibm.jsse2.renegotiation.peer.cert.check is set to ON, the jdk.tls.allowUnsafeServerCertChange property is overridden and no certificate change is allowed in renegotiation.

Table 4. Behavior of jdk.tls.allowUnsafeServerCertChange
Value of jdk.tls.allowUnsafeServerCertChange	Result
`false` (default)	The server certificate change in renegotiation after a session-resumption abbreviated initialhandshake is restricted. The server certificate can be changed only to certificates that can represent the same identity.
`true`	If the system property is set to `true` explicitly, the restriction on server certificate change in renegotiation is disabled.

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

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

Two certificates can be considered to represent the same identity:

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

Attention: DO NOT set com.ibm.jsse2.renegotiation.peer.cert.check=OFF and jdk.tls.allowUnsafeServerCertChange=true unless it is really necessary, as this would re-establish the unsafe server certificate change vulnerability.

End of changes for service refresh 6 fix pack 25