The conditions that allow the exploit are:
[In order to conduct the attack, the following conditions must be true]:
1. HTTPS-enabled endpoint (ideally with stream ciphers like RC4, although the attack can be made to work with adaptive padding for block ciphers).
2. The attacker must be able to measure the size of HTTPS responses.
3. Use of HTTP-level compression (e.g. gzip).
4. A request parameter that is reflected in the response body.
5. A static secret in the body (e.g. CSRF token, sessionId, VIEWSTATE, PII, etc.) that can be bootstrapped (either first/last two characters are predictable and/or the secret is padded with something like KnownSecretVariableName="".
6. An otherwise static or relatively static response. Dynamic pages do not defeat the attack, but make it much more expensive.
So, it looks to be a pretty narrow set of criteria at this point. That will probably change as more folks look at the issue. This isn't a trivial exploit, at this time. I suspect there will be patches to HTTPS server and client sides before long, though.