SecureBlackbox 16: Preventing TLS Renegotiation Attacks with SecureBlackbox 7.2 and Later

A class of serious attacks on the SSL/TLS protocol has been discovered recently. The attack utilizes a protocol design flaw and allows an adversary to insert arbitrary data into the very beginning of the application, the data stream sent from the legitimate client to the server.

The vulnerable part of the protocol is cipher renegotiation. The renegotiation mechanism is often used to authenticate the client to the application layer. For example, the IIS server initiates renegotiation if a negotiated but non-authenticated client requests a restricted server resource, so that the client can authenticate itself with the certificate.

The reaction of the internet society was quite fast and resulted in a published draft of the standard that is supposed to make the attack impossible. Unfortunately, the proposed workaround is a breaking change in the protocol and can result in certain interoperability problems between parties that are not aware of it.

Understanding the importance of the discovered attack and its potential effects, we decided to postpone the 7.2 release date for the sake of making it safe with regard to the mentioned attack. The instructions below observe the attack prevention features that have been introduced and provide instructions on their deployment to the user code.

The Attack

A weakness in the TLS protocol design allows an active attacker (a so-called MITM, or a man-in-the-middle) to prevent the stream of application data sent from the real client to the real server with an arbitrary sequence of bytes (see an example below):

The attack looks quite dangerous. However, there is some good news: for most existing environments, the SSL cipher renegotiation must be invoked by the server close to the start of the intercepted negotiation to make the attack successful. The bad news here is that many server-side implementations use the renegotiation approach to authenticate connected clients on the application layer. For example, IIS initiates renegotiation to request a certificate from the client if the latter requests a restricted resource using a secure, but nonauthenticated connection.

It should be noted that the MITM is not aware of the data that is sent by the real client. This may slightly complicate the attack for the attacker, but not by much.

What is Vulnerable and What Damage Can Be Caused?

It depends on the application level protocol being used. According to the example above, the attacker can force the server to return the wrong page to the requester. If the attacker uses POST instead of GET, he or she can upload some data to the server under the credentials of the legitimate user.

There is no general way to prevent the attack for a client and server conforming to the existing SSL/TLS specification. The proposed draft (see above) introduces certain improvements to the TLS protocol set (1.0, 1.1, and 1.2); however, implementing them in all the SSL-capable products available worldwide is not a one-day task. We should note that the proposed countermeasures must be supported by both sides of the communication to provide an effect.

The obvious way for the server to make the attack impossible is to refuse the use of cipher renegotiation. Unfortunately, this solution is not applicable on the client side -- without deploying the fix described in the above draft the client has no way to detect if the connection to the server is a subject for intrusion (even though there have been no cipher renegotiations performed).

Preventing the Attack with SSLBlackbox

First of all, we should note that even after upgrading to 7.2 the nonupdated user code is insecure. We did not turn on the attack prevention features intentionally to preserve compatibility with most of the existing third-party TLS implementations that are not updated yet.

Added Features: Overview

The countermeasure features that were introduced are observed below.

• All SSL-capable components publish the RenegotiationAttackPreventionMode property of the TSBRenegotiationAttackPreventionMode enumeration type. The property specifies whether and how exactly the component should act to prevent renegotiation attacks:
• rapmCompatible: The default value of the property. The behavior of the components does not differ from earlier SecureBlackbox builds, and no special attack prevention methods are used. This mode is recommended for use if there is a need for maximized compatibility with existing third-party implementations.
• rapmStrict: Attack prevention features are turned on. If the remote side does not support them, the connection will be terminated (client-side components), or cipher renegotiation features will be prohibited (server-side components).
• rapmAuto: The component will attempt to the use attack prevention features wherever possible. Whether these features have been negotiated for a particular connection is indicated by the value of the PeerExtensions.RenegotiationInfo.Enabled property.
• The OnRenegotiationStart event has been added to the server-side components. This event notifies the user code about cipher negotiation being requested, indicates whether this procedure is safe with regard to the renegotiation attack, and provides a means for refusing it.
• (ActiveX edition only) Since adding the above features (in particular, the new events) to the ActiveX controls breaks compatibility with existing user code, we decided to publish all of them in new interfaces, IElSSLClientAttackPreventionSettingsX (supported by all the client-side SSL controls) and IElSSLServerAttackPreventionSettingsX (supported by the server-side SSL controls). The below code illustrates the use of these interfaces in VB:

  Dim intf As IElSSLClientAttackPreventionSettingsX
  …
  Set intf = HTTPClient.Object ‘ HTTPClient is an ElHTTPSClientX control on the form
  intf.RenegotiationAttackPreventionMode = rapmAuto

I Use Client-Side SSLBlackbox Components: What Should I Do?

The only guaranteed way to exclude the possibility of the attack on the client side is to set RenegotiationAttackPreventionMode to rapmStrict. However, as the majority of the existing server-side SSL implementations still have not set up the patches (at least for today, November 20, 2009), doing this will result in interoperability problems. Another approach is setting RenegotiationAttackPreventionMode to rapmAuto, making the client attempt to use the attack prevention mechanism wherever possible, but at the same time to ignore the failure of the server to set it up and proceed with insecure communication. Our tests have exposed no compatibility problems (all the servers that do not support the new protocol extension silently ignored the request), so this approach seems reasonable for use until the patches are widely deployed. The PeerExtensions.RenegotiationInfo.Enabled property indicates whether the attack prevention mechanism has been negotiated. Please keep in mind that this mechanism only addresses TLS1 and higher versions of the protocol, so the SSL2 and SSL3 versions must be turned off.

I Use Server-Side SSLBlackbox Components: What Should I Do?

It is easier to introduce the necessary changes to the server-side code without breaking compatibility with existing third-party client-side software. Setting RenegotiationAttackPreventionMode to rapmAuto will make the server components negotiate the attack prevention mechanism if the client supports it, and at the same time talk insecurely to the clients who do not support it. Whether the attack prevention mechanism has been negotiated by the peers is indicated by the PeerExtensions.RenegotiationInfo.Enabled property. Setting RenegotiationAttackPreventionMode to rapmStrict will make the server disallow cipher renegotiation for the clients who do not support the attack prevention mechanism (those clients still will be able to use other security features of the protocol though).

I Use Both Client- and Server-Side SSLBlackbox Components: What Should I Do?

If you are developing a client-server system using both client- and server-side SSLBlackbox components talking to each other, you can safely set RenegotiationAttackPreventionMode to rapmStrict and be confident that both of the sides support it correctly.