20.7 Insecure renegotiation

In 2009, Marsh Ray and Steve Dispensa, two employees of a company providing a multi-factor authentication solution that was eventually acquired by Microsoft and integrated into Azure, discovered a renegotiation-related vulnerability in then-current TLS versions that allowed Mallory to inject an arbitrary amount of chosen plaintext into the beginning of the application protocol stream [111].

Conceptually, then-current TLS versions were vulnerable to insecure renegotiation because server Alice did not verify whether the source – that is, her communication peer – of the old and the new data in a TLS session was the same.

Using the insecure renegotiation attack, Mallory can inject data that Alice will process as if it came from Bob. For instance, in a web application, Mallory can inject an unauthenticated HTTP request and trick Alice into processing that request in the context of the authenticated user Bob.

Technically, the attack is carried out in three steps [150]:

1. Mallory intercepts Bob’s TLS handshake request to Alice and suspends that request.
2. Mallory then opens a TLS connection to Alice and sends her the attack payload P.
3. Finally, Mallory passes Bob’s original TLS handshake request to Alice.

Figure 20.5 illustrates how the attack works against a web application secured using TLS [150]:

Figure 20.5: Insecure renegotiation

After suspending Bob’s TLS handshake, Mallory initiates her own TLS session with Alice and sends an HTTP request for the target page, with a partial header line (no newline at the end) that is deliberately left incomplete to neutralize the first line of Bob’s subsequent HTTP request:

GET /target.jsp HTTP/1.0
X-Ignore:

Once Mallory passes Bob’s original TLS handshake request to Alice, Alice and Bob establish their TLS session. From Bob’s perspective, the TLS session has just started, so he might send an HTTP request like this one:

GET /index.jsp HTTP/1.0
Cookie: JSESSIONID=5A644E…257

From Alice’s perspective, however, Bob’s TLS handshake is a renegotiation (because Alice has already established a valid TLS session with Mallory). As a result, Alice will pass Bob’s HTTP request to the web application, in the same context as Mallory’s request.

The web application does not care whether a renegotiation occurred in the middle of an HTTP request and will stitch the two HTTP requests together, resulting in the following:

GET /target.jsp HTTP/1.0
X-Ignore: GET /index.jsp HTTP/1.0
Cookie: JSESSIONID=5A644E…257

As a result, Mallory can impersonate Bob – using the authentication cookie that Bob transmits in the header of his HTTP request – while interacting with the web application.

Conceptually, insecure renegotiation vulnerability results from a missing validation that both HTTP requests originate from the same communication entity. Instead, Alice simply interprets both HTTP requests as part of the same data stream.