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

ssltomcat

With the recent buzz about the SSL BEAST vulnerability I wanted to try to improve the security of an SSL protected web site that is based on Tomcat 6. To that end, I tried the google approach of giving non Cipher Block Chaining (CBC) ciphers priority in my Tomcat server.xml file in the HTTP connector declaration:

ciphers="TLS_ECDHE_RSA_WITH_RC4_128_SHA,
         TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,
         TLS_ECDH_RSA_WITH_RC4_128_SHA,
         TLS_ECDH_ECDSA_WITH_RC4_128_SHA,
         TLS_RSA_WITH_RC4_128_SHA,
         TLS_RSA_WITH_RC4_128_MD5,
         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
         TLS_RSA_WITH_AES_256_CBC_SHA,
         TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
         TLS_RSA_WITH_3DES_EDE_CBC_SHA,
         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
         TLS_RSA_WITH_AES_128_CBC_SHA"

But Tomcat does not appear to use the order of the ciphers, but instead seems to select the best cipher based on key strength. Also SSL Labs indicates that my site does not show a cipher preference, whereas google.com does. I do not want to remove the 256 bit CBC ciphers in order to use the 128 bit RC4 cipher for fear of SSL incompatibilities. I am guessing that the cipher selection is done at the Java JSSE layer and not in Tomcat.

Does anyone know of a simple way to customize the priority/order of the SSL ciphers with the standard Tomcat HTTP connector? Is there a way to achieve this using a simple custom java class? Does the Tomcat APR connector and some openSSL configuration option offer an alternative. Is there some other simple way to do this?

Note that I realize that this attack requires cross site scripting or some other similar vulnerability, and so is not that serious (for my site). However, if there are easy steps to mitigate this attack, I will take them. Also, I do not want to introduce an Apache front end (assuming there is a way to do this in Apache) because of the extra complexity and therefor risk.

Best Answer

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.

Related Topic