I'm at my wits end with this one! I am not a CI/networking person to begin with, and so I apologize if I am asking the wrong question/giving the wrong information.

I am working on trying to get a client site to pass its Trustwave security scan so that it can continue to accept credit cards. Here is the timeline of events so far:

  1. 2 weeks ago I was contacted to rectify the problem in our clients site scan. The scan said that we were failing on 3 items due to the BEAST vulnerability (CVE-2011-3389)
  2. The site is on Windows Azure and was on a very early guest OS, so I upgraded the guest OS to 3.2 on Windows Server 2012. According to the National Vulnerability Database, this vulnerability is discussed in Microsoft Security Bulletin MS12-006, which was addressed in version Azure Guest OS 1.18/ 2.1.
  3. The scan continued to fail on the same 3 items, even though according to MS' documentation, Windows Server 2012/IIS8 are not effected by this vulnerability
  4. I then downloaded the tool IISCrypto and applied the BEAST settings, and restarted. This got me down to only 1 reported vulnerability - (Client Provided Options 'TLSv1 : ALL:eNULL:aNULL' ; Server Negotiated Block Cipher 'TLSv1 : AES128-SHA'). Just from what I think I know about this, it doesn't make any sense since the RC4 ciphers were all first. As a side note, SSL Labs online scanner reported that our site no longer was vulnerable to BEAST.
  5. I then went for scorched earth and deactivated all CBC ciphers leaving only RC4 in an attempt to force it no matter what to negotiate with the RC4 cipher. The scan still fails on the same vulnerability, however SSL labs still reports our site is fine.

I really want to test this myself, however as I said, this isn't my real job - I am a developer, and while I want to learn a lot about CI, I don't have the time today! What I have done so far is used my openssl instance to attempt the query as I think Trustwave is presenting it to see if I can recreate their evidence:

openssl s_client -connect thenewtonproject.com:443 -cipher "TLSv1:ALL:eNULL:aNULL"

When I run this, I see that it says TLSv1/SSLv3. Cipher is RC4-SHA, which would lead me to believe that the Trustwave scan is wrong, but since this is the first time I've ever done anything like this with openssl, I am not even sure I've used the right command/syntax. Can someone either help to correct my syntax/verify my result against the same site?


According to Trustwave, the description of the BEAST problem is:

The SSL protocol encrypts data by using CBC mode with chained initialization vectors. This allows an attacker, which is has gotten access to an HTTPS session via man-in-the-middle (MITM) attacks or other means, to obtain plain text HTTP headers via a blockwise chosen-boundary attack (BCBA) in conjunction with Javascript code that uses the HTML5 WebSocket API, the Java URLConnection API, or the Silverlight WebClient API. This vulnerability is more commonly referred to as Browser Exploit Against SSL/TLS or "BEAST".

According to Trustwave, the steps for remediation are:

Affected users should disable all block-based cipher suites in the server's SSL configuration and only support RC4 ciphers, which are not vulnerable to fully address this vulnerability. This vulnerability was addressed in TLS version 1.1/1.2, however, support for these newer TLS versions is not widely supported at the time of this writing, making it difficult to disable earlier versions. Additionally, affected users can also configure SSL to prefer RC4 ciphers over block-based ciphers to limit, but not eliminate, exposure. Affected users that implement prioritization techniques for mitigation as described above should appeal this vulnerability and include details of the SSL configuration.

I received the information in regards to the IISCrypto tool from just generic Googling this past week.

EDIT 2: Per request, here is what the ciphers looks like in the registry:

[\AES 128/128]
[\AES 256/256]
[\DES 56/56]
[\RC2 128/128]
[\RC2 40/128]
[\RC2 56/128]
[\RC4 128/128]
[\RC4 40/128]
[\RC4 56/128]
[\RC4 64/128]
[\Triple DES 168/168]
  • Is there any explanation available about what the vulnerability is? Are you not supposed to allow AES128? Are you not supposed to allow SHA? – David Schwartz Apr 8 '13 at 20:23
  • @tostringtheory: Instead of stating "I download tool x and applied y", why don't you just document what the enabled/disabled Ciphers settings are? It's a few lines in the registry. – Greg Askew Apr 8 '13 at 20:38
  • @GregAskew: As I said before, I am not a CI/networking person, and don't know where to begin to look for those settings. If you'd point me to an article, or better yet a regkey I'd be happy to give you that info. However, the tool IISCrypto appears to be a widely used and respected tool from the information I read before downloading it, and since the BEAST settings are a preset within the program, I figured that that was enough to convey. I am still also looking for information regarding whether or not my openssl command was correct. – tostringtheory Apr 8 '13 at 21:20
  • @tostringtheory: The ciphers are in the registry, at: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\ – Greg Askew Apr 8 '13 at 21:39
  • As a note, I don't particularly like only the RC4 ciphers on because I am worried about compatibility and security situations, however, this was my last attempt to get the issue resolved, since one of the solution steps is to disable all block ciphers to fix the issue. – tostringtheory Apr 8 '13 at 22:24

This was originally answered here:

I applied this and it works:

it was answered by https://security.stackexchange.com/users/12375/josh https://security.stackexchange.com/questions/14326/how-to-fix-ssl-2-0-and-beast-on-iis

Let me know if it worked

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.