Tools to test for BEAST/CRIME that AREN'T Internet-based?

Question

We have increasing pressure to identify and remediate any HTTPS server configurations that are vulnerable to BEAST (CBC) and CRIME (compression). We need to fix servers that are accessible to the Internet at large, servers that are only accessible to limited partner IP addresses via the Internet, and servers that are internal.

Servers available to the Internet at large can be scanned using Qualys' SSL Labs web service. It gives clear indication of BEAST vulnerability, and presumably the "Compression" setting that isn't a bad sign today relates to CRIME and will start triggering an alert in the near future. However, this does not help with sites that aren't generally available via the Internet.

I can find all sorts of information on how to test things by hand - for example, discussion of ciphers for BEAST and openssl s_client recipes for testing compression. However, in my old age I'm getting more fond of tools - like SSL Labs - that just tell me, rather than having to decipher the various openssl cipher strings ("No CBC, unless it's TLS 1.1+, in which case CBC is okay, and don't forget Tuesday").

I also am leary that I'm unable to get a result indicating compression using various openssl + hand-coded HTTP headers on a web server that SSL Labs says has compression enabled. Who do I believe? I'm inclined to trust tools more than recipes, because tools are generally built upon a recipe that's then tested in a wide variety of setups and fixed, whereas recipes often worked for someone, somewhere, somewhen.

So what I'm looking for is a command-line tool like sslscan which I can run against all my servers, regardless of their availability to the Internet at large. (Yes, I realize sslscan prints out the ciphers, which I can interpret to determine BEAST vulnerability - but I want an expert (or just knowledgeable!) system which is less fallible than I am to look at that output and make the call).

Answer 1

Edit (2012/09/23): Ask and ye shall receive. TestSSLServer is a simple command-line tool which I wrote this week-end; it obtains from a given SSL/TLS server the list of supported cipher suites, protocol versions and support of TLS-level Deflate. It then gives a summary of the encryption strength and the vulnerability to BEAST and CRIME attacks. It is written in Java and should work "everywhere" (I only tested it from a Linux/ppc client, though).

(Note that BEAST and CRIME target the client, not the server. We are talking here about steps which the server can take to "protect" the client by not allowing it to use vulnerable feature combinations.)

---

Original response:

For compression, there are two places where it may be activated; the blog post you link to talks about the wrong place, the one the CRIME attack is not about.

CRIME uses the compression which is at the SSL/TLS-level: a compression negotiated during the handshake, and which applies to every byte which is sent within the SSL/TLS tunnel. In a HTTPS context, this compression operates on both the HTTP request/response bodies and the HTTP headers (including the cookies, which is the point of CRIME). The compression which occurs at the HTTP level is the one which is specified with HTTP headers (like "Accept-Encoding") and which applies to the request/response bodies only. That compression does not cover the cookies (which are in the headers) and is thus, presumably, CRIME-free.

(This does not preclude the theoretical existence of a CRIME-like attack which abuses HTTP-level compression on the bodies, but it would require a request or response body which contains both confidential data, and data which the attacker can choose.)

To test a server for compression support, use this:

openssl s_client -connect www.theservername.com:443

This will produce some output which contains the server's certificate, and ends with a block of text which looks like this:

---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 4B4110C44117BA0382CA6C3903A8185E0C156B253073E66B2D44F04B83611633
    Session-ID-ctx: 
    Master-Key: C11D38EE064BE6549364D54BD60E216E367A52825E62FFCCBEFC4AC8DB97D07BD72B7355CB268B91E3AD176EB69446AA
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 4c f8 be c1 d1 0f cf 03-4a 99 89 8b 75 28 97 3c   L.......J...u(.<
    0010 - 3e cf 2a b8 0f f0 d1 b4-7d c7 83 16 03 2c f0 8a   >.*.....}....,..
    0020 - 1b a7 57 be dd 1b be a3-14 eb cf 34 42 99 e0 5a   ..W........4B..Z
    0030 - c5 96 43 da c7 d9 dd da-ed 4c e2 7c eb c1 8b a8   ..C......L.|....
    0040 - ce 73 c8 22 43 10 88 d6-d2 f2 df 91 9d 47 71 70   .s."C........Gqp
    0050 - 77 bb c0 55 cd 46 34 3b-44 26 36 a1 7f 37 64 cd   w..U.F4;D&6..7d.
    0060 - 72 64 66 89 cc f6 8b 23-17 9b 9a 91 23 6a f7 c2   rdf....#....#j..
    0070 - 8a e2 8c 10 85 8f b7 6c-60 d2 b6 72 b3 13 98 8b   .......l`..r....
    0080 - 75 da 68 cc 2a ca 4f fb-ec 4c f2 db 91 4a f7 2a   u.h.*.O..L...J.*
    0090 - 40 eb 92 44 c7 7a f7 84-ef 65 ea 2c 96 aa c5 ba   @..D.z...e.,....
    00a0 - c3 b5 76 6d 52 03 85 c9-27 53 a2 a4 70 54 06 37   ..vmR...'S..pT.7
    00b0 - 82 3e 09 93 21 6d f6 e7-eb cf c3 5e 26 19 e1 a2   .>..!m.....^&...

    Compression: 1 (zlib compression)
    Start Time: 1348073749
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---

This was done on a server which supports TLS-level compression. You see "zlib compression" in three places: Deflate compression is indeed supported by this server. Note that there is not a single sign of a HTTP header anywhere ! Just type the openssl command, and look at the output. No need to enter a HTTP header.

On a server which does NOT support TLS-level compression, things will look like this:

---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : ECDHE-RSA-RC4-SHA
    Session-ID: 59D609F13BEE9157D26318ADB12F4CF219EF7A1BC2C87AF84AD66773303F90A6
    Session-ID-ctx: 
    Master-Key: 1DD9E0C306A86A7EC823561EF0B1F47B63E70B43D57F3B3FBB3D389863F540E3B4CCE5DE454E6D19811C24001E95777A
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    0000 - de c6 06 25 10 c9 22 38-c4 1f 82 d7 c7 b5 62 08   ...%.."8......b.
    0010 - 01 c0 e1 26 e2 64 8a 62-99 74 85 bb 60 bf a8 e0   ...&.d.b.t..`...
    0020 - 65 08 74 89 d5 62 45 e9-b4 f0 80 4e f7 bd ff d5   e.t..bE....N....
    0030 - 6a 12 3b 90 97 ca 7a f4-d1 1b e1 0d 89 d2 52 49   j.;...z.......RI
    0040 - 11 fe 92 82 94 70 ba 4b-5e 81 ff f2 12 62 f4 79   .....p.K^....b.y
    0050 - 11 eb 74 7a d6 ee 10 4e-b5 6d 50 8d 1c 1c 8e 57   ..tz...N.mP....W
    0060 - 19 46 67 91 89 2e 45 28-2e 49 94 8e c8 32 28 bf   .Fg...E(.I...2(.
    0070 - 7b 73 82 ab 63 c4 b7 8f-5c b3 1b 5c 74 59 3c 8d   {s..c...\..\tY<.
    0080 - ec 8a 6a 3a 28 c2 82 c1-d7 d5 4f ec 7e 79 e7 57   ..j:(.....O.~y.W
    0090 - 4a f9 45 e7                                       J.E.

    Start Time: 1348074257
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---

The "Compression: NONE" shows that this second server indeed rejects usage of TLS-level compression.

Note also that the first server chose DHE-RSA-AES256-SHA as cipher suite, i.e. a suite which uses the block cipher AES in CBC mode. This first server is then potentially vulnerable to both BEAST and CRIME. The second server selected ECDHE-RSA-RC4-SHA, which is BEAST-immune.

(First server is mine; since I do not use cookies at all on it, I am not nervous about cookie-stealing attacks. Second server is www.google.com.)

If I find the time, I will write a tool which gives such results more easily. There is no need to do a full SSL/TLS handshake, only to send a ClientHello et look at the ServerHello which comes back.