QID 42366 : SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Vulnerability (CVE-2011-3389) is reported based on SSLv3.0/TLSv1.0 being detected as enabled with CBC mode. The full recommended solution for QID 42366 is to disable SSLv3.0/TLSv1.0, and use TLSv1.1 or later. If an upgrade to TLS is not currently feasible, a short term mitigation for QID 42366 would be to avoid using CBC mode within SSLv3.0/TLSv1.0, and instead rely on RC4 suites. (Note that RC4 also has some current insecurities, and so the full update to TLSv1.1 or later is strongly recommended)

You can leverage the free Qualys SSL Labs tool https://www.ssllabs.com/ to run a quick SSL Test and confirm if your system is fully vulnerable, or if the risk has been ‘mitigated’ by removing CBC from SSLv3.0/TLSv1.0. In such cases this can be approved as a PCI False Positive Request, or should no longer be reported during a re-scan.

This vulnerability explanation is confusing. Upgrading TLS won't actually fix this. After upgrading you must disable TLSv1.0 completely for this vulnerability to be eliminated from a scan. But eliminating TLSv1.0 completely will also disable access from Android 4.3 (and earlier) as well as IE 10 (and earlier). Based on Google's own statistics this would disable access from more than 66% of android users and at least that amount for IE users. Is eliminating access to that large of a pool of users really considered a valid solution?

Simply using the cipher string

RC4-SHA:HIGH:!ADH

(as implied in the QID 42366) lands a fat F in the Qualys SSL analyzer.

A more nuanced approach seems necessary. A good start is implementing something similar to Steve Caligo's cipher string (explained a little bit here The specified item was not found.

ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

The idea is that you put a few TLS 1.2 cipher suites first so that they can be picked up by TLS 1.2 clients, which are not vulnerable, followed by RC4 for TLS 1.0 clients.