A researcher has published an exploit that uses the SSL renegotiation attack to compromise Twitter logins. That appears to run counter to earlier assessments that this exploit wasn't aimed at the accounts of individuals accessing sites. So what's going on here, you ask?
This attack does indeed follow the parameters of the attack as previously described. It attaches exploit code to the encrypted stream and indeed cannot decrypt the data going to and from the site. What the inserted exploit code does is take advantage of a vulnerability in Twitter's API that allows it to command Twitter to publish the credentials of the currently active account. And of course the currently active account by definition is the same as the one operated by the site visitor who owns this session.
It's a subtlety, but it matters to our resolution of the problem. This attack combined two vulnerabilities, the recently discovered renegotiation flaw and this hole allowed by the Twitter API. While this same vulnerability doesn't necessarily exist in the APIs of other popular sites with some sort of publishing capability, there certainly is the possibility that it exists in some or many such sites.
This new attack hasn't changed industry's best response in a meaningful way. The software vendors need to develop and push patches. Site operators need to deploy them. What's new here is that while they're waiting for their software providers, site developers can look at their APIs and safeguard against attacks of this nature. And depending on the application, there are other potential defenses as well. For instance, in this case Twitter could offer a two-factor authentication solution to defend users against account takeover. In that scenario, even if a malicious party were to steal the login information, it would be worthless without the offline credential or other factor.