BLOG | NGINX

Protegendo NGINX e NGINX Plus do ataque POODLE contra SSLv3 (CVE-2014-3566)

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Owen Garrett
Owen Garrett
Publicado em 15 de novembro de 2014

Uma vulnerabilidade relatada recentemente na versão 3 do protocolo SSL (SSLv3) pode ser explorada em um ataque do tipo man-in-the-middle para extrair partes de uma transmissão de texto simples que foi criptografada com HTTPS. Pesquisadores do Google publicaram uma explicação detalhada descrevendo como tal ataque pode ser realizado.

Esta não é uma vulnerabilidade em nenhuma implementação de SSL/TLS, mas sim uma vulnerabilidade no design do protocolo SSLv3 ao usar cifras de bloco. Como todas as cifras de fluxo alternativas também apresentam fraquezas, a única medida é desabilitar o SSLv3 em suas configurações NGINX e NGINX Plus.

Desabilitando SSLv3 no NGINX

O SSLv3 é habilitado por padrão no NGINX e no NGINX Plus e é potencialmente usado por serviços HTTP e de e-mail.

[Editor – Proxy e balanceamento de carga de tráfego TCP não eram totalmente suportados quando este artigo foi publicado originalmente. Para fins de integridade, as etapas a seguir foram atualizadas para incluir proteção para tráfego TCP.]

Execute estas etapas em todas as instâncias do NGINX e do NGINX Plus:

  1. Elimine o SSLv3 do conjunto de protocolos usados para tráfego HTTP. Adicione a seguinte diretiva ssl_protocols ao bloco http{} se ela não existir, ou edite a diretiva existente para remover SSLv3 da lista de parâmetros.

    # nos blocos de configuração http{}sl_protocols TLSv1 TLSv1.1 TLSv1.2; # omitir SSLv3 por causa do POODLE (CVE‑2014‑3566)
  2. Crie ou edite a mesma diretiva no bloco de configuração mail{} se suas instâncias NGINX ou NGINX Plus manipularem tráfego de e-mail.

    # nos blocos de configuração de e-mail{}sl_protocols TLSv1 TLSv1.1 TLSv1.2; # omitir SSLv3 por causa do POODLE (CVE‑2014‑3566)
  3. Crie ou edite a mesma diretiva no bloco de configuração stream{} se suas instâncias NGINX ou NGINX Plus manipularem tráfego TCP.

    # nos blocos de configuração do fluxo{}sl_protocols TLSv1 TLSv1.1 TLSv1.2; # omitir SSLv3 por causa do POODLE (CVE‑2014‑3566)
  4. Localize todas as outras instâncias da diretiva ssl_protocols na sua configuração (ela pode ser incluída em um bloco de configuração server{} dentro dos blocos http{} , mail{} e stream{} ). Recomendamos remover essas diretivas ssl_protocols , mas no mínimo remover SSLv3 da lista de parâmetros:

    # em cada bloco de servidor{} ssl_protocols TLSv1 TLSv1.1 TLSv1.2;# omitir SSLv3 por causa do POODLE (CVE‑2014‑3566)
  5. Execute o seguinte comando para recarregar a configuração:

    # nginx –s recarregar

Qual é o efeito dessa mudança?

Todos os navegadores modernos e clientes de API oferecem suporte a TLSv1 e versões posteriores. Desabilitar o SSLv3 causará transtornos aos usuários do Windows XP que navegam usando o Internet Explorer 6; a CloudFlare estima que 1,12% dos usuários do Windows XP (que representam 3,12% do tráfego) serão afetados – o que equivale a aproximadamente 1 em cada 3.000 usuários.

A mudança também pode afetar rastreadores da web e outros tráfegos de bots automatizados.

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 de SSLv3, pode tornar a conexão SSL/TLS vulnerável ao ataque POODLE. Desabilitar o SSLv3 no servidor torna esse ataque impossível.

O Google propôs uma extensão para SSL/TLS chamada TLS_FALLBACK_SCSV que busca evitar downgrades forçados de SSL/TLS. [Editor – A extensão foi adotada como RFC 7507 em abril de 2015.] Essa extensão pode eventualmente ser aceita no OpenSSL, e o suporte correspondente do lado do cliente pode ser adicionado aos principais navegadores. Isso permitirá que serviços web suportem SSLv3, mas clientes legados ainda estarão vulneráveis.

No entanto, essa vulnerabilidade pode sinalizar o último prego no caixão do SSLv3 – uma solução mais simples e confiável no geral.

O que mais posso fazer?

Recomendamos atualizar o software do seu cliente para que ele não suporte SSLv3. Isso protegerá você desse ataque quando você acessar serviços que não foram atualizados para desabilitar o SSLv3.

Leitura adicional


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."