Implementando a Segurança Perfeita de Transmissão SSL no Servidor Web NGINX

Este COMO FAZER descreve o processo de implementação da Segurança Perfeita de Transmissão com o servidor web NGINX em sistemas Debian e Ubuntu. O processo pode ser facilmente adaptado para outros sistemas GNU/Linux.

Em resumo, a Segurança Perfeita de Transmissão garante: “… que a compromissão de uma mensagem não pode levar à compromissão de outras, e também que não há um único valor secreto que possa levar à compromissão de múltiplas mensagens.” Para mais informações, veja http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy.

Quando a vulnerabilidade Heartbleed no OpenSSL foi revelada no início de 2014, ficou cada vez mais claro que PFS é imprescindível para qualquer sistema que utilize SSL/TLS de forma séria.

Caso você deseje comparar seus resultados com os meus, minha implementação de referência pode ser testada em https://www.ssllabs.com/ssltest/analyze.html?d=indietorrent.org, e a cadeia de certificados SSL e os cabeçalhos NGINX que são enviados podem ser revisados em https://indietorrent.org.

Sem mais delongas, vamos configurar o NGINX para implementar PFS.

Vamos entrar no diretório de configuração do NGINX:

cd /etc/nginx/

Precisamos gerar parâmetros Diffie-Hellman que sejam suficientemente fortes. Alguns argumentam que 4096 bits é exagerado e causará uma carga indevida na CPU do sistema, mas com o poder computacional moderno, isso parece um compromisso válido. Para mais informações, veja a seção de Referências, abaixo.

openssl dhparam -out dh4096.pem 4096

É útil ter este arquivo de configuração, que é específico para a tarefa em questão, compartimentado em um arquivo de inclusão; isso torna mais simples implementar PFS em um grande número de sistemas.

vi /etc/nginx/perfect-forward-secrecy.conf

Cole o seguinte no arquivo acima:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !MEDIUM";
ssl_dhparam dh4096.pem;

Modifique a configuração do NGINX para incluir o arquivo acima, inserindo a seguinte linha no arquivo de configuração principal do NGINX (por padrão, /etc/nginx/nginx.conf), na parte inferior (e dentro) do bloco http {}:

# Veja: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
# Isso DEVE vir DEPOIS das linhas que incluem .../sites-enabled/*, caso contrário, o suporte ao SSLv3 pode ser reativado acidentalmente.
inclua perfect-forward-secrecy.conf;

Reinicie o NGINX para que as alterações tenham efeito:

service nginx restart

Se o teste em https://www.ssllabs.com/ssltest/analyze.html exibir a Resumação de Sessão (cache) Não (IDs atribuídos, mas não aceitos) em vermelho, e o servidor implementar SNI, adicione o seguinte ao bloco de nível superior http {} (ou seja, adicione ao nginx.conf, logo abaixo de onde fizemos as adições anteriores):

# Veja: http://forum.nginx.org/read.php?2,152294,152401#msg-152401
ssl_session_cache shared:SSL:10m;

Novamente, reinicie o NGINX para que as alterações tenham efeito:

service nginx restart

O teste acima não deve mais relatar esse problema (mesmo que o problema não reduza a pontuação geral do teste).

Levando Mais Longe: Implementando HTTP Strict Transport Security (HSTS) com Longa Duração

Este é fácil, e vale a pena fazer, desde que:

1. Você queira forçar SSL para todos os recursos de qualquer host para o qual este cabeçalho esteja definido (ou seja, cada página no site em questão).
2. Você possa viver sem ter a capacidade de aceitar e ignorar avisos SSL para qualquer recurso solicitado de qualquer host para o qual este cabeçalho esteja definido, como “Desvio de Nome de Domínio”, etc. A própria natureza do HSTS é que avisos e condições de erro relacionados ao certificado SSL não podem ser ignorados.

Eu pesquisei na Internet informações sobre se definir este cabeçalho poderia ter consequências não intencionais em navegadores que não suportam o cabeçalho e não encontrei nada. Mas, consegui aliviar minhas preocupações testando esta implementação no Internet Explorer 6, por exemplo, e navegadores nos quais o HSTS não é implementado simplesmente ignoram o cabeçalho. Perfeito!

Basta adicionar as seguintes linhas ao final de /etc/nginx/perfect-forward-secrecy.conf e salvar as alterações:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
# Isso evitará certos ataques de click-jacking, mas impedirá
# outros sites de emoldurar seu site, então exclua ou modifique conforme necessário!
add_header X-Frame-Options SAMEORIGIN;

Um recarregamento (em vez de uma reinicialização) será suficiente para forçar o NGINX a captar essas alterações específicas:

service nginx reload

É possível confirmar que o HSTS está funcionando como pretendido testando sua implementação em https://www.ssllabs.com/ssltest/analyze.html. Se o HSTS estiver implementado corretamente, você deve ver uma caixa verde logo abaixo de sua pontuação, afirmando: “Este servidor suporta HTTP Strict Transport Security com longa duração. Nota definida como A+.”

Parabéns!

Você agora tem uma das implementações SSL/TLS mais seguras da Internet.

Referências:

• https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

Copyright © 2014 Ben Johnson