Someone listening in on your connection could take over your bank account session, pay pal session etc. It's unclear from the article how practical it is though, since it seems to require a JS injection on the attacked site.
Not on the attacked site, no. Sounds like it would suffice to serve custom JavaScript to any unencrypted page running in the same browser, and sniff all the traffic going between an encrypted site and that browser.
How exactly would you sniff traffic between an encrypted site and the browser, without running JS in that encrypted site, or without exploiting the browser (in which case you already won and don't need need to break SSL)? Is this some sort of man-in-the-middle hybrid that uses JS as an attack vector?
Let's say an ISP in an oppressive country is hooked up to a government system which sniffs all traffic. It's able to record all your SSL traffic but is unable to decrypt it since it doesn't know the session key that was used for encryption.
At the same time you're browsing on the SSL-secured site, you're also using a site which isn't SSL-secured in another tab. The ISP can inject the unsecured site with specially crafted javascript for your browser to execute. This javascript fetches data from the SSL-secured site using specific known plaintext[0] and the ISP records the resulting traffic. Presumably this separate tab would not have to renegotiate the SSL handshake from scratch, thereby reusing the previously randomly generated session ID.[1] By doing this very deliberately with specially chosen plaintext, over time you have enough data to reverse engineer what key was used to encrypt the data.
[0] I'm guessing it takes the form of a GET request to non-existent resources. You know part of the input, and the resulting 404 page is almost always the same so you know part of the output.
