There has recently been a couple questions from our customers regarding in-depth technical details of how nCircle detects if TLS Legacy Session Renegotiation is enabled on a server, and so it was suggested to me that I write a blog post about it. Since I've been meaning to set aside some time to write my first blog post since transitioning from being a Software Engineer here at nCircle to a Security Research Engineer on VERT, I figured this would be a great excuse to do just that.

First, I figure some background information would be appropriate. Session Renegotiation was defined by the IETF in RFC 2246 for the TLS protocol. This standard specified that either the client or server can initiate a renegotiation request during an established TLS session. Renegotiation allows new cryptographic parameters to be established for that session, meaning new keys can be used and new cipher suites can be chosen. Why is this bad? Because the server doesn't keep track, nor does it care, about which TLS session a renegotiation is being performed over. This opens up the door for a man-in-the-middle to hijack TLS sessions, meaning the attacker can potentially view confidential information such as credentials or credit card information being transmitted over the session, a big no-no for PCI. Though he cannot simply read the communications in plaintext, since the communication between the victim client and server will be encrypted after the renegotiation has taken place; by exploiting this feature of TLS, a man-in-the-middle may be able to modify the requests themselves in order to obtain confidential information. This vulnerability can defeat the entire point of using TLS, and so it's very important that TLS session renegotiation be detected by IP360 so that it can be disabled on the server before it has the chance to be abused. If nCircle detects this vulnerability on your system, you will not pass PCI compliance. In response to this problem, the IETF has created RFC 5746 to define a TLS extension that cryptographically ties a renegotiation to the TLS connection that established the initial encrypted tunnel. Making use of the renegotiation extension defined in RFC 5746 is commonly referred to as secure renegotiation, whereas the insecure method of renegotiating is known as legacy renegotiation.

In order to take advantage of legacy session renegotiation, an attacker first establishes a connection with the TLS server, and then intercepts a victim’s TLS communications and tunnels them through his own session. The attacker can either establish a TLS session ahead of time and wait for another client to attempt to connect, or the attacker can establish the connection on the fly. Either way, the Client Hello sent by the victim client is intercepted by the attacker, and sent encrypted over the attacker’s session as if the attacker was initiating a renegotiation. After the victim client finishes its’ handshaking process, the attacker then acts solely as a proxy between the victim client and the server. Communication between the victim client and server from this point on is encrypted. Even though the attacker may not be able to read the communications directly, he can inject his own content into the session in an attempt to obtain confidential information or make the server behave in a way that was not intended by the victim client.

An example attack that made use of the legacy session renegotiation flaw is the famous Twitter exploit where a researcher was able to obtain a user’s login credentials by injecting text into the https requests. This caused Twitter to dump the contents of the web request into a Twitter message after it had been decrypted by the server. If the same attack was attempted today, and Twitter’s servers only allowed secure renegotiation, this attack would not be possible. The server would have rejected the attacker’s renegotiation request if he attempted to use the victim client’s Client Hello since the attacker’s TLS session would have been cryptographically tied to himself.

Since I’ll be diving headfirst into the inner-workings of the TLS protocol, this post is geared toward a more technical audience. We have had some positive feedback from our customers regarding our detection of this vulnerability, mostly in cases where the customer thought renegotiation was disabled on their server only to find out that it actually wasn’t. Here at nCircle, VERT has put in a lot of work toward detecting this issue. Considering the critical nature of this vulnerability and how many potential people it impacts, we would like a chance to share our knowledge with other security researchers in the hopes that they may write or improve their own detection for it. At the same time, it would be great to hear feedback regarding our detection that may help us to make improvements to it.

Click here to read about how nCircle detects TLS Legacy Session Renegotiation.