Uma vulnerabilidade relatada recentemente na versão 3 do protocolo SSL (SSLv3) pode ser explorada em um ataque man-in-the-middle para extrair partes de uma transmissão em texto simples que foi criptografada com HTTPS. Pesquisadores do Google publicaram uma explicação detalhada descrevendo como esse tipo de ataque pode ser realizado.
Esta não é uma vulnerabilidade em nenhuma implementação de SSL/TLS, mas sim uma vulnerabilidade no projeto do protocolo SSLv3 ao usar cifras de bloco. Como todas as cifras de fluxo alternativas também apresentam falhas, a única medida é desabilitar o SSLv3 nas configurações do NGINX e do NGINX Plus.
Desabilitando o SSLv3 no NGINX
O SSLv3 é habilitado por padrão no NGINX e no NGINX Plus e pode ser usado pelos serviços HTTP e de e-mail.
[Editor – Proxy e balanceamento de carga de tráfego TCP não eram totalmente compatíveis quando este artigo foi publicado originalmente. Para fins de completude, as etapas a seguir foram atualizadas para incluir a proteção do tráfego TCP.]
Execute estas etapas em todas as instâncias do NGINX e do NGINX Plus:
- Elimine o SSLv3 do conjunto de protocolos usados para o tráfego HTTP. Adicione a seguinte diretiva
ssl_protocolsao blocohttp{}caso ela não exista ou edite a diretiva existente para removerSSLv3da lista de parâmetros.
# in the http{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)- Crie ou edite a mesma diretiva no bloco de configuração
mail{}se suas instâncias do NGINX ou NGINX Plus processarem tráfego de e-mail.
# in the mail{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)- Crie ou edite a mesma diretiva no bloco de configuração
stream{}se suas instâncias do NGINX ou NGINX Plus processarem tráfego TCP.
# in the stream{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)- Localize todas as outras ocorrências da diretiva
ssl_protocolsna sua configuração (ela pode estar incluída em um bloco de configuraçãoserver{}dentro dos blocoshttp{},mail{}estream{}). Recomendamos remover essas diretivasssl_protocols, mas, no mínimo, removaSSLv3da lista de parâmetros:
# in every server{} block ssl_protocols TLSv1 TLSv1.1 TLSv1.2;# omit SSLv3 because of POODLE (CVE‑2014‑3566)- Execute o seguinte comando para recarregar a configuração:
# nginx –s reloadQual é o efeito dessa alteração?
Todos os navegadores modernos e clientes de API são compatíveis com TLSv1 e versões posteriores. Desabilitar o SSLv3 causará transtornos aos usuários do WindowsXP que navegam usando o Internet Explorer 6; CloudFlare estima que 1,12% dos usuários do WindowsXP (que representam 3,12% do tráfego da empresa) serão afetados — o equivalente a aproximadamente 1 em cada 3.000 usuários.
A alteração também pode afetar rastreadores da web e outros tipos de tráfego automatizado de bots.
O futuro
Em um ataque de downgrade de SSL, o invasor pode interromper os handshakes SSL/TLS e fazer com que o cliente e o servidor selecionem uma versão anterior do SSL/TLS. Quando usado para forçar a seleção do SSLv3, esse ataque pode tornar a conexão SSL/TLS vulnerável ao ataque POODLE. Desabilitar o SSLv3 no servidor impossibilita esse ataque.
O Google propôs uma extensão para SSL/TLS chamada TLS_FALLBACK_SCSV que busca impedir downgrades forçados de SSL/TLS. [Editor – A extensão foi adotada como RFC 7507 em abril de 2015.] Essa extensão poderá vir a ser incorporada ao OpenSSL, e o suporte correspondente no lado do cliente poderá ser adicionado aos principais navegadores. Isso permitirá que os serviços web ofereçam suporte ao SSLv3, mas os clientes legados ainda estarão vulneráveis.
No entanto, essa vulnerabilidade pode representar o golpe final no SSLv3 — uma solução mais simples e confiável de modo geral.
O que mais posso fazer?
Recomendamos atualizar o software cliente para que ele não ofereça suporte ao SSLv3. Isso protegerá você contra esse ataque ao acessar serviços que ainda não foram atualizados para desativar o SSLv3.
Leitura complementar
- O relatório original da vulnerabilidade
- Uma explicação mais concisa do ImperialViolet
- Vários fornecedores publicaram recomendações; a da Ubuntu é particularmente abrangente
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.