BEAST: IIS6: Failing PCI scan - are these ciphers OK?

Question

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:

Protocols:
 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?

Answer 1

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?

Answer 2

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
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

Answer 3

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.