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 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, IIS server initiates renegotiation if a negotiated but non-authenticated client requests a restricted server resource, so that the client could authenticate himself with the certificate.
Links to the documents describing the attack in detail are available here.
The reaction of 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.
We at EldoS Corporation, understanding the importance of the discovered attack and its potential effects, decided to postpone the 7.2 release date a bit 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 attackA weakness in the TLS protocol design allows the active attacker (so-called MITM, or a man-in-the-middle) to prepend the stream of application data sent from the real client to the real server with an arbitrary sequence of bytes (see an example below):
GET /good.html HTTP/1.0
|Prepends the data with|
GET /bad.html HTTP/1.0
GET /bad.html HTTP/1.0
X-Ignore: GET / good.html HTTP/1.0
and sends the contents of /bad.html to the client instead of originally requested /good.html.
The attack looks quite dangerous, however, there is some good news: for most of the existing environments, SSL cipher renegotiation must be invoked by the server closely to the start of the intercepted negotiation to make the attack successful. The bad news here is that many server-side implementations use 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 secure, but non-authenticated connection.
It should be noted that MITM is not aware of the data that is sent by the real client. This may slightly complicate the attack for him, but not that 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 wrong page to the requester. If the attacker will use POST instead of GET, he will be able to upload some data to the server under the credentials of the legitimate user. Preventing the attack
There is no general way to prevent the attack for client and server conforming to the existing SSL/TLS specification. The proposed draft (see above) introduces certain improvements to TLS protocol set (1.0, 1.1, 1.2), however, implementing them in all the SSL-capable products available worldwide is not a task of one day. We should note that the proposed anti-attack features must be supported by both sides of the communication to provide an effect.
The obvious way for server to make the attack impossible is to refuse from using cipher renegotiation. Unfortunately, this solution is not applicable on client side – without deploying the fix described in the above draft the client has no way to detect if his connection to 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 non-updated user code is insecure. We did not turn on attack prevention features intentionally to preserve compatibility with most of the existing third-party TLS implementations that are not yet updated.
The anti-attack features that have been introduced are observed below.
Added features: overview
- All SSL-capable components publish the RenegotiationAttackPreventionMode property of 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 behaviour of the components does not differ from earlier SecureBlackbox builds, no special attack prevention methods are used. This mode is recommended for use if there is a need of 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 use attack prevention features wherever possible. Whether these features have been negotiated for a particular connection is indicated by the value of PeerExtensions. RenegotiationInfo.Enabled property.
- OnRenegotiationStart event has been added to 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 means for refusing it.
- (ActiveX edition only) Since adding the above features (in particular, new events) to 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 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 client side is to set RenegotiationAttackPreventionMode to rapmStrict. However, as the majority of the existing server-side SSL implementation 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, proceeding with insecure communication. Our tests have exposed no compatibility problems (all the servers who do not support 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 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 the 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 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.