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:
- 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)
- 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.
- 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
- 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.
- 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:
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] "Enabled"=false [\AES 256/256] "Enabled"=false [\DES 56/56] "Enabled"=false [\NULL] "Enabled"=false [\RC2 128/128] "Enabled"=false [\RC2 40/128] "Enabled"=false [\RC2 56/128] "Enabled"=false [\RC4 128/128] "Enabled"=true [\RC4 40/128] "Enabled"=false [\RC4 56/128] "Enabled"=false [\RC4 64/128] "Enabled"=false [\Triple DES 168/168] "Enabled"=true