Our server failed the last PCI scan. The description of the problem is below my questions. Windows Server 2008 According to Qualys Security Labs one method to correct this to change the priority of the cipher suite, putting RC4 at the top of the list. Is this information correct? To change the order of the Cipher do I do this in group policy? I believe I have to disable SSL2 also. (I think I did that but I will have to reboot and retest to verify) Thanks Mitigating the BEAST attack on TLS https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls This fixes the clients? MS12-006: Vulnerability in SSL/TLS could allow information disclosure: January 10, 2012 Security Warning found on port/service "smtp (25/tcp)" Security Warning found on port/service "https (443/tcp)" Status Fail (This must be resolved for your device to be compliant). Plugin "SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability" Category "General " Priority "Medium Priority Synopsis It may be possible to obtain sensitive information from the remote host with SSL/TLS-enabled services. Description A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow information disclosure if an attacker intercepts encrypted traffic served from an affected system. TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected. This script tries to establish an SSL/TLS remote connection using an affected SSL version and cipher suite, and then solicits return data. If returned application data is not fragmented with an empty or one-byte record, it is likely vulnerable. OpenSSL uses empty fragments as a countermeasure unless the 'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is initialized. Microsoft implemented one-byte fragments as a countermeasure, and the setting can be controlled via the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHAN NEL\SendExtraRecord. Therefore, if multiple applications use the same SSL/TLS implementation, some may be vulnerable while others may not, depending on whether or not a countermeasure has been enabled. Note that this script detects the vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It does not detect the BEAST attack where it exploits the vulnerability at HTTPS client-side (i.e., Internet browser). The detection at server-side does not necessarily mean your server is vulnerable to the BEAST attack because the attack exploits the vulnerability at client-side, and both SSL/TLS clients and servers can independently employ the split record countermeasure. ee also: http://www.openssl.org/~bodo/tls-cbc.txt http://vnhacker.blogspot.com/2011/09/beast.html http://technet.microsoft.com/en-us/security/bulletin/ms12-006 http://support.microsoft.com/kb/2643584 http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the- Risk factor Medium / CVSS Base Score : 4.3 (CVSS2#AV:N/AC:M/Au:N/C:P/I:N/A:N) CVSS Temporal Score : 3.6 (CVSS2#E:F/RL:OF/RC:C) Public Exploit Available : true Plugin output Negotiated cipher suite: AES128-SHA|TLSv1|Kx=RSA|Au=RSA|Enc=AES(128)|Mac=SHA1 CVE: CVE-2011-3389 Addition Information Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure SSL/TLS servers to only support cipher suites that do not use block ciphers. Apply patches if available. Note that additional configuration may be required after the installation of the MS12-006 security update in order to enable the split-record countermeasure. See also: http://support.microsoft.com/kb/2643584 for details.

Hello, Thank you for your post. This is a quick note to let you know that we are performing research on this issue. Best Regards Elytis Cheng Elytis Cheng TechNet Community Support

Hi, I have a same problem, and change the register value SendExtraRecord at 1, and vulnerability is gone but the aplication that use sql server is no func, when change the register value in 2 or 0 the vulnerability reappears

MS12-006 implements a new behavior in SCHANNEL.DLL, causing it to send an extra record if SSL 3.0 or TLS 1.0 are specified and the cipher suite uses Cipher Block Chaining (CBC). The client must request this behavior. A recent IE update (MS11-099) ensures that Internet Explorer will request this behavior. The problem arises that not all SSL/TLS implementation support this additional record, so you may experience problems. Most commonly, you will find Internet Explorer 9.0 display an "Internet Explorer cannot display the webpage" error. Earlier version of IE may simply display a blank page. KB2643584<http://support.microsoft.com/kb/2643584> covers the workarounds: 1. Client-Side: Force IE to use TLS 1.1 or TLS 1.2. Be careful with non-Windows servers with this solution. OpenSSL, for example, does not yet support TLS 1.1 or TLS 1.2 in the distribution build. Support has been added to the current development build, so vendors that leverage the OpenSSL library may start to include support. How do you detect if an application uses the OpenSSL library? In the application directory, look for the file ssleay32.dll. This is the OpenSSL library. 2. Server-side: Disable SSL 3.0 and TLS 1.0 in the registry on the server. 3. Modify the SendExtraRecord registry value to effectively disable the update. Please review the article for all the details and caveats about this workaround.Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

No, I don't think that is going to help me. I had already tried to fix the server using the fix posted at http://support.microsoft.com/kb/2643584 MicrosoftFixit50774.msi Message This Microsoft Fix does not apply to your operating system or application version. Please correct me if I'm wrong, but my understanding is Windows server 2008 (not R2) does not support TLS1.1 or TLS1.2. Refering to MS12-006: Changing the SendExtraRecord is not recomended. I'll give it a try to see what breaks. Note: After putting RC4 at the to of the list of ciphers our server passed the scan for the BEAST issuem, but it is still failing the PCI scan with this error message. (Qualys SSL Labs, Grade A88 - BEAST attack Not vulnerable ) Status Fail (This must be resolved for your device to be compliant). Plugin "SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability" Category "General " Priority "Medium Priority Synopsis It may be possible to obtain sensitive information from the remote host with SSL/TLS-enabled services. Description A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow information disclosure if an attacker intercepts encrypted traffic served from an affected system. TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected. This script tries to establish an SSL/TLS remote connection using an affected SSL version and cipher suite, and then solicits return data. If returned application data is not fragmented with an empty or one-byte record, it is likely vulnerable. OpenSSL uses empty fragments as a countermeasure unless the 'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is initialized. Microsoft implemented one-byte fragments as a countermeasure, and the setting can be controlled via the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHAN NEL\SendExtraRecord. Therefore, if multiple applications use the same SSL/TLS implementation, some may be vulnerable while others may not, depending on whether or not a countermeasure has been enabled. Note that this script detects the vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It does not detect the BEAST attack where it exploits the vulnerability at HTTPS client-side (i.e., Internet browser). The detection at server-side does not necessarily mean your server is vulnerable to the BEAST attack because the attack exploits the vulnerability at client-side, and both SSL/TLS clients and servers can independently employ the split record countermeasure. Thanks

Just to muddy the water a little more... Comodo added this item to their list on 18 April 2012 and it failed at the next scan in May.. We tested with Qualyss and it failed on the beast attack vunerability. Using the tool from Nartac https://www.nartac.com/Products/IISCrypto/Default.aspx We rearranged the cypher order (make sure ALL the cyphers you want are checked, not just the one you want to move up the list, it removes all unchecked ones) Checked it again with Qualyss and it passed. Ran the Hacker Guardian scan and it passed. All was good... Just run the scan again with hacker guardian and it failed, but is still passing with Qualyss.. Qui me amat, amet et canem meum

Yesterday I received this response from Comodo This vulnerability is causing a lot of problems. This afternoon I got a follow up. Originally this was reported as a false positive and rejected. I have resubmitted the report.. Watch this space Without writing a treatise on cryptographic flaws, the short answer to how we're handling this vulnerability is as follows: You can report the fact that you've configured your server to prefer non-CBC cipher suites (as you have below as a compensating control via the 'Report as False Positive' links in the vulnerability report within the scanning interface and we'll evaluate the report and pass the server if it's satisfactory. Qui me amat, amet et canem meum

In short the answer seems to be... 1. Remove SSL 2.0 2. Arrange the cypher suite to prefer non-CBC cyphers Scan the server - you will get a fail on this. Submit a false positive report stating that 1. SSL 2.0 has been disabled 2. The cypher suite is arranged to prefer non-CBC cyphers The only way that the scan will pass is if all CBC cipher suites are disabled - but only very current IE and Opera browsers will be able to gain access, so they will accept a preference of RC4 as a compensating control for now. Qui me amat, amet et canem meum

Submit a false positive report stating that 1. SSL 2.0 has been disabled 2. The cypher suite is arranged to prefer non-CBC cyphers Actually, it is NOT a false positive, because the attacker will not use the prefered cipher, but will force the server to use the vulnerable cipher instead, obviously... I think that disabling the m12-006 workaround and ONLY allow strong RC4 ciphers might solve the problem and will be compatible with almost evrything. To disable the m12-006 workaround on windows 2008, 2003, XP, Vista change the value of the following registry key to 2. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendExtraRecord referece: http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspx