Como corrigir a vulnerabilidade de 'logjam' no Apache (httpd)

Question

Recentemente, foi publicada uma nova vulnerabilidade no Diffie-Hellman, informalmente chamada de 'logjam', para a qual esta página foi elaborado sugerindo como combater a vulnerabilidade:

We have three recommendations for correctly deploying Diffie-Hellman for TLS:

1. Disable Export Cipher Suites. Even though modern browsers no longer support export suites, the FREAK and Logjam attacks allow a man-in-the-middle attacker to trick browsers into using export-grade cryptography, after which the TLS connection can be decrypted. Export ciphers are a remnant of 1990s-era policy that prevented strong cryptographic protocols from being exported from United States. No modern clients rely on export suites and there is little downside in disabling them.
2. Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE). Elliptic-Curve Diffie-Hellman (ECDH) key exchange avoids all known feasible cryptanalytic attacks, and modern web browsers now prefer ECDHE over the original, finite field, Diffie-Hellman. The discrete log algorithms we used to attack standard Diffie-Hellman groups do not gain as strong of an advantage from precomputation, and individual servers do not need to generate unique elliptic curves.
3. Generate a Strong, Unique Diffie Hellman Group. A few fixed groups are used by millions of servers, which makes them an optimal target for precomputation, and potential eavesdropping. Administrators should generate unique, 2048-bit or stronger Diffie-Hellman groups using "safe" primes for each website or server.

Quais são as etapas de melhores práticas que devo seguir para proteger meu servidor de acordo com as recomendações acima?

    

Answer 1

No artigo vinculado , há três etapas recomendadas para se proteger contra essa vulnerabilidade. Em princípio, essas etapas se aplicam a qualquer software que você possa usar com SSL / TLS, mas aqui lidaremos com as etapas específicas para aplicá-las ao Apache (httpd), já que esse é o software em questão.

1. Disable Export Cipher Suites

Lida com as alterações de configuração que faremos em 2. abaixo ( !EXPORT perto do final da linha SSLCipherSuite é como desativamos os conjuntos de cifras de exportação)

2. Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE)

Para isso, você precisa editar algumas configurações em seus arquivos de configuração do Apache, ou seja, SSLProtocol , SSLCipherSuite , SSLHonorCipherOrder para ter uma configuração de "práticas recomendadas". Algo como o seguinte será suficiente:

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Nota: como para qual configuração de SSLCipherSuite usar, isso está sempre mudando, e é uma boa idéia consultar recursos como este para verificar a última configuração recomendada.

3. Generate a Strong, Unique Diffie Hellman Group

Para fazer isso, você pode executar

openssl dhparam -out dhparams.pem 2048 .

Observe que isso colocará uma carga significativa no servidor enquanto os parâmetros são gerados - você sempre pode contornar esse problema gerando os parâmetros em outra máquina e usando scp ou similar para transferi-los para o servidor em questão. usar.

Para usar esses dhparams recém-gerados no Apache, na Documentação do Apache :

To generate custom DH parameters, use the openssl dhparam command. Alternatively, you can append the following standard 1024-bit DH parameters from RFC 2409, section 6.2 to the respective SSLCertificateFile file:

(ênfase minha)

que é então seguido por um parâmetro DH padrão de 1024 bits. A partir disso, podemos inferir que os parâmetros DH gerados de forma customizada podem ser simplesmente anexados ao SSLCertificateFile em questão.

Para fazer isso, execute algo semelhante ao seguinte:

cat /path/to/custom/dhparam >> /path/to/sslcertfile

Como alternativa, de acordo com a subseção do Apache do artigo que você vinculou originalmente, você também pode especificar o arquivo dhparams personalizado que criou se você preferir não alterar o arquivo de certificado, assim:

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

em qualquer configuração do Apache que seja relevante para sua implementação SSL / TLS específica - geralmente em conf.d/ssl.conf ou conf.d/vhosts.conf , mas isso será diferente dependendo de como você configurou o Apache.

Vale a pena notar que, conforme este link ,

Before Apache 2.4.7, the DH parameter is always set to 1024 bits and is not user configurable. This has been fixed in mod_ssl 2.4.7 that Red Hat has backported into their RHEL 6 Apache 2.2 distribution with httpd-2.2.15-32.el6

No Debian Wheezy atualize o apache2 para 2.2.22-13 + deb7u4 ou posterior e abra-o para 1.0.1e-2 + deb7u17. O SSLCipherSuite acima não funciona perfeitamente, ao invés disso, use o seguinte conforme este blog :

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

Você deve verificar se a sua versão do Apache é posterior a estes números de versão, dependendo da sua distribuição, e se não - atualize-a, se possível.

Depois de executar as etapas acima para atualizar sua configuração e reiniciar o serviço Apache para aplicar as alterações, verifique se a configuração é a desejada, executando os testes em SSLLabs e no artigo relacionado a essa vulnerabilidade específica.

    

Answer 2

Baseado em um patch de Winni Neessen eu publiquei uma correção para o Apache / 2.2.22 (Debian Wheezy, talvez também utilizável no Ubuntu): - thx. para o seu feedback.

    

Answer 3

Em vez de seguir a rota complexa dos hacks acima, considere alternar para o nginx como seu principal software de servidor web (não apenas cache ou proxy). Obviamente, parece estar mais de acordo com os padrões atuais, em termos de segurança, do que os antigos mecanismos apache. Ao usar o repositório nginx, ele está dando a você um mecanismo do servidor da Web mais atualizado do que o apache.

Eu mudei completamente. Economizei muito tempo na resolução de problemas de TLS, e - para nossas configurações - também liberou muita memória RAM da mesma forma. De fato, achei o emprego do nginx agradavelmente simples e direto, comparado com a miríade de complicações de configuração do httpd / apache que eu havia me acostumado. Poderia ser uma questão de gosto, eu tinha me tornado bastante fluente em httpd / apache reescrever / config / maintenance antes de me virar, e era mais fácil do que eu temia que fosse. Existem informações recentes apropriadas sobre a configuração do nginx disponíveis on-line, e sua base de usuários é enorme, muito ativa e compatível com o suporte. link