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.
Pronto, agora basta executar o teste novamente e assegurar-se que tudo deu certo!
Um grande abraço e até a próxima 😉
Referências:
The Logjam Attack
List ciphers used by JVM
Disabling the use of ephemeral DH keys in mailboxd
