Implications of the Twitter attack using the SSL gap

Posted  November 17, 2009 By Steve

When we released the SSL authentication gap details a couple of weeks ago, I was convinced that this was a serious issue that needed immediate attention. Although most everyone agreed, there were a few commentators out there that weren’t as concerned about the problem as I was.

Well, fast-forward a few days, and the situation has changed. A clever researcher by the name of Anil Kurmus has demonstrated a working exploit against Twitter using the request-splicing technique we outlined in the “Renegotiating TLS” paper. He leveraged the flaw into a revealed-plaintext attack against Twitter, with the effect that a bad guy could steal any user’s username and password.

It’s difficult to say just how a flaw like this in an underlying security protocol will affect the upper-layer protocols, like HTTP, that depend on it. Certainly, as Bruce Schneier often observes, attacks only get better. So while we’re not about to go out and see what all we can exploit with this flaw, I’m certain that there are cleverer hackers out there that will have no trouble in leveraging this flaw into a serious problem for a wide variety of sites.

It’s interesting to consider why the opinions of some researchers have been shifting as to the severity of this issue. In my opinion, it is primarily the result of the subtlety of this flaw. There have been numerous arguments about whether or not TLS was even broken at all, or if on the other hand, the fault lay in the higher-level protocols such as HTTP. This argument has been batted around extensively in public by some of the world’s brightest security protocol engineers.

It didn’t help matters that we described the flaw primarily in the context of client certificate-based authentication. That was the first case Marsh found and got working, but we were eventually able to broaden the attack to the potentially much more dangerous client-initiated attack that was used in the Twitter exploit. It probably should have been moved to the top of the paper we released, but in our defense, we had planned a major revision next month or so; we were as taken by surprise at the unexpected release of the flaw as everyone else was.

The reality is that it’s going to take a while for the full implications of this flaw to be worked out. It’s never pretty when a security protocol is found to be deficient, and as Chris Paget pointed out, there are a great many other protocols that use TLS, some of which may also be impacted by this find. I think we’ll be finding problems related to this flaw for months or years to come.

-Steve