Control SSL Cipher Priority/Order for Tomcat to avoid BEAST attack

I have the same issue. It seems that we can't do what we want.
The Sun(Oracle) Java SSL implementation checks only the client side cipher suite order(priorities) and ignores the server side.

Related classes are:
sun.security.ssl.ServerHandshaker
sun.security.ssl.CipherSuite

On ServerHandshaker,
"private void chooseCipherSuite(ClientHello mesg)"
http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-sun/security/sun/security/ssl/ServerHandshaker.java.htm

/*
 * Choose cipher suite from among those supported by client. Sets
 * the cipherSuite and keyExchange variables.
 */
private void chooseCipherSuite(ClientHello mesg) throws IOException {
    for (CipherSuite suite : mesg.getCipherSuites().collection()) {
        if (isEnabled(suite) == false) {
            continue;
        }
        if (doClientAuth == SSLEngineImpl.clauth_required) {
            if ((suite.keyExchange == K_DH_ANON) || (suite.keyExchange == K_ECDH_ANON)) {
                continue;
            }
        }
        if (trySetCipherSuite(suite) == false) {
            continue;
        }
        return;
    }
    fatalSE(Alerts.alert_handshake_failure,
                "no cipher suites in common");
}

We can see that it itelates cipher suites in the client hello message and chooses cipher suite.

For native/APR/OpenSSL connectors

As of Tomcat 6.0.37/7.0.30/8.0.x, the native/APR/OpenSSL-based connector supports the SSLHonorCipherOrder configuration setting which allows the server to have a specified order in which ciphers are chosen. That ordering is up to you and isn't based upon fuzzy definitions like "strength", since a high-bit cipher can be worse than a lower-bit cipher in certain situations.

For Java-based connectors (BIO, NIO, NIO2)

Tomcat 8.0.21 and later on Java 8 and later will use the server's preferred cipher-suite order if useServerCipherSuitesOrder is set to "true" (the default) for Java-based connectors.

Tomcat 7.0.60 and later on Java 8 and later will use the server's preferred cipher-suite order if useServerCipherSuitesOrder is set to "true" (the default) for Java-based connectors.

Tomcat 6 never had this capability for Java-based connectors; server-preferred ordering of cipher suites on Tomcat 6 will require the use of the APR/native connector.

During handshake the client sends the prefered cipher suites and the server chooses the strongest that both can support.
I am not sure what ordering you expect.

Also SSL Labs indicates that my site does not show a cipher preference, whereas google.com does

I can not understand what you mean here.
What exactly is the complaint? That from the enabled ciphers, Tomcat chose a less week than it supposed to?

I don't believe you can order them by preference and once you get rid of the CBC ones, there's an awfully short list of cipher options available! However, most clients are going to connect at RC4-128 any way--at least that's what all my server logs indicate when I feel like turning that logging option on.

Using the OpenSSL connector, you get the option of using a more concise syntax for allowing or disallowing certain ciphers but no options for setting cipher order or even preferred cipher.