Controle Prioridade de Codificação SSL / Pedido para o Tomcat para evitar ataque BEAST

Question

Com o recente burburinho sobre a vulnerabilidade ANIMAIS do SSL, eu queria tentar melhorar o segurança de um site protegido por SSL baseado no Tomcat 6. Para esse fim, eu tentei a abordagem google de dar prioridade a cifras Cipher Block Chaining (CBC) no meu arquivo Tomcat server.xml no Declaração do conector HTTP:

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"

Mas o Tomcat parece não usar a ordem das cifras, mas, em vez disso, parece selecionar a melhor cifra baseada na força-chave. Também o SSL Labs indica que o meu site não mostra uma preferência de cifra, enquanto o google.com sim. Eu não quero remover as cifras CBC de 256 bits para usar a codificação RC4 de 128 bits por medo de incompatibilidades de SSL. Eu estou supondo que a seleção de cifra é feita na camada Java JSSE e não no Tomcat.

Alguém sabe de uma maneira simples de personalizar a prioridade / ordem das cifras SSL com o conector HTTP padrão do Tomcat? Existe uma maneira de conseguir isso usando uma classe java personalizada simples? O conector APR do Tomcat e algumas opções de configuração do openSSL oferecem uma alternativa. Existe alguma outra maneira simples de fazer isso?

Note que percebo que esse ataque exige scripts entre sites ou alguma outra vulnerabilidade semelhante e, portanto, não é tão grave (para o meu site). No entanto, se houver passos fáceis para mitigar esse ataque, eu os aceitarei. Além disso, não quero introduzir um front end do Apache (supondo que haja uma maneira de fazer isso no Apache) devido à complexidade extra e, portanto, ao risco.

    

Answer 1

Eu tenho o mesmo problema. Parece que não podemos fazer o que queremos.
A implementação Java do Java da Sun (Oracle) verifica apenas a ordem do conjunto de cifras do lado do cliente (prioridades) e ignora o lado do servidor.

Classes relacionadas são:
sun.security.ssl.ServerHandshaker
sun.security.ssl.CipherSuite

No ServerHandshaker,
"private void chooseCipherSuite (ClientHello mesg)"
link

/*
 * 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");
}

Podemos ver que ele integra os conjuntos de criptografia na mensagem de saudação do cliente e escolhe o pacote de criptografia.

    

Answer 2

Durante o handshake, o cliente envia os pacotes de criptografia preferidos e o servidor escolhe o mais strong que ambos podem suportar.
Não sei o que você espera.

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

Eu não consigo entender o que você quer dizer aqui.
O que exatamente é a reclamação? Que das cifras ativadas, o Tomcat escolheu uma semana a menos do que deveria?

    

Answer 3

Eu não acredito que você possa encomendá-los de preferência e assim que você se livrar dos CBCs, há uma lista muito pequena de opções de cifra disponíveis! No entanto, a maioria dos clientes vai se conectar no RC4-128 de qualquer forma - pelo menos é o que todos os meus logs de servidor indicam quando eu sinto como ativar essa opção de logging.

Usando o conector OpenSSL, você tem a opção de usar uma sintaxe mais concisa para permitir ou não certas cifras, mas sem opções para configurar a ordem da cifra ou mesmo a cifra preferida.

    

Answer 4

Para conectores nativos / APR / OpenSSL

A partir do Tomcat 6.0.37 / 7.0.30 /8.0.x, o conector nativo / APR / OpenSSL suporta o SSLHonorCipherOrder configuração que permite ao servidor ter uma ordem especificada na qual as cifras são escolhidas. Essa ordenação depende de você e não se baseia em definições difusas como "força", já que uma cifra de alto bit pode ser pior do que uma cifra de bit inferior em certas situações.

Para conectores baseados em Java (BIO, NIO, NIO2)

O Tomcat 8.0.21 e posterior no Java 8 e posterior usarão a ordem de conjunto de codificação preferida do servidor se useServerCipherSuitesOrder estiver definido como "true" (o padrão) para conectores baseados em Java.

O Tomcat 7.0.60 e posterior no Java 8 e posterior usarão a ordem de conjunto de codificação preferida do servidor se useServerCipherSuitesOrder for definido como "true" (o padrão) para conectores baseados em Java.

O Tomcat 6 nunca teve esse recurso para conectores baseados em Java; a ordenação preferida pelo servidor dos conjuntos de cifras no Tomcat 6 exigirá o uso do conector nativo / APR.