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
–
jimbobmcgeeDec 14 '12 at 18:25

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:

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)

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).

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.
–
GlennGDec 17 '12 at 12:43

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.

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.

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.
–
GlennGDec 15 '12 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..
–
PaulDec 16 '12 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.
–
GlennGDec 17 '12 at 8:50

1

I agree that depending on the situation it's not worth the effort :)
–
PaulDec 17 '12 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!
–
GlennGDec 17 '12 at 12:46