I'd like to test a server specifically for vulnerabilities related to BEAST. What command line switches should I use?
What should I see (or not see) in the output?
Update
The intent is to scan a non-Internet connected web server, or to scan a server that is running on a non-default port. In all other cases I could use SSL Scan for this task
I have written a command-line tool called TestSSLServer which can be used for that job.
The tool makes a lot of aborted handshakes with the server (it sends the ClientHello and receives the ServerHello; then it closes the connection). First, it establishes the list of cipher suites supported by the server, by sending a full list of many suites, then removing one by one the suite that the server selects each time.
Then the tool sends another ClientHello, with maximum TLS version 1.0, and CBC-based cipher suites first, followed by non-CBC-based ones (suites taken among the "strong" suites that the server supports). If the server selects a non-CBC-based cipher suite, then it is deemed "protected" (the server enforces a choice which protects the client); if it selects a CBC cipher suite, then the tool reports "vulnerable" (there again, vulnerability is on the client side, but the server fails to enforce protection on the client).
Background. To learn more about how to mitigate the BEAST attack, I recommend reading the following two blog posts: Rizzo/Duong BEAST Countermeasures and Mitigating the BEAST attack on TLS. You'll quickly learn that there are no really great solutions.
What to scan for. Right now, the only known server-side mitigation is for the server to force use of RC4 by refusing to accept any other ciphersuite. A similar variation is to place the RC4 ciphersuite as the highest preference; this is almost as safe, as it ensures that any client which supports RC4 will use RC4.
Thus, when you scan a SSL server, if the server prioritizes any block cipher based ciphersuite higher the RC4 ciphersuites, then it can be considered vulnerable to the BEAST attack. If all the ciphersuites it accepts use RC4 (or if the RC4 ciphersuites are prioritized before any block cipher ciphersuite, except for TLS 1.2-only ciphersuites), it is probably safe from the BEAST attack.
Determining the server's priorities on ciphersuites can be tricky, and may require multiple connections to the server with a different set of ciphersuites each time. However, in this case one simple method may be to have your client connect with a list of ciphersuites that starts with all of the (non-TLS-1.2-only) block cipher suites, and then end with some RC4 ciphersuites. If the server picks any block cipher ciphersuite, then the server is probably vulnerable to the BEAST attack.
Ideally, the server would support TLS 1.1 or higher. If both the client and the server support TLS 1.1, then the BEAST attack becomes much harder (it requires a man-in-the-middle attack). Therefore, if the server doesn't support TLS 1.1, you might want to output a warning/advisory suggesting that the server admin upgrade to provide TLS 1.1 support. However, apparently supporting TLS 1.1 on both endpoints is not an absolute guarantee of security, due to the possibility of downgrade attacks if a man-in-the-middle is present, so I would suggest listing this merely as a warning/advisory, rather than a critical failure.
More on SSL server scanning. You might want to consider using the SSL Labs service for scanning a SSL server. It is a great way to test for many possible configuration vulnerabilities. It will also test whether the server is vulnerable to the BEAST attack, but it will check for many other common and serious problems as well -- which is probably more useful than just looking for the BEAST problem.
this is based on some online searches alone, with no detailed anlaysis, but from what I gather, it's more of a client-side vulnerability than a server one. Of course the vulnerability is when the communication between client and server is attacked, but the fix should be primarily on the client. The primary reason, as I understand it, is because the client selects its preferred ciphers and sends an ordered list to the server to 'choose' from. The server should generally accept the client request (but it doesn't have to). That's my limited understanding of the handshake from this SO answer
With that in mind, there are some server workarounds that seem to be effective. One of which is avoiding block ciphers that use CBC, and e.g. use RC4 as an alternative. This can be enforced by the server. Of course using TLS 1.1+ would also solve the issue, but from what I understand it's not widely supported. According to wikipedia article on RC4
RC4, being a stream cipher, is the only common cipher which is immune[6] to the 2011 BEAST attack
([6] linking to serverfault :)
To go back to the specifics of your question. I guess the logical thing is check which ciphers the server supports, and if it does support TLS 1.0 + one of the block ciphers with CBC which are vulnerable to BEAST then you could say the server is vulnerable to BEAST. Looks like it might be easier to use sslscan rather than openssl to list all the server supported ciphers and from that discover vulnerable servers.
