Prevenindo o Logjam Attack no Glassfish 3.1.2.2

Desde o update 39 do Firefox muitas pessoas passaram a receber a tela de erro abaixo quando tentam acessar endereços utilizando https.

Isso se deve a uma grande falha (Logjam Attack) descoberta no método de troca de chaves chamado Diffie-Hellman. O Firefox foi o primeiro a recusar o acesso a sites com este problema e os demais como Chrome e Internet Explorer virão logo em seguida.

Para testar se seu servidor está vulnerável clique aqui, e na caixa onde diz “Teste A Server” digite o endereço de seu site e clique em Go.

Se o resultado for como o da imagem abaixo está tudo certo e nada precisa ser feito!

Caso o resultado não seja positivo (barra azul) e se pareça com um dos abaixo você infelizmente terá um trabalhinho 🙁

O primeiro passo é verificar se o Java está reconhecendo os conjuntos criptográficos que precisaremos utilizar (eles tem o prefixo TLS_ECDH). A maneira mais fácil de verificar é copiando o código abaixo e salva-lo em seu servidor com o nome de Ciphers.java

import java.util.Iterator;
import java.util.Map;
import java.util.TreeMap;
import javax.net.ssl.SSLServerSocketFactory;

public class Ciphers
{
 public static void main(String[] args)
 throws Exception
 {
 SSLServerSocketFactory ssf = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();

 String[] defaultCiphers = ssf.getDefaultCipherSuites();
 String[] availableCiphers = ssf.getSupportedCipherSuites();

 TreeMap ciphers = new TreeMap();

 for(int i=0; i<availableCiphers.length; ++i )
 ciphers.put(availableCiphers[i], Boolean.FALSE);

 for(int i=0; i<defaultCiphers.length; ++i )
 ciphers.put(defaultCiphers[i], Boolean.TRUE);

 System.out.println("Default\tCipher");
 for(Iterator i = ciphers.entrySet().iterator(); i.hasNext(); ) {
 Map.Entry cipher=(Map.Entry)i.next();

 if(Boolean.TRUE.equals(cipher.getValue()))
 System.out.print('*');
 else
 System.out.print(' ');

 System.out.print('\t');
 System.out.println(cipher.getKey());
 }
 }
}

Digite o comando abaixo para compilar o aplicativo que usaremos.

javac Ciphers.java

Agora digite o comando abaixo para executar o aplicativo.

java Ciphers

Neste momento será exibida uma lista com todos os conjuntos criptográficos reconhecidos pelo Java. Se aparecerem itens com o prefixo “TLS_ECDH” você está com sorte e pode ir direto para a configuração do Glassfish, caso contrário será necessário habilitar estes conjuntos criptográficos.

Os conjuntos necessários estão marcados pela zona vermelha.

Antes de habilitarmos os conjuntos criptográficos necessários precisamos verificar qual é o security provider que sua versão de Java está utilizando. Para isso edite o arquivo ${java.home}/lib/security/java.security.

Apenas para exemplificar, em alguns servidores que tenho este arquivo está localizado em:

/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.85.x86_64/jre/lib/security/java.security.

Dentro do arquivo procure pelo trecho abaixo:

# the NSS security provider was not enabled for this build; it can be enabled
# if NSS (libnss3) is available on the machine. The nss.cfg file may need
# editing to reflect the location of the NSS installation.
security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

Se a ultima linha estiver descomentada, significa que você está utilizando o NSS como security provider, caso contrário você está utilizando o JCE.

Se estiver utilizando o NSS será necessário atualiza-lo para a ultima versão através do comando (no meu caso utilizo CentOs) abaixo:

yum update nss

Caso utilize o JCE baixe o “Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7” aqui. No meu caso utilizo o Java 7.

Extraia os dois arquivos “local_policy.jar” e “US_export_policy.jar” para a pasta ${java.home}/lib/security/ sobrescrevendo os antigos.

Legal, estamos quase -lá 🙂

Execute novamente o aplicativo que criamos com o comando abaixo para termos certeza que os conjuntos criptográficos necessários foram instalados corretamente:

java Ciphers

Agora é a hora de configurarmos o Glassfish para não permitir que ele utilize os conjuntos criptográficos vulneráveis.

Em seu painel do Glassfish Admin vá em:
1) Configurações -> server-config -> Configurações de Rede -> Listeners de Rede -> http-listener-2
2) Clique na aba SSL.
3) No primeiro item desabilite o SSL3 se estiver habilitado. Este item nem é necessário para resolver este problema, mas ele impede outra vulnerabilidade conhecida como “Poodle”.

4) Deixe os conjuntos criptográficos “Conjuntos Criptográficos Diffie-Hellman Temporários Disponíveis:” apenas com estes três do lado esquerdo conforme mostra a imagem abaixo para desabilita-los.