Angelo Prado, Neal Harris and Yoel Gluck reported , that SSL/TLS attacks are still viable via a "BREACH" (Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext) attack, which they describe as:
While CRIME was mitigated by disabling TLS/SPDY compression (and by modifying gzip to allow for explicit separation of compression contexts in SPDY), BREACH attacks HTTP responses. These are compressed using the common HTTP compression, which is much more common than TLS-level compression. This allows essentially the same attack demonstrated by Duong and Rizzo, but without relying on TLS-level compression (as they anticipated).
BREACH is a category of vulnerabilities and not a specific instance affecting a specific piece of software. To be vulnerable, a web application must:
* Be served from a server that uses HTTP-level compression
* Reflect user-input in HTTP response bodies
* Reflect a secret (such as a CSRF token) in HTTP response bodies
It is important to note that the attack is agnostic to the version of TLS/SSL, and does not require TLS-layer compression. Additionally, the attack works against any cipher suite. Against a stream cipher, the attack is simpler; the difference in sizes across response bodies is much more granular in this case. If a block cipher is used, additional work must be done to align the output to the cipher text blocks.
CERT has an entry describing the flaw as well . Currently no CVE is assigned as MITRE is attempting to determine whether one CVE will suffice, or whether it will require multiple CVEs (one per affected product). 
Mitigations are noted by the researchers as follows
1. Disable HTTP compression.
2. Separate the secrets from the user input.
3. Randomize the secrets in each client request.
4. Mask secrets (effectively randomizing by XORing with a random secret per request).
5. Protect web pages from CSRF attacks.
6. Obfuscate the length of web responses by adding random amounts of arbitrary bytes.
Sorry, just realized that CERT did indeed reference CVE-2013-3587.
This is more related to compression than SSL itself, from my understanding. As noted in Novell's bug report  we need to look at mod_deflate, probably mod_gzip, and Accept-* headers in case PHP is doing output compression (the same would likely go for other languages).
*** Bug 994856 has been marked as a duplicate of this bug. ***
While there has been some discussion about addressing this flaw in upstream Apache project, no decision was reached. It is currently unlikely that this issue will be fixed at server level. Discussion here:
The version of httpd package shipped with Red Hat Enterprise Linux 5 and 6 is not vulnerable by default, because 'DEFLATE' is not enabled in its default configuration.
The simplest mitigation is to disable DEFLATE for responses which are vulnerable to this attack. Other mitigation options are listed in comment #0
This issue is not planned to be addressed in the version of httpd as shipped with Red Hat Enterprise Linux 5 and 6. More details and possible mitigations are mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=995168#c5
This issue affects the version of httpd package as shipped with Fedora 19 and Fedora 20. The version of httpd package shipped with Fedora is not vulnerable by default, because 'DEFLATE' is not enabled in its default configuration. Users are advised to follow mitigation details listed in comment #0