What a fabulously badly written, sensationalistic article. The TLS problem published last week affects virtually none of the applications that use HTTPS on the web today: they're currently only relevant to applications in which the client is required to carry a certificate to authenticate themselves.
That was the initial report from one of the researchers, but there are claims that it can be demonstrated to work in cases not involving client-side certificates, too. See http://extendedsubset.com/?p=8 : "Cases not involving client certificates have been demonstrated as well."
Unfortunately, that's all the data I have on that, that one sentence, and a few other places that have the same basic info which may or may not simply be reflections of this one. I haven't seen any additional substantiation.
The flaw here is that TLS tunnels multiple sessions inside a single connection, and, particularly with HTTPS, the first one of those sessions is both client-anonymous and (the bug) "live" --- in that any commands received in that session will be processed as long as a subsequent session is client-authenticated. That's the "authentication gap" being talked about in the reports.
What's also true is that there are lots of protocols, many of them very obscure, that either rely on client auth, or that may themselves have an app-layer notion of multiple sessions which will conflict with TLS's session renegotiation.
I'm not going to eat my hat or anything if this happens, but I'd bet againt someone finding a plausible MITM attack that beats server certificates using this attack. I think it's reasonably safe shorthand right now to say this attack largely applies to apps that use SSL outside of its common case.
In my 5 years as a UNIX Sysadmin I've set up SSL/TLS hundreds of times to protect web, email, and database communications, and not once have I ever been compelled to use client side certificates for authentication.
I strongly agree. Client cert auth is also harder to screw up than most of the alternatives, and, let's face it, the alternatives are almost always "shared passwords stored in configuration files".
