Introdução à Criptografia em Trânsito e a Necessidade do Hardening
A segurança de dados em trânsito é um pilar fundamental da infraestrutura moderna. Quando falamos em criptografia em trânsito, referimo-nos ao processo de proteger informações enquanto elas viajam entre o cliente (navegador, aplicativo móvel) e o servidor web. Sem essa proteção, dados sensíveis como credenciais de login, números de cartão de crédito e comunicações privadas podem ser interceptados por atacantes através de técnicas de man-in-the-middle (MitM).
Neste tutorial técnico focado em segurança linux, vamos abordar o hardening de servidores web populares: Nginx e Apache HTTP Server. O objetivo principal é forçar a utilização do protocolo TLS 1.3, que representa o estado da arte em segurança e performance para criptografia na internet atual.
O TLS (Transport Layer Security) evoluiu significativamente desde sua criação. Versões anteriores, como SSL 2.0, SSL 3.0, TLS 1.0 e TLS 1.1, foram descontinuadas ou consideradas vulneráveis devido a falhas conhecidas (como POODLE, BEAST e ROBOT). O TLS 1.2 ainda é amplamente suportado, mas o TLS 1.3 oferece vantagens críticas: handshake mais rápido (reduzindo a latência), eliminação de cifras obsoletas e inseguras, e forward secrecy obrigatória em quase todos os casos.
A configuração adequada não serve apenas para passar por auditorias de segurança, mas também para garantir conformidade com padrões da indústria e proteger a reputação do seu serviço. Vamos dividir este guia em duas partes principais: configuração do Nginx e configuração do Apache.
Pré-requisitos Comuns
Antes de modificar as configurações dos servidores, é essencial garantir que o ambiente esteja preparado para lidar com o TLS 1.3.
- Sistema Operacional: Utilize uma distribuição Linux atualizada (Ubuntu 20.04+, Debian 11+, RHEL/CentOS 8+). Versões antigas podem não incluir as bibliotecas OpenSSL necessárias.
- OpenSSL: Certifique-se de que o OpenSSL está atualizado para uma versão que suporte nativamente o TLS 1.3 (geralmente OpenSSL 1.1.1 ou superior).
- Certificados SSL/TLS: Você precisa ter um certificado válido instalado em seu servidor. Para testes, certificados autoassinados podem ser usados, mas para produção, utilize certificados emitidos por uma Autoridade Certificadora confiável (como Let's Encrypt, DigiCert, etc.).
Verifique a versão do OpenSSL em execução no seu servidor com o comando:
openssl versionO resultado deve indicar uma versão igual ou superior a 1.1.1.
Parte 1: Hardening do Nginx para TLS 1.3
O Nginx é conhecido por sua alta performance e eficiência de recursos. Sua configuração de SSL/TLS reside no arquivo de bloco de servidor (server block), geralmente localizado em /etc/nginx/sites-available/ ou /etc/nginx/conf.d/.
1.1 Configurando os Diretivas de Protocolo
A primeira etapa é instruir o Nginx a aceitar apenas conexões seguras e, especificamente, a negociar o TLS 1.3. Embora seja recomendado manter o TLS 1.2 para compatibilidade com clientes muito antigos (embora isso esteja diminuindo rapidamente), o foco aqui é garantir que o TLS 1.3 seja preferido.
Edite seu arquivo de configuração do site. Adicione ou modifique a diretiva ssl_protocols:
server {
listen 443 ssl http2;
server_name exemplo.com www.exemplo.com;
# Configurações de Certificado
ssl_certificate /etc/letsencrypt/live/exemplo.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/exemplo.com/privkey.pem;
# Hardening do Protocolo TLS
ssl_protocols TLSv1.3;
}Nota Importante: Ao definir ssl_protocols TLSv1.3;, você está desabilitando explicitamente o TLS 1.2, 1.1 e versões anteriores. Isso é seguro para a maioria dos ambientes modernos, mas se você tiver clientes legados que não suportam TLS 1.3, você deve usar ssl_protocols TLSv1.2 TLSv1.3;. No entanto, para fins de hardening máximo, forçar apenas o 1.3 é o ideal.
1.2 Selecionando Cifras Seguras
O TLS 1.3 simplificou drasticamente a lista de cifras disponíveis. Ao contrário do TLS 1.2, que tinha dezenas de opções (muitas inseguras), o TLS 1.3 define um conjunto fixo de cifras consideradas seguras. Portanto, a diretiva ssl_ciphers é menos crítica no TLS 1.3, mas ainda pode ser especificada para controle fino se necessário.
Para o TLS 1.3, as cifras padrão são geralmente suficientes e recomendadas:
# As cifras do TLS 1.3 são gerenciadas internamente pela biblioteca OpenSSL
# Não é estritamente necessário definir ssl_ciphers para TLS 1.3 puro,
# mas se você suportar TLS 1.2 simultaneamente, defina aqui:
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
# Para forçar a preferência de cifras seguras no handshake
ssl_prefer_server_ciphers on;A diretiva ssl_prefer_server_ciphers on garante que o servidor decide qual cifra será usada, evitando que um cliente malicioso ou legado force o uso de uma cifra fraca.
1.3 Configurando Sessões e Renegociação
O handshaking TLS pode ser custoso em termos de CPU. Para otimizar performance sem sacrificar segurança, configuramos sessões SSL:
# Tempo de vida da sessão (em segundos)
ssl_session_timeout 1d;
# Cache de sessões para reutilização
ssl_session_cache shared:SSL:50m;
# Tipo de cache externo (opcional, mas recomendado para clusters)
ssl_session_tickets off;Atenção: Desativar ssl_session_tickets (off) é uma prática de hardening recomendada. Os tickets de sessão podem comprometer o forward secrecy se a chave do ticket for comprometida. Sem eles, cada nova conexão exige um handshake completo, garantindo que mesmo que uma chave seja quebrada no futuro, as comunicações passadas permanecem seguras.
1.4 Habilitando OCSP Stapling
O OCSP (Online Certificate Status Protocol) permite verificar se um certificado foi revogado. O "Stapling" faz com que o Nginx obtenha essa assinatura da Autoridade Certificadora e a envie ao cliente durante o handshake, melhorando a privacidade e a velocidade.
ssl_stapling on;
ssl_stapling_verify on;
# Resolver o nome do domínio da CA para obter o status OCSP
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;Lembre-se de que o resolver deve apontar para servidores DNS confiáveis e acessíveis pelo seu servidor.
Parte 2: Hardening do Apache HTTP Server para TLS 1.3
O Apache possui uma estrutura de configuração modular. As configurações de SSL geralmente ficam em /etc/apache2/mods-available/ssl.conf ou em arquivos de vhost específicos.
2.1 Configurando Protocolos e Cifras
No Apache, utilizamos as diretivas SSLProtocol e SSLCipherSuite. A sintaxe é ligeiramente diferente do Nginx.
# Desabilitar todos os protocolos antigos
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
# Forçar preferencialmente o TLS 1.3, mas manter compatibilidade com 1.2 se necessário
# Para hardening estrito (apenas 1.3):
SSLProtocol -all +TLSv1.3Se você optar por suportar ambos (recomendado para máxima compatibilidade enquanto migra clientes):
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1Para as cifras, o Apache exige uma lista explícita. Use a "Hardened Cipher Suite" recomendada pela Mozilla:
# Cifras modernas e seguras
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
# Priorizar as cifras do servidor
SSLHonorCipherOrder onA diretiva SSLHonorCipherOrder on é crucial. Sem ela, o Apache poderia aceitar a preferência do cliente, que poderia ser uma cifra mais fraca.
2.2 Gerenciamento de Sessões e Tickets
O Apache gerencia sessões de SSL através de módulos como mod_ssl. A configuração é similar:
# Tempo de sessão
SSLSessionTimeout 86400
# Desativar tickets de sessão para garantir Forward Secrecy
SSLSessionTickets off2.3 Habilitando OCSP Stapling no Apache
O Apache também suporta OCSP Stapling nativamente:
# Habilitar stapling
SSLUseStapling on
# Limpar cache de respostas OCSP periodicamente
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"Verifique se o módulo mod_socache_shmcb está habilitado, pois é necessário para o cache de stapling.
Validação e Testes Pós-Configuração
Após aplicar as configurações em ambos os servidores, é imperativo validar que o hardening funcionou corretamente antes de liberar o tráfego em produção ou monitorá-lo ativamente.
3.1 Sintaxe da Configuração
Sempre teste a sintaxe antes de recarregar o serviço para evitar quedas no serviço.
Para Nginx:
sudo nginx -tPara Apache:
sudo apachectl configtestSe a saída indicar "syntax ok" ou "ok", você pode prosseguir com o reload:
# Nginx
sudo systemctl reload nginx
# Apache
sudo systemctl reload apache23.2 Verificação de Protocolo TLS
Utilize a ferramenta openssl s_client para verificar manualmente qual versão do protocolo está sendo negociada.
echo | openssl s_client -connect seu-dominio.com:443 -tls1_3 2>&1 | grep "Protocol"Se a conexão for estabelecida e o retorno mostrar TLSv1.3, a configuração está correta para essa versão. Tente conectar com -tls1_2; se você configurou apenas TLS 1.3, essa conexão deve falhar (o que é desejável em um cenário de hardening estrito).
3.3 Ferramentas Online de Auditoria
Para uma análise completa que inclui força de cifras, suporte a certificados e pontuação de segurança, utilize ferramentas online confiáveis:
- SSL Labs (Qualys): Acesse
ssllabs.com/ssltest. Insira seu domínio. O objetivo é obter uma nota A+. - TestSSL.sh: Uma ferramenta de linha de comando poderosa para testes locais.
Na análise do SSL Labs, verifique a seção "Protocol Support". Você deve ver apenas TLS 1.2 e/ou TLS 1.3 listados como suportados, dependendo da sua escolha. Se aparecer TLS 1.0 ou 1.1, revise suas configurações de ssl_protocols ou SSLProtocol.
Considerações Finais sobre Segurança Linux e Hardening
A migração para o TLS 1.3 não é apenas uma atualização técnica, mas uma mudança de postura em relação à segurança da informação. Ao desabilitar protocolos antigos e cifras fracas, você reduz a superfície de ataque do seu servidor.
Lembre-se que o hardening é um processo contínuo. Monitore logs de erro para identificar clientes que estão sendo rejeitados por não suportarem TLS 1.3 e avalie se vale a pena manter a compatibilidade ou forçar a atualização desses clientes. Além disso, mantenha suas bibliotecas OpenSSL e seus certificados atualizados.
A segurança linux exige vigilância constante. Configurar o Nginx ou Apache para usar apenas criptografia forte é um passo fundamental, mas deve ser acompanhado de boas práticas em outras camadas, como firewall (iptables/nftables), gerenciamento de pacotes e monitoramento de integridade de arquivos.
Ao seguir estes passos, você garante que seus dados estejam protegidos contra interceptações modernas e que seu servidor esteja alinhado com as melhores práticas globais de segurança linux.