Our PCI compliance scanner, TrustWave, have failed our Win 2003/IIS6 site on BEAST because of the following cyphers:

Cipher Suite: SSLv3 : DES-CBC3-SHA 
Cipher Suite: SSLv3 : RC4-SHA 
Cipher Suite: SSLv3 : RC4-MD5 
Cipher Suite: TLSv1 : DES-CBC3-SHA 
Cipher Suite: TLSv1 : RC4-SHA 
Cipher Suite: TLSv1 : RC4-MD5

From my research, these are all OK, i.e. are 'strong' and not susceptible to the BEAST exploit. Scanning our site using https://www.ssllabs.com/ssltest/analyze.html results in a pass:

 TLS 1.2    No
 TLS 1.1    No
 TLS 1.0    Yes
 SSL 3.0    Yes
 SSL 2.0    No

Cipher Suites:
 TLS_RSA_WITH_RC4_128_MD5 (0x4)         128 
 TLS_RSA_WITH_RC4_128_SHA (0x5)         128 
 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)    168 

BEAST attack:   Not vulnerable

Should I dispute TrustWave's findings?

  • 1
    I think the problem is the DES-CBC3-SHA entry; we had a third-party pen test that said the same and wouldn't go away until we removed anything with CBC in its name. Commented Dec 14, 2012 at 17:00
  • 1
    Doesn't that present problems for users with XP and IE6/7? (they don't understand RC4)
    – GlennG
    Commented Dec 14, 2012 at 17:25
  • I think so, which is why we elected not to fix it (we have a requirement in our app to support IE6/7 still). I think it is acceptable, provided the CBC-based cipher is prioritised such that it will not be chosen over an RC4 implementation -- blogs.msdn.com/b/kaushal/archive/2011/10/03/… has some more details Commented Dec 14, 2012 at 18:25
  • How does one disable CBC 'mode' on IIS6?
    – GlennG
    Commented Dec 17, 2012 at 8:54
  • 1
    For info, TrustWave subsequently mis-scanned our site, wrongly claiming that we're running Windows 2003 SP1 (we're not, it's fully patched). Had a minor hassle to get that finding revoked. All of which proves that TrustWave scans aren't infalible.
    – GlennG
    Commented May 9, 2013 at 13:50

3 Answers 3


How does one disable CBC 'mode' on IIS6?

You disable all ciphers that have CBC in their name. http://support.microsoft.com/default.aspx?scid=kb;EN-US;245030 describes how; https://www.nartac.com/Products/IISCrypto/Default.aspx provides a tool to do it for you.

Also, from that second website:

Note - Windows Server 2003 does not support the reordering of SSL cipher suites offered by IIS. However, you can still disable weak protocols and ciphers. Also, Windows Server 2003 does not come with the AES cipher suite. Microsoft has a hotfix for this.

This means you really only have two choices:

  1. Upgrade your operating system to Windows Server 2008, which I infer as being fully supported by the Nartac tool and is the last 32-bit version of Windows Server, so shouldn't require updating your application too much (although you really should)

  2. Disable all CBC-named ciphers to pass your PCI check (and then re-enable them once it is done, albeit it is on your own head if you ever get caught).

Did I say that out loud?

  • To say I'm a little nervous about installing a 3rd party tool on a production server is somewhat of an understatement! I think I need to install this on a VM, find out what the registry changes are, then implement these on the live servers.
    – GlennG
    Commented Dec 17, 2012 at 12:43

If you are using TLS 1.0 with a CBC-based ciphersuite, you are potentially vulnerable to the BEAST attack. Cryptographically the TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite is still fine and in TLS 1.1 and TLS 1.2 you will have no issues. Protocol-wise with HTTPS it is not so fine with regards to BEAST in TLS 1.0.

(although the AES-based ciphersuites are preferred by the RFC, NIST and the NSA).

The only true mitigation with TLS 1.0 is putting the RC4 ciphersuites higher in the priority list. As a result clients that don't support RC4 ciphersuites can still connect, but are indeed vulnerable to the BEAST attack.

The only true mitigation is moving to clients and servers that support TLS 1.1 or TLS 1.2. By putting TLS 1.2 suites up front you guarantee that newer client are still able to get more secure ciphersuites than the RC4 ones.

SSLHonorCipherOrder On
  • Alas we're running W2k3 with IIS6 which doesn't support TLS1.1 or TLS1.2. It's out of the question to upgrade the server and all applications just for a theoretical risk.
    – GlennG
    Commented Dec 15, 2012 at 18:20
  • GlennG, The BEAST attack is not a theoretical risk. The issue is with CBC ciphersuites under TLS 1.0 and is definitely a vulnerability. Putting the RC4 ciphersuites first in the order helps most clients.. And the TLS_RSA_WITH_3DES_EDE_CBC_SHA is then for clients not supporting RC4 ciphersuites. Solves the problem for almost all clients, still gives a warning on the SSL Labs check of course..
    – Paul
    Commented Dec 16, 2012 at 16:07
  • I'm sure that BEAST is feasible for very large-scale sites with large amounts of e-commerce, but for a small site with a few transactions, it's just not worth the effort to attack the protocol; much better to simply attack the server. The problem is that it's weeks or months of work for us to port our code to the latest version of ASP.NET/IIS which will cost $+++; this will need to be planned for and not done reactively.
    – GlennG
    Commented Dec 17, 2012 at 8:50
  • 1
    I agree that depending on the situation it's not worth the effort :)
    – Paul
    Commented Dec 17, 2012 at 11:25
  • 1
    This challenge is really highlighting the need to split transport security from the application server, through the use of a proxy server, preferably a non-Windows one!
    – GlennG
    Commented Dec 17, 2012 at 12:46

Cipher suites which are potentially vulnerable to BEAST are those which use block ciphers in CBC mode (e.g. TLS_RSA_WITH_3DES_EDE_CBC_SHA). Moreover, the cipher suite selection system in SSL works like this:

  • The client sends the list of cipher suites that it is willing to support.
  • The server selects one cipher suite in that list, that it also supports.

The list sent by the client is ordered by preference: the first suite in the list is the one which the client wishes most to use. A courteous server should honour the client's preferences. IIS6 appears to be "courteous" and this cannot be changed.

BEAST is a client attack; when we say that a server is vulnerable to BEAST, we actually mean that the server has the opportunity to protect the client, and yet does not do it. Namely, the "vulnerability" occurs when:

  • The protocol version is SSL 3.0 or TLS 1.0 (TLS 1.1+ is inherently immune to BEAST-like exploits).
  • The client advertises only cipher suites which uses CBC; or, more often, the client advertises some CBC cipher suites first (in order of preference), with RC4-based suites coming only after, and the server does not enforce use of RC4 (i.e. the server is too courteous).

In practice, BEAST requires a rather complex attack framework, and, moreover, needs to exploit a Same Origin Policy hole in the browser. No flexible enough SOP hole is known at the moment (the BEAST demo used two holes, in Javascript WebSockets and in Java, and both have been plugged since), so the threat is only potential. No need to unduly worry. You need to fix the BEAST thing for compliance, not for actual security.

Since IIS6 cannot be uncourteous, you have to disable the CBC-based cipher suites altogether. See @jimbobmcgee's answer for pointers. This has the side effect of refusing to talk to clients who know only of CBC-based cipher suites, but browsers which cannot do RC4 are extremely rare.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .