Home > Products > Communication & Messaging Security > iSaSiLk > documentation > Secure Renegotiation

Secure Renegotiation

This document describes how to use the iSaSiLk library to perform secure renegotiation.

The SSL/TLS Renegotiation vulnerability

In November 2009 Marsh Ray and Martin Rex independently discovered a serious vulnerability in the SSL/TLS renegotiation protocol which does not provide any cryptographic binding of the renegotiation handshake to the corresponding TLS channel. An attacker may exploit this vulnerability and establish a regular TLS connection with a server, exchange some data with it, and then splice in a connection with an innocent client who starts a new handshake with the server. The server, however, interprets this initial handshake as renegotiation and thinks that any data received so far has come from the client (and not from the attacker).

There may be variants of the attack possible where an initial handshake of the server is interpreted as renegotiation handshake by the client.

As a countermeasure against this attack (and its possible derivatives) the IETF TLS working group has developed a new TLS extension, RenegotiationInfo (RFC 5746), to establish a cryptographic binding of the renegotiation handshake to the corresponding TLS channel. When successfully exchanging and verifying the RenegotiationInfo extension, client and server know whether they perform an initial or renegotiating handshake and if they actually renegotiate the cryptographic parameters of the corresponding TLS connection.

For further information see
http://extendedsubset.com/?p=8 ,
http://www.ietf.org/mail-archive/web/tls/current/msg03928.html , and
RFC 5746 .

The RenegotiationInfo extension

RFC 5746 defines the RenegotiationInfo extension as an opaque structure that may be empty (initial handshake) or (renegotiating handshake) may carry verification data for checking the cryptographic binding to the enclosing TLS connection:

struct {
     opaque renegotiated_connection<0..255>;
} RenegotiationInfo;

On the beginning of an initial handshake the client sends a ClientHello message containing a RenegotiationInfo extension with an empty renegotiated_connection field. The server, when parsing the ClientHello message, knows that the client is able to perform secure renegotiation (because the ClientHello message contains the RenegotiationInfo extension) and that the ClientHello message belongs to an initial handshake (because the renegotiated_connection field of the RenegotiationInfo extension is empty). The server now also includes an RenegotiationInfo extension with an empty renegotiated_connection field into its ServerHello message to let the client know that it also is able to perform secure renegotiation.

Later, when client or server decide to perform a renegotiation, they exchange ClientHello and ServerHello messages containing RenegotiationInfo extensions with a non-empty renegotiated_connection field that carries verification data from the Finished messages of the immediately previous handshake. Successfully verification of this data ensures that the renegotiation corresponds to the enclosing TLS connection and the handshake can be securely continued.
Otherwise, if the verification fails, the renegotiation handshake may be under attack and has to be aborted immediately by sending a fatal handshake failure alert.

A TLS handshake may be also aborted by any of the following reasons:

Initial handshake: The client sends a RenegotiationInfo extension with an
empty renegotiated_connection field, but the server does not respond
with a RenegotiationInfo extension. The client now knows that the server
does not support secure renegotiation and may prefer to abort the handshake
with a fatal handshake failure alert because it may be already under attack.
Initial handshake: If the client does not send a RenegotiationInfo extension, the
server knows that the client does not support secure renegotiation and may abort the
handshake with a fatal handshake failure alert or may continue it to later deny any
renegotiation request of the client by sending a no_renegotiation alert message.
Initial handshake or renegotiating handshake: Any incorrect usage of the
RenegotiationInfo extension (non-empty
renegotiated_connection field at an initial handshake, empty
renegotiated_connection field at a renegotiating handshake)
immediately causes a fatal handshake failure alert.
Renegotiating handshake: When both client and server have announced to be able
to support secure renegotiation (by exchanging RenegotiationInfo extensions
within the initial handshake), but any party does not send the
RenegotiationInfo extension within the renegotiating handshake, the
renegotiation has to be aborted with fatal handshake failure alert.

For interoperability with SSLv3- and TLS-Servers that do not support extensions yet, RFC 5746 provides an alternative way for the client to signal its ability to perform secure renegotiation. Instead of including an empty RenegotiationInfo extension into the ClientHello message of an initial handshake, the client may add the special signalling cipher suite value (SCSV) "TLS_EMPTY_RENEGOTIATION_INFO_SCSV" withID {0x00, 0xFF} to the list of its cipher suites. When parsing this special cipher suite value, the server knows that the client supports the RenegotiationInfo extension and safely can include it into its ServerHello message to tell the client that it is also able to perform secure renegotiation. The SCSV cipher suite has no other meaning or purpose than announcing the ability to perform secure renegotiation. It can only be sent within an initial handshake and is simply ignored by (and does not break) servers that do not support TLS extension.

iSaSiLk and the RenegotiationInfo extension

By default iSaSiLk uses the RenegotiationInfo extension as described above.
At the beginning of a handshake an iSaSiLk client announces its ability for secure
renegotiation by either sending an empty RenegotiationInfo extension or
including the special SCSV cipher suite value into its cipher suite list. The
RenegotiationInfo extension is only sent if the client application has
configured iSaSiLk to use any further extensions (like, for instance, ServerName ).
If the client application does not want to use extensions, iSaSiLk does not send the
RenegotiationInfo extension, but includes the SCSV cipher suite value.
This ensures that the server will not break if it does not support extensions.
However, if the server does not respond with a RenegotiationInfo extension,
the client cannot know if an attacker already has launched a renegotiation attack
and therefore iSaSiLk will abort the handshake immediately by sending a fatal
handshake failure alert to the server. In the same way, an iSaSiLk server by default
will immediately abort an initial handshake with a fatal handshake failure alert if
the ClientHello message neither contains the RenegotiationInfo
extension nor the SCSV cipher suite value.
Both, iSaSiLk clients and iSaSiLk servers will not continue an (initial or renegotiating)
handshake if they notice that the peer does not use the RenegotiationInfo extension
correctly (for instance non-empty extension at initial handshake, empty extension at
renegotiating handshake) or that the RenegotiationInfo extension of a renegotiating
handshake contains an invalid or wrong renegotiated_connection value. In all
these situations the handshake will be aborted immediately by sending a fatal handshake
failure alert.

All RenegotiationInfo extension and the SCSV cipher suite value handling is done
transparently to the user. iSaSiLk manages the RenegotiationInfo extension as
"hidden" extension. It must not be set by the application and cannot be
accessed by the application. All required secure renegotiation processing is done
automatically. You only will recognize something about it if you turn on and watch
the debug output or if you get an exception because the handshake fails because of
missing or incorrect use of the RenegotiationInfo extension.

A typical initial and renegotiation client-server handshake course may look like:

Client:

Starting handshake...
ssl_debug(1): Starting handshake (iSaSiLk 4.4)...
ssl_debug(1): Sending v3 client_hello message to localhost:443, requesting version 3.2...
ssl_debug(1): Received v3 server_hello handshake message.
ssl_debug(1): Server selected SSL version 3.2.
ssl_debug(1): Server created new session 4A:B7:09:06:F3:35:BA:5E...
ssl_debug(1): CipherSuite selected by server: SSL_RSA_WITH_3DES_EDE_CBC_SHA
ssl_debug(1): CompressionMethod selected by server: NULL
ssl_debug(1): TLS extensions sent by the server: renegotiation_info (65281)
ssl_debug(1): Server supports secure renegotiation.
ssl_debug(1): Received certificate handshake message with server certificate.
ssl_debug(1): Server sent a 1024 bit RSA certificate, chain has 3 elements.
ssl_debug(1): Received server_hello_done handshake message.
ssl_debug(1): Sending client_key_exchange handshake...
ssl_debug(1): Sending change_cipher_spec message...
ssl_debug(1): Sending finished message...
ssl_debug(1): Received change_cipher_spec message.
ssl_debug(1): Received finished message.
ssl_debug(1): Session added to session cache.
ssl_debug(1): Handshake completed, statistics:
ssl_debug(1): Read 2538 bytes in 3 records, wrote 254 bytes in 4 records.
ssl_debug(1): Acquiring locks for renegotiation...
ssl_debug(1): Starting renegotiation...
ssl_debug(1): Sending v3 client_hello message to localhost:443, requesting version 3.2...
ssl_debug(1): Sending extensions: renegotiation_info (65281)
ssl_debug(1): Received v3 server_hello handshake message.
ssl_debug(1): Server selected SSL version 3.2.
ssl_debug(1): Server created new session FD:15:DD:D5:11:1E:6A:B6...
ssl_debug(1): CipherSuite selected by server: SSL_RSA_WITH_3DES_EDE_CBC_SHA
ssl_debug(1): CompressionMethod selected by server: NULL
ssl_debug(1): TLS extensions sent by the server: renegotiation_info (65281)
ssl_debug(1): Received certificate handshake message with server certificate.
ssl_debug(1): Server sent a 1024 bit RSA certificate, chain has 3 elements.
ssl_debug(1): Received server_hello_done handshake message.
ssl_debug(1): Sending client_key_exchange handshake...
ssl_debug(1): Sending change_cipher_spec message...
ssl_debug(1): Sending finished message...
ssl_debug(1): Received change_cipher_spec message.
ssl_debug(1): Received finished message.
ssl_debug(1): Session added to session cache.
ssl_debug(1): Renegotiation completed, statistics:
ssl_debug(1): Read 2623 bytes in 3 records, wrote 372 bytes in 4 records.
ssl_debug(1): Shutting down SSL layer...
ssl_debug(1): Sending alert: Alert Warning: close notify
ssl_debug(1): Read 501 bytes in 1 records, 466 bytes net, 466 average.
ssl_debug(1): Wrote 53 bytes in 1 records, 18 bytes net, 18 average.
ssl_debug(1): Closing transport...

Server:

ssl_debug(1): Starting handshake (iSaSiLk 4.4)...
ssl_debug(1): Received v3 client_hello handshake message from localhost/127.0.0.1.
ssl_debug(1): Client supports secure renegotiation.
ssl_debug(1): Client requested SSL version 3.2, selecting version 3.2.
ssl_debug(1): Creating new session 4A:B7:09:06:F3:35:BA:5E...
ssl_debug(1): CipherSuites supported by the client:
ssl_debug(1): SSL_RSA_WITH_3DES_EDE_CBC_SHA
ssl_debug(1): SSL_RSA_WITH_IDEA_CBC_SHA
ssl_debug(1): SSL_RSA_WITH_RC4_128_SHA
ssl_debug(1): CompressionMethods supported by the client:
ssl_debug(1): NULL
ssl_debug(1): Sending server_hello handshake message.
ssl_debug(1): Selecting CipherSuite: SSL_RSA_WITH_3DES_EDE_CBC_SHA
ssl_debug(1): Selecting CompressionMethod: NULL
ssl_debug(1): Selecting extensions: renegotiation_info (65281)
ssl_debug(1): Sending certificate handshake message with 1024 bit RSA server certificate...
ssl_debug(1): Sending server_hello_done handshake message...
ssl_debug(1): Received client_key_exchange handshake message.
ssl_debug(1): Received change_cipher_spec message.
ssl_debug(1): Received finished message.
ssl_debug(1): Sending change_cipher_spec message...
ssl_debug(1): Sending finished message...
ssl_debug(1): Session added to session cache.
ssl_debug(1): Handshake completed, statistics:
ssl_debug(1): Read 254 bytes in 4 records, wrote 2538 bytes in 3 records.
ssl_debug(1): Acquiring locks for renegotiation...
ssl_debug(1): Starting renegotiation...
ssl_debug(1): Received v3 client_hello handshake message from localhost/127.0.0.1.
ssl_debug(1): Client requested SSL version 3.2, selecting version 3.2.
ssl_debug(1): Creating new session FD:15:DD:D5:11:1E:6A:B6...
ssl_debug(1): CipherSuites supported by the client:
ssl_debug(1): SSL_RSA_WITH_3DES_EDE_CBC_SHA
ssl_debug(1): SSL_RSA_WITH_IDEA_CBC_SHA
ssl_debug(1): SSL_RSA_WITH_RC4_128_SHA
ssl_debug(1): CompressionMethods supported by the client:
ssl_debug(1): NULL
ssl_debug(1): TLS extensions sent by the client: renegotiation_info (65281)
ssl_debug(1): Sending server_hello handshake message.
ssl_debug(1): Selecting CipherSuite: SSL_RSA_WITH_3DES_EDE_CBC_SHA
ssl_debug(1): Selecting CompressionMethod: NULL
ssl_debug(1): Selecting extensions: renegotiation_info (65281)
ssl_debug(1): Sending certificate handshake message with 1024 bit RSA server certificate...
ssl_debug(1): Sending server_hello_done handshake message...
ssl_debug(1): Received client_key_exchange handshake message.
ssl_debug(1): Received change_cipher_spec message.
ssl_debug(1): Received finished message.
ssl_debug(1): Sending change_cipher_spec message...
ssl_debug(1): Sending finished message...
ssl_debug(1): Session added to session cache.
ssl_debug(1): Renegotiation completed, statistics:
ssl_debug(1): Read 372 bytes in 4 records, wrote 2623 bytes in 3 records.
ssl_debug(1): Shutting down SSL layer...
ssl_debug(1): Sending alert: Alert Warning: close notify
ssl_debug(1): Read 53 bytes in 1 records, 18 bytes net, 18 average.
ssl_debug(1): Wrote 501 bytes in 1 records, 466 bytes net, 466 average.
ssl_debug(1): Closing transport...

Configuration Options

As discussed above, a TLS client – for being sure to be not vulnerable to renegotiation
attacks – has to abort a handshake with a fatal handshake failure alert if a server does
not send the RenegotiationInfo extension within its initial ServerHello
message. In the same way, a TLS server has to abort an initial handshake with a fatal handshake
failure alert if the ClientHello message neither contains the RenegotiationInfo
extension nor the SCSV cipher suite value.

This means that by default no SSL/TLS communication is possible if the peer does not support secure
renegotiation. Although this is the recommended behaviour from the security point of view, it might
cause interoperability problems with servers/clients that do not support the RenegotiationInfo
extension yet.
Since deployment of patched TLS implementations cannot start before the final release of
RFC 5746, it will take a certain transition period until the majority of available TLS
applications will be able to understand the secure renegotiation protocol. Especially
during this transmission period there may be a certain (for instance, economic) requirement
for being still able to talk with unpatched TLS client or servers.

This section describes the configuration options allowing an application to control the
renegotiation handling of the iSaSiLk library. Each option can be dynamically set (or unset)
by calling a particular method of the SSLContext class, or can be statically
configured by editing a SSLContext.properties file and packing it with
iaik_ssl.jar file (or putting it elsewhere in the classpath).
Any static configuration via SSLContext.properties file is globally valid for the
entire application scope. Dynamical configuration settings are only valid for the particular
SSLContext to which they have been applied.
The SSLContext.properties file has to be located in the package iaik.security.ssl .
A sample property and iSaSiLk jar file allowing to communicate with unpatched TLS applications is
contained in the lib/legacy-renegotiation folder of your iSaSiLk distribution.

Allow legacy renegotiation : An iSaSiLk client or server that allows legacy
renegotiation will be able to talk (and renegotiate) with unpatched TLS applications
that do not support the RenegotiationInfo extension yet. Please note that
your application may be vulnerable to renegotiation attacks if you allow legacy
renegotiation without using the RenegotiationInfo extension to
cryptographically bind the renegotiation handshake to the enclosing SSL/TLS connection.

Configuration via SSLContext method:
sslContext.setAllowLegacyRenegotiation(true);
Configuration via SSLContext.properties file:
allowLegacyRenegotiation=true
Default value: false
Use of no_renegotiation warnings : A no_renegotiation
warning maybe sent if a renegotiation request ( ClientHello message from the client;

HelloRequest message from the server, respectively) from the peer is refused by
the local TLS server/client. The local TLS server/client does not abort the current TLS session,
it only tells the peer that it will not go into a renegotiation handshake. It then is the
decision of the peer if it wants to continue the current session or if it prefers to close
the session because the renegotiation request has been refused.

By default iSaSiLk does not use no_renegotiation warnings. Rather the handshake is
aborted by sending a fatal handshake failure alert if it gets a renegotiation request
you cannot be fulfilled. You may configure your SSLContext to not send a fatal
handshake failure alert, but continue and send a no_renegotiation warning in response
to an unsupported renegotiation request. In this case an iSaSiLk server will
not abort an initial handshake if it receives a ClientHello that
does not contain the SCSV cipher suite value or RenegotiationInfo
extension. It will continue and then send a no_renegotiation warning if
it receives a renegotiating ClientHello . Please note that this behaviour may
make your server vulnerable to attacks where only the client notices that a renegotiation
takes place.

Note also, that no_renegotiation warnings are only
defined for TLS, not for SSLv3; SSLv3 in any case will abort the handshake
with a fatal handshake failure alert when refusing a renegotiation request of the
peer.

Configuration via SSLContext method:
sslContext.setUseNoRenegotiationWarnings(true) ;
Configuration via SSLContext.properties file:
useNoRenegotiationWarnings=true
Default value: false
Allow identity change during renegotiation : If identity change is allowed an already
authenticated peer may change its certificate, psk identity or ServerName extension
during renegotiation. If peer identity change is not allowed, a renegotiation handshake will
be aborted with a fatal handshake failure alert if the peer tries to authenticate with a
different certificate or psk identiy, or tries to use a different ServerName extension
than used for the preceding session.

Configuration via SSLContext method:
sslContext.setAllowIdentityChangeDuringRenegotiation(false);
Configuration via SSLContext.properties file:
allowIdentityChangeDuringRenegotiation=false
Default value: true
Disable renegotiation : Use this flag if you want to disable renegotiation at all.
However, note that disabling renegotiation only might provide a conditional
protection against renegotiation attacks. Without using the

RenegotiationInfo extension, your initial (attacked) handshake may look
like a renegotiation handshake for the peer. Disabling renegotiation would only help
you if you are aware about the renegotiation.

Configuration via SSLContext method:
sslContext.setDisableRenegotiation(true);
Configuration via SSLContext.properties file:
disableRenegotiation=true
Default value: false

SecurityProvider

A more finely granulated configuration option is provided by the iSaSiLk SecurityProvider
method continueIfPeerDoesNotSupportSecureRenegotiation . iSaSiLk calls this
method during an (initial or renegotiation) handshake to check if legacy renegotiation
is allowed or not when the peer does not support secure renegotiation according to RFC 5746.

By default this method will check the SSLContext configuration (as described
above) and throw an SSLException if legacy renegotiation is not allowed. This means
that -- if the default configuration is used -- at the client side an intial handshake
with a server that does not send the RenegotiationInfo extension will be aborted
immediately with a fatal handshake failure alert. On the server side
an initial handshake will also be aborted immediately if the client
does not send the RenegotiationInfo extension or SCSV cipher
suite value.

You may override the SecurityProvider method continueIfPeerDoesNotSupportSecureRenegotiation
if you do not want to use the default behaviour/configuration or, for instance, want to
decide on case-by-case basis whether to continue or not. For instance, a client application may pop-up a warning dialag to inform the user that the server has not send the RenegotiationInfo
extension (may be only appropriate for expierenced users), or may maintain a
white list with server names for which legacy renegotiation is allowed, e.g.:


/**
 * Simple demo SecurityProvider implementation for a client} 
 * that generally enforces secure renegotiation according 
 * RFC 5746 but allows legacy renegotiation with some 
 * specific, explcitily listed sites. 
 */
public class RISecurityProvider extends IaikProvider {
  
  /**
   * Repository of sites to which legacy renegotiation 
   * shall be allowed.
   */
  Hashtable legacyRenegotiationSites_;

  /**
   * Default constructor.
   */
  public RISecurityProvider() {
    super();
    legacyRenegotiationSites_ = new Hashtable();
  }
  
  /**
   * Adds a site (server) name with which legacy 
   * renegotiation shall be allowed.
   * 
   * @param severName the site (server) name
   */
  public void addSite(String serverName) {
    if (serverName != null) {
      legacyRenegotiationSites_.put(serverName, serverName);
    }
  }
  
    
  /**
   * Removes a site (server) name with which legacy 
   * renegotiation shall be not allowed.
   * 
   * @param severName the site (server) name
   */
  public void removeSite(String serverName) {
    if (serverName != null) {
      legacyRenegotiationSites_.remove(serverName);
    }
  }
  
  /**
   * Throws a SSLException if a server that does not support 
   * secure renegotiation (or tries a legacy renegotiation), 
   * but the server name is not contained in the list of sites 
   * with which legacy renegotiation is allowed.
   *  
   * 
   * @param transport the SSLTransport to maybe used for getting 
   *                  information about the remote peer
   * @param renegotiation whether this method is called during an 
   *                      initial or during a renegotiation handshake                  
   *                  
   * @exception SSLException if a server that does not support secure 
   *                         renegotiation (or tries a legacy renegotiation), 
   *                         but is not contained in the list of sites with 
   *                         which legacy renegotiation is allowed
   */
  public void continueIfPeerDoesNotSupportSecureRenegotiation(SSLTransport transport,
                                                              boolean renegotiation) 
    throws SSLException {
    
    String serverName = transport.getRemotePeerName();
    if ((serverName != null) && (legacyRenegotiationSites_.get(serverName) != null)) {
      transport.debug("Server " + serverName + " did not send RenegotiationInfo extension. Continue anyway.");
    } else {
      throw new SSLException("Server did not send RenegotiationInfo extension.");
    } 
    
  }
}

For a more detailed description of the several configuraton options see the Javadoc
documentation of the SSLContext class.
Please note that full protection can only be achieved when not allowing any
communication with clients/servers that do not support the RenegotiationInfo
extension. For that reason the default configuration of iSaSiLk does not allow
to communicate with unpatched peers that are not able to perform secure renegotiation.