Ataque contra acordo de chaves Diffie-Hellman no OpenSSL

Por: Conrado Gouvêa / Andre “Dexter” Bereza

O OpenSSL divulgou no dia 28/01/2016 uma vulnerabilidade que pode afetar servidores que utilizam Diffie-Hellman para fazer acordo de chaves em conexões seguras.

O Ataque

O OpenSSL é uma biblioteca criptográfica de propósito geral com a capacidade de estabelecer conexão segura entre dois pontos utilizando o protocolo TLS.

Uma das etapas de uma conexão segura é o acordo de chaves, que pode utilizar diversos tipos de algoritmos. O algoritmo em questão é o Diffie-Hellman (DH), criado por Whitfield Diffie e Martin Hellman em 1976. Ele é composto por três fases: geração de parâmetros, geração de chaves e o acordo propriamente dito.

A geração de parâmetros DH é normalmente feita uma única vez no início da configuração do servidor e permanece a mesma durante o funcionamento dele. A geração de chaves, idealmente, é feita a cada conexão pelas duas partes, seguida então do acordo de chaves propriamente dito. Desta forma obtém-se a propriedade de “forward secrecy”, isto é, se a chave privada Diffie-Hellman for vazada de alguma forma, então conexões anteriores não poderão ser quebradas, somente posteriores. Contudo, por questões de eficiência, alguns servidores geram uma chave no início da execução e ela é reutilizada por todas as conexões durante a execução do servidor. Tal prática compromete o forward secrecy, já que o vazamento da chave DH permite a quebra de todas as conexões criadas desde o início da execução do servidor.

O OpenSSL inseriu uma funcionalidade em sua versão 1.0.2 que permite a geração de parâmetros Diffie-Hellman descritos na RFC 5114. O problema é que tais parâmetros não foram definidos de forma correta e são inseguros. Um cliente malicioso é capaz de extrair a chave privada de um servidor utilizando tais parâmetros se ele conseguir se conectar múltiplas vezes com o servidor, e o servidor utilizar a mesma chave Diffie-Hellman em todas as conexões durante sua execução. Como mencionado, este não é o recomendado, mas é a configuração padrão do OpenSSL.

Solução

O OpenSSL possui uma configuração que é a “SSL_OP_SINGLE_DH_USE”. Essa configuração, quando ativa, faz com que o OpenSSL gere chaves DH a cada nova conexão. Quando desativada, que é o padrão do OpenSSL, um único par de chaves é gerado quando o aplicativo é iniciado e reutilizado em todas as conexões durante a execução do aplicativo.

Na sua versão mais recente, a 1.0.2f, o OpenSSL foi modicado de forma que o “SSL_OP_SINGLE_DH_USE” esteja sempre ativo, sendo impossível desativá-lo. Adicionalmente, o OpenSSL adicionou uma checagem no servidor de forma a detectar e impedir este ataque, validando os parâmetros enviados pelo cliente.

As versões anteriores do OpenSSL não são suscetíveis a essa falha, pois a função que gerava parâmetros inseguros não existia antes do OpenSSL 1.0.2, mas o OpenSSL da família 1.0.1 foi corrigido por precaução. Ainda assim, versões antigas do OpenSSL têm o “SSL_OP_SINGLE_DH_USE” desativado por padrão. Também é interessante notar que a opção “SSL_OP_SINGLE_ECDH_USE” análoga, só que referente ao Diffie-Hellman com curvas elípticas, continua sendo desativada por padrão mesmo em versões recentes.

Resumo

O que fazer como responsável por servidores:
– Ativar SSL_OP_SINGLE_USE e/ou atualizar o OpenSSL para 1.0.2f
– Certificar-se que os parâmetros Diffie-Hellman não foram gerados com “genpkey” utilizando a opção “dh_rfc5114”, ou então com “dhparam” e a opção “-dsaparam”. Pode ser mais fácil gerar parâmetros novos sem essas opções, para garantir.
– Alternativamente, desativar suítes TLS que utilizem DH e somente utilizar ECDH (que é mais eficiente), e ativar SSL_OP_SINGLE_ECDH_USE.

O que fazer como usuário ou responsável por clientes:
– Não é necessário fazer nada, somente servidores são afetados.

Referências:
OpenSSL security advisory: https://www.openssl.org/news/secadv/20160128.txt
Descrição do ataque pelo seu autor: http://intothesymmetry.blogspot.com.br/2016/01/openssl-key-recovery-attack-on-dh-small.html[/vc_column_text][vc_column_text]