According to a recent article by Dan Goodin in the Register, engineers have apparently signed off on a fix for the TLS renegotiaion vulnerabilty. Read on to learn what the problem is, and what the proposed solution involves.
What’s The TLS Vulnerability Issue?
In 2009 there was a bit of discussion around a fundamental flaw with Transport Layer Security (TLS) and renegotiation. The vulnerability resulted in the possibility of a man-in-the-middle (MITM) attack and manipulation of traffic by injecting text at the beginning or end of the traffic. Note that the traffic remains encrypted and the attacker is unable to decipher it. From the Register:
It allows man-in-the-middle attackers to insert text at the beginning of an SSL stream each time a session is negotiated. The vulnerability stems from the ability for either party in an SSL transaction to renegotiate the session, usually so one can refresh its cryptographic keys.
Why Is This a Big Deal?
This is a fundamental component that affects practically any recent application or OS that uses SSL/TLS, including Apache OpenSSH, and Cisco applications. It’s not terribly difficult to sniff wireless browser traffic in a place like a coffee shop. While the attacker is unable to decipher the traffic directly, that may not be needed. In some cases an attacker may be able to direct browsing traffic to do something without needing any authentication information.
Depending of the traffic destination, the attacker may be able to manipulate what happens at the destination and get the decrypted data as a result. This is the example vulnerability that was demonstrated, stealing usernames and passwords from Twitter.
What’s The Fix?
Except for patches from a few vendors, about the only thing that could be done was to disable TLS renegotiation. The latest draft of specifications appears to change the requirements for the TLS renegotiaiton extension and communication between client and server, checking the state of various protocol flags and capabilities of the client.
The new protocol overhauls the way SSL-enabled software renegotiates encrypted sessions so it’s no longer possible for attackers to inject malicious payloads into encrypted traffic passing between two endpoints. The vulnerability violated one of the core guarantees provided by SSL by making it possible to perform man-in-the-middle attacks that could steal sensitive data or tamper with secure transactions.
Victim shopping online at Biggins.com via a public wifi hotspot. The Attacker intercepts that traffic by impersonating the wireless access point. The Attacker inserts their own HTTP header first, crafting a GET statement to add items to the cart and buy products from the Attacker’s storefront rather than the intended one, followed by an HTTP header command to ignore anything else that follows. The Victim’s session info was stored in a cookie, which included authentication, and that cookie is already present in the traffic that was intercepted. The Attacker doesn’t need to see the cookie, just to keep it included in the traffic which is appended to the request by the attacker. Victim ,seeing no difference, completes the checkout.