Case Closed: SSL/TLS Authentication Gap Posted  August 19, 2010 By Marsh Ray

It was one year ago this week that I began in earnest a coding project to prove or disprove my suspicion of an exploitable weakness in TLS renegotiation. I fully expected to fail in this endeavor as this protocol was generally regarded as having stood the test of time. Even after I had a working demo in hand I scarcely believed it, halfway expecting to be interpreting some result wrongly or to be pointing out a non-issue which had always been obvious to everyone else.

Nevertheless, Steve and I decided to begin the process of disclosing this bug to respected members of the security community, vendors, and other code owners with the expectation of widening the circle over time. Although our sentiments typically favor aggressive disclosure timelines, it was clear that the complex dependencies and the multi-vendor nature of this bug made that approach unrealistic. We reasoned that the most well-engineered solution would have the best chance of emerging from a coordinated process. So for the next few months, we offered our help in working out tentative agreement on a proposed solution and giving some vendors a little head start in their implementation efforts.

A few months later, the vulnerability was independently rediscovered and publicly described. In retrospect, this was a classic case of “sometimes you get what you need” though it was hard for everyone to accept at the time. Now that the cat was out of the bag, the protocol standardization efforts could be conducted with the usual open, public processes of the IETF. After a great deal of discussion, the proposed solution was eventually accepted with just a few missing details filled in (RFC 5746).

At this point, we were a bit surprised at the absence of a great rush to patch vulnerable software with support for the protocol extension which fixed renegotiation (perhaps we were still a bit idealistic). We’d expected open source TLS implementations to take an early lead. But in fact, most distributors had patched their software to simply disable renegotiation outright and now seemed to be in no hurry to re-enable it securely (this logic is flawed for subtle reasons). Sometimes open-source TLS libraries implemented support for the fix which stalled in the pipelines of their downstream distributors. It was the commercial browser vendor Opera that first implemented secure renegotiation in a major product, and many other vendors have followed along since.

Microsoft’s case was particularly challenging. They have invested heavily into web-based technologies and consequently have one of the largest varieties of products speaking TLS. Their commitment to platform support going back years and multiple OS versions meant that, in some cases, older designs had to be given significant architectural upgrades. Through a combination of conservative design and accident, Microsoft clients and servers tended to not be willing to perform TLS renegotiation without reason. Thus in many cases, a Microsoft client talking to a Microsoft server would not be susceptible to the bug (although they still needed to be patched for the greater TLS ecosystem). To their credit, Microsoft never used this argument to advocate delay.

Last Tuesday, just nine months since the public disclosure of the TLS renegotiation vulnerability, Microsoft pushed down a patch via their Windows Update channel which added support for the protocol extension to all their operating systems and applications, beating several smaller vendors in the process.
At a time when vendors are often criticized for slow responses to seemingly small but severe defects, the industry has proven it can work together to fix a very challenging bug in an interoperable protocol in record time. I think now is a good a time as any to claim victory.

- Marsh Ray