Note: For information about signing up to receive security notice updates from F5, refer to SOL9970: Subscribing to email notifications regarding F5 products.

Note: Versions that are not listed in this Solution have not been evaluated for vulnerability to this security advisory. For information about the F5 security policy regarding evaluating older and unsupported versions of F5 products, refer to SOL4602: Overview of the F5 security vulnerability response policy.

F5 products and versions that have been evaluated for this Security Advisory

A Man in the Middle attack allows an attacker to inject an arbitrary amount of chosen plain text into the application protocol stream data during a secure session renegotiation that uses SSL version 3.x or TLS version 1.x. This may provide an attacker the ability to perform arbitrary actions on affected websites with user's credentials. This vulnerability does not allow one to decrypt the intercepted network communication.

Information about this advisory is available at the following locations:

Note: These links take you to a resource outside of AskF5, and it is possible that the documents may be removed without our knowledge.

• http://extendedsubset.com/?p=8
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555

Note: F5 thanks Marsh Ray, who originally identified and reported this vulnerability.

The IETF has adopted as RFC5746: Transport Layer Security (TLS) Renegotiation Indication Extension a new extension to the TLS standard that addresses this issue. F5 Product Development has implemented this new extension beginning in BIG-IP versions 10.2.3 and 11.0.0.

Important: When session renegotiation is disabled, some browsers may log an informational message that appears similar to the following example to the console when connecting to F5 products:

Server does not support RFC 5746, see CVE-2009-3555

Although the message implies that the F5 product to which the browser is connecting is vulnerable to this attack, all vulnerable F5 Products have been patched to disable SSL/TLS renegotiation, and some have been further enhanced to allow explicit control over renegotiation, thus mitigating this attack. For more information regarding completed and planned updates related to this vulnerability, refer to the following table. Note that ID 223836 specifically addresses this error message.

F5 Product Development is tracking this issue as follows:

If a named hotfix has been issued for your software version, you may download the referenced hotfix or later versions of the hotfix from the F5 Downloads site.

If an engineering hotfix has been issued for your software version, you should contact F5 Technical Support, referencing this Solution number and the associated CR number to request the hotfix.

For a list of the latest available hotfixes, refer to SOL9502: BIG-IP hotfix matrix.

For information about the F5 hotfix policy, refer to SOL4918: Overview of the F5 critical issue hotfix policy.

For information about how to manage F5 product hotfixes, refer to SOL6845: Managing F5 product hotfixes.

For information about installing version 10.x hotfixes, refer to SOL10025: Managing BIG-IP product hotfixes (10.x).

Mitigation steps for BIG-IP LTM, ASM, PSM, SAM, Link Controller, WebAccelerator, or WOM SSL virtual servers

You can use the Client SSL profile Renegotiation setting or an iRule to disable client-side session renegotiation for virtual servers. Refer to the following section that applies to your version:

Note: Applications that require session renegotiation are inherently vulnerable to the attack. Only removal of the renegotiation requirement in the application itself will eliminate the vulnerability. If session renegotiation is disabled by any of the vulnerability mitigation steps described below without modifying the application, client connections will be dropped. For example, IE 5.0 clients accessing applications which use SGC (Server Gated Cryptography) certificates are known to require renegotiation, and their connections would be disrupted by such a configuration.

Important: Any mitigation action that re-enables session re-negotiation on patched vulnerable versions may re-expose your F5 system to this vulnerability. In some cases, iRule logic can be used to control this behavior. Refer to the sections below for details regarding your product and version.

BIG-IP versions 10.1.0 through 10.2.x

To mitigate the vulnerability, verify that the default Client SSL profile Renegotiation setting has not been modified from the default value of Disabled, and that any non-default Client SSL profiles have the Renegotiation setting configured as Disabled.

The Renegotiation setting was added to the BIG-IP Client session and Server SSL profiles in version 10.1.0 as a result of ID 213308 (formerly CR132180). In versions that include this change, the Renegotiation setting is Disabled by default in the Client SSL profile. Virtual servers using a Client SSL profile with the Renegotiation setting set to Disabled are protected from this vulnerability.

If necessary, you can selectively enable renegotiation using the SSL::renegotiate iRules command on a virtual server which has renegotiation disabled in its Client SSL profile. For example, an iRule similar to the following enables renegotiation only for clients within a single Class C subnet:

when CLIENTSSL_HANDSHAKE priority 1 {
  if { [IP::addr [IP::client_addr] equals 192.168.222.0/24] }{
    SSL::renegotiate enable
  }
}

Note: For more information, refer to the DevCentral wiki page for the SSL::renegotiate iRule command. A separate DevCentral login is required to access this content; you will be redirected to authenticate or register (if necessary).

BIG-IP versions 9.3.1 HF8, 9.4.8 HF2, 10.0.1 HF3, and 10.1.0 through 10.2.x

To mitigate the vulnerability, a BIG-IP system administrator may apply iRules similar to the following to each SSL virtual server. This sample iRule uses the SSL::renegotiate command to disable client-side session renegotiation, which prevents the BIG-IP from processing a secondary session renegotiation request:

when CLIENTSSL_HANDSHAKE priority 1 {
   SSL::renegotiate disable
}

The <enable|disable>parameter was added to the SSL::renegotiate command in versions 9.3.1 HF8, 9.4.8 HF2, 10.0.1 HF3, 10.1.x and 10.2.0 as a result of ID 213305 (formerly CR132165). In versions prior to 10.1.0, all virtual servers with a Client SSL profile applied will by default still accept session renegotiation.

Note: For more information, refer to the DevCentral wiki page for the SSL::renegotiate iRule command. A separate DevCentral login is required to access this content; you will be redirected to authenticate or register (if necessary).

BIG-IP versions 9.4.x, 9.3.x prior to 9.3.1 HF8, and 10.0.x prior to 10.0.1 HF3

To mitigate the vulnerability in versions that do not include the SSL::renegotiate command, apply an iRule similar to the following to each SSL virtual server. The iRule resets the connection if client-side SSL renegotiation is attempted.

when CLIENT_ACCEPTED {
    # initialize TLS/SSL handshake count for this connection
    set sslhandshakecount 0
}
when CLIENTSSL_HANDSHAKE priority 1 {
    # a handshake just occurred
    incr sslhandshakecount
    # is this the first handshake in this connection?
    if { $sslhandshakecount > 1 } {
        # log (rate limited) the event (to /var/log/ltm)
        log "\[VS [IP::local_addr]:[TCP::local_port] client [IP::remote_addr]:[TCP::remote_port]\]:TLS/SSL renegotiation"
        # if not, close the clientside connection
        reject
    }
}

Note: This example was provided by F5 DevCentral poster Lupo. The original post is available at the following location:

mitigating the TLS client-initiated renegotiation MITM attack

A separate DevCentral login is required to access this content; you will be redirected to authenticate or register (if necessary).