This issue was identified by security researchers Marsh Ray and Steve Dispensa. The vulnerability exists because certain Transport Layer Security (TLS)/Secure Sockets Layer (SSL) protected protocols assume that data received after a TLS renegotiation is sent by the same client as before the renegotiation. Renegotiation is TLS functionality that allows either peer to change the parameters of the secure session. In this post, we’ll explain how our fix works, and why the risk to most Microsoft customers is limited.
TLS and SSL did not effectively guarantee this authenticity, and as a result, the underlying protocol would need to ensure that the renegotiated session is still with the same peer, something the protocol is often ill prepared for. An attacker with the ability to intercept traffic (for instance through an ARP spoofing attack, or DNS cache poisoning) could execute a man-in-the-middle attack, intercept a TLS renegotiation attempt, and partially pose as the authenticated client.
By cleverly manipulating the protocol, the researchers identified that as man-in-the-middle, they could keep the client-end of the connection stalled, start up their own renegotiation with the server, and submit data. Once the server received it, they would restart the renegotiation, and pass the server’s renegotiation attempt back to the client as if nothing happened. While an attacker cannot use this to change or read encrypted information, it can be leveraged to prepend data to a secure connection.
Some protocols are more affected than others. HTTPS for instance, is affected. An attacker can send an HTTPS request from the client to the server, and by splicing the request can have the actual client send through the authentication cookie. The server will read the request issued by the attacker, and attribute it to the authenticated client.
The risk to most Microsoft customers, overall, is limited. While the TLS/SSL implementations for all vendors are affected, overall risk to our customers is limited. In order to exploit this vulnerability, the attacker needs to abuse TLS renegotiation already taking place between both peers. Internet Information Services (IIS) 6 and 7, do not allow clients to initiate TLS renegotiation, removing the attacker’s ability to induce a vulnerable scenario. These servers will only start up renegotiation themselves when they are configured to ‘accept’ certificate based mutual authentication. This is a non-default scenario. In addition, our team found a number of other reasons why this issue would be difficult to exploit. We published more detail on our overall risk assessment in this February blog entry.
It is important to note that this is still potentially a significant issue for certain deployments, and the update should be installed. In particular, the vulnerability may affect other, non-HTTP protocols that are less well understood. When the vulnerability was identified, Microsoft worked through the Industry Consortium for Advancement of Security on the Internet (ICASI) to ensure that we had a TLS-layer fix which is compatible with third-party TLS implementations.
The result of that collaboration, and hard work by many other security developers in the IETF TLS working group, led to the publication of RFC 5746, the TLS Renegotiation Indication Extension. This new standard, co-authored by Nasko Oskov in our Windows security engineering team, addresses the vulnerability by defining a TLS extension that cryptographically binds renegotiations to their initial TLS connection. With this fix installed, the TLS endpoint itself can validate whether the data sent still belongs to the same initial connection. There is no longer any requirement for the encapsulated protocol to do so.
In order for a connection to be fully protected, both client and server need to have a TLS implementation that is RFC 5746 compliant. As of today, we’re happy to announce that Microsoft customers have an update available that will deploy this new functionality. We also know many other vendors have either released or are in the process of releasing support for this extension.
We understand that administrators may have a need to require clients to have the update in order to connect to high-security applications. A registry key is available, documented in KB 980436, which allows the administrator to place a system in “Compatible” or “Strict” mode. In compatible mode, the default setting, the client will enable the use of this TLS extension, but not enforce it. A client connecting without the security update will still be able to successfully connect with peers that do not. In strict mode, both peers will require the standard in order to successfully connect.
The following diagram displays this in more detail:
Thanks to the following for their work on this issue and feedback on the blog:
Nasko Oskov from Windows Security Engineering
Gavin Thomas and Robert Hensing from MSRC Engineering
Manoj Thakur and Chunlin Shi from Windows Sustained Engineering