TLS Extended Master Secret Extension: Fixing a Hole in TLS

Image

Few Internet technologies are relied upon as heavily as TLS/SSL, yet it has been widely known for years that this fundamental security protocol does not do enough to effectively protect communications. The most visible failing of TLS is the reliance on public key infrastructure (PKI) in which every certification authority (CA) becomes a potential single point of failure. Between CAs improperly issuing certificates for reserved names, getting hacked, and others simply issuing rogue certificates for trusted web sites, there is a massive problem threatening to undermine confidence in the web. The problems surrounding CAs and certificate trust are generally easy to comprehend since this is, at its core, a non-technical problem in which trusted entities fail to uphold their trustworthiness. Other problems, however, are far more technical and can be difficult for technical experts to wrap their heads around let alone lay persons. Problems related to the handshake process tend to fall under this category. Today, Microsoft has released an SChannel update to prevent a malicious server from carrying out the scary sounding “Triple Handshake” attack. Before getting into the specifics of this disclosure, it is important to preface with some background information. Over the years, security researchers have noted that, in some circumstances, the TLS handshake does not validate connections thoroughly enough to assure the authenticity of a connection. This was most notably illustrated in 2009 when Marsh Ray revealed how TLS session renegotiation could be abused by an active network adversary to inject arbitrary data into the beginning of an otherwise secured connection (CVE-2009-3555). At the core of the problem was a failure to bind handshake messages within a single connection to each other. This created shockwaves in the industry with vendors quickly reacting by completely removing support for TLS renegotiation and later coming back to implement RFC5746, allowing servers to more effectively guarantee secure renegotiation. Prior to that, Nokia researchers had revealed how certain EAP tunnel based authentication techniques were prone to MitM due to a lack of cryptographic bindings between authentication methods. More recently (March 2014), a group of researchers documented yet another situation in which an attacker could potentially impersonate an authenticated client. While this may sound scary, the slow industry reaction should give some indication that the risk is not on par with other MitM vulnerabilities. When carried out successfully, the triple handshake allows a malicious web server (not necessarily an active network adversary) to synchronize session parameters between a victim client and a victim server, thereby breaking some assumptions made by TLS. To understand why this is bad, it is necessary to explain more about the protocol than most people care to know but the full details are explained here. It is important to understand, however, that the described attacks affect sites and services using client certificates or channel binding for authentication. This means that typical HTTPS sites and most other TLS protected services are unaffected, which is likely why Microsoft felt comfortable waiting more than a year before implementing the advised solution (extended master secret computation) described in RFC7627. The known risk of the documented attack comes into play when TLS-based authentication is used during a renegotiation. In this scenario, if a malicious server is able to synchronize session parameters between the victim client and server, it becomes possible to have attacker-provided data attributed to an authenticated client. More generally speaking, it allows the malicious server to spoof a legitimate web site as Microsoft notes in the bulletin. The attacking server can go beyond injecting content into the beginning of a session (as we saw with CVE-2009-3555) and actually relay an encrypted session to a foreign service as if it were hosted on the attacker’s domain. Although the described attacks do not give the MitM knowledge of the post-renegotiation encryption keys, the capacity for spoofing means that a targeted service can be rendered within an HTML IFRAME tag in such a way that attacker controlled code can interact in defiance of the same-origin policy. While the specific attacks highlighted in the research do not directly undermine all TLS usage, the new extension does provide enhanced security for any connection that takes advantage of it. Web sites offering this extension will already benefit from enhanced security with the Google Chrome browser, as well as browsers using the updated SChannel (Internet Explorer and Microsoft Edge primarily). In order to help administrators identify which services make use of this extension, I have put together a quick test script available on the Tripwire GitHub. Given a hostname and optional port number, this script tests sends a test ClientHello for TLSv1, TLSv1.1 and TLSv1.2, including the extended master secret extension, and verifies whether or not the server advertises support for said extension in its response. Microsoft has rated this bulletin (MS15-121) as important, which I feel is appropriate for most systems but may not reflect the risk when using TLS-based authentication like client certificates, SASL, or PEAP. Administrators of currently unsupported Windows platforms should also be aware that as a protocol defect, this issue affects all previous releases. Please feel free to check out the Tripwire VERT detection script available on GitHub.