Mozilla created an extensive page  concerning the best current choice of SSL/TLS cipher suites, primarily for web servers. Compass Security agrees broadly with the article, but recommends some additional restrictions in order to provide the most resistance against active and passive attacks versus TLS secured connections:
- Use 3DES cipher instead of RC4
- Disable SSLv3 support
Compass Security recommends against using RC4, and favors 3DES for a transitional period. 3DES only provides 112 bit keys (and may therefore be more prone to brute force attacks on the key), but is otherwise regarded as not (yet) broken. RC4, on the other hand, is considered not secure anymore:
- A “nearly practical” attack exists, as the first bytes of the stream cipher are biased (not perfectly random)
- Microsoft recommends to disable it, and warns developers to not use it anymore 
- The NSA is suspected to be able to decrypt it in real-time 
- RC4 was primarily used to thwart BEAST and Lucky13 attacks. But BEAST is fixed on current browsers. Exploiting Lucky13 is currently not practically feasible 
For additional security, it is possible to remove SSLv3 support altogether, as it contains several weaknesses:
- Weaker key derivation process than TLS
- Cannot be validated under FIPS 140-2
- There have been various attacks on SSLv3 implementations
- Vulnerable to certain protocol downgrade attacks
TLSv1.0, which was released in 1999, contains several additional security features in comparison to SSLv3. For example, it uses both SHA-1 and MD5 at the same time, making it less vulnerable if one of these hash functions becomes insecure.
All browsers, except IE6 on Windows XP (in its default configuration) support at least TLSv1.0. The default IE8 browser on an up-to-date Windows XP, happily connects to TLS-only web servers. Nevertheless, other software may not be compatible with such an restricted configuration yet.
Furthermore it is recommended to turn off TLS compression. This will fix the CRIME attack on TLS connections, even if vulnerable OpenSSL implementation on the server is being used, while an obsolete browsers which do not have this issue fixed is connected. If the server uses current OpenSSL library, and/or the client has the CRIME fix implemented, this attack is not feasiable anyway. Turning off TLS compression will not mitigate the BREACH attack, as it uses the compression feature of HTTP, not TLS. See  for further information about this issue.
This concludes the discussion about most of the currently known SSL/TLS attacks, and their mitigation.
The following chapter provides an Apache configuration example, which incorporates the discussion above. It is based on https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses
The implemented cipher prioritization logic is as follows:
- Most secure TLS 1.2 ciphers first: AES-GCM
- AES with PFS: ECDHE (Elliptic Curves)
- AES with PFS: DHE (Traditional RSA)
The cipher prioritization list:
Virtual host SSL configuration:
<VirtualHost *:443> ... SSLProtocol All -SSLv2 –SSLv3 SSLCipherSuite <recommended ciphersuite from above> SSLHonorCipherOrder on SSLCompression off # default off, except in 2.4.3 and 2.2.24 to 2.2.25 SSLInsecureRenegotiation off # default ... </VirtualHost>
This TLS- and AES/3DES-only configuration was successfully tested with current versions of IE8, Chrome and Firefox on Windows XP.
Example configuration settings for Windows. This should act as a basic configuration skeleton. Before deployment, the configuration needs to be actively tested in an production environment. The cipher list has been extracted on a Windows 7, but is identical to that of a Windows 2012 Server.
Disabling SSLv2 and SSLv3:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server] "DisabledByDefault"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server] "DisabledByDefault"=dword:00000001
- ECDHE ECDSA AES-GCM SHA2
- ECDHE ECDSA AES-CBC SHA2
- ECDHE RSA AES-CBC SHA2
- ECDHE RSA AES-CBC SHA
- ECDHE ECDSA AES-CBC SHA
- DHE DSS AES-CBC SHA2
- DHE DSS AES-CBC SHA
- DHE DSS 3DES SHA
- RSA AES SHA2
- RSA AES
- RSA 3DES
Configure Schannel according to the recommendations above and these pages:
- How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll
- Cipher Suites in Schannel
This renewal in favor of more secure SSL ciphers can be a good opportunity to kick-off further clarifications and investigations about SSL related topics in your company, e.g.:
- Is all your web infrastructure (proxies, WAFs, web servers, …) ready to support TLSv1.1 and TLSv1.2?
- Are the clients you manage use an adequate configuration for setting up SSL communication (e.g. Prioritizing Schannel Cipher Suites for Windows clients)
- Have your SSL certificates a 2048 bit private key?
- Have your CA SSL certificates a 4096 bit private key?
- Does your internal PKI enforce best practices and is moving to SHA2 and ECC? 
- Are you using the most current version of the webserver?
- Are you using the most current version of OpenSSL?
- Microsoft recommends disabling RC4
- Article about suspicious that NSA is able to decrypt RC4
- Article about suspicious that NSA is able to decrypt RC4, german
- Bruce Schneier about attack on RC4 from spring 2013
- Discussion “RC4 is kind of broken in TLS”
- Qualys Discussion about retiring RC4
- Mozilla Article about SSL ciphers
- Qualys SSL Test
- Web Browser Support Matrix
- MS SHA1 deprecation policy
- Windows Root Certificate Program – Technical Requirements version 2.0
- Nginx SSL Module
- Qualys – Defending against the BREACH Attack
Thanks to Alexandre Herzog for research, review and discussions concerning this matter.