BLOG | NGINX

Anunciando o NGINX Plus R26

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Robert Haynes Miniatura
Robert Haynes
Publicado em 15 de fevereiro de 2022

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 26 (R26) . Baseado no NGINX Open Source, o NGINX Plus é o único servidor web de software completo , balanceador de carga, proxy reverso, cache de conteúdo e gateway de API.

Os recursos novos e aprimorados do NGINX Plus R26 incluem:

  • Validação JWT mais rápida com cache JSON Web Key Set – Dando continuidade à série de melhorias no suporte a JSON Web Tokens (JWT) adicionadas nas últimas versões, apresentamos o cache na memória de JSON Web Key Sets (JWKS), o que reduz substancialmente a sobrecarga para validação JWT.
  • Handshakes TLS reforçados – O NGINX Plus rejeita o handshake TLS se o cliente propõe um protocolo de comunicação via ALPN que não corresponde ao contexto de configuração do NGINX para a sessão que está sendo estabelecida (por exemplo, propõe o protocolo de e-mail IMAP para um servidor virtual no contexto http{} ).
  • Melhorias no módulo NGINX JavaScript – Funções assíncronas que usam as palavras-chave async e await e o objeto Promise agora são suportadas, e implementamos a API WebCrypto para operações criptográficas (como gerar números aleatórios ou criptografar cookies).

Completando esta versão estão o suporte para a arquitetura IBM System Z (s390x) , a capacidade de fechar cada direção de uma conexão TCP de forma independente e o suporte para a versão 2 da biblioteca Perl Compatible Regular Expression (PCRE).

Mudanças importantes no comportamento

O módulo JavaScript NGINX não oferece mais suporte a js_include

Conforme anunciado no lançamento do NGINX Plus R23 , na versão0.4.0 do módulo JavaScript NGINX, a diretiva js_import substituiu a diretiva js_include . A diretiva js_include estava obsoleta naquela época e, a partir desta versão, não é mais suportada.

Antes de atualizar para o NGINX Plus R26 , substitua js_include por js_import nos arquivos de configuração do NGINX e também adicione uma instrução export aos arquivos JavaScript para funções referenciadas na configuração do NGINX. Siga estes passos:

  1. Editar arquivos de configuração do NGINX:

    • Substitua js_include por js_import e anote o module_name implícito (o parâmetro de nome de arquivo JavaScript para a diretiva, sem a extensão .js ).

    • Em cada diretiva que faz referência a uma função JavaScript, prefixe o nome da função com module_name . O nome da função é o primeiro parâmetro para essas diretivas:

      É o segundo parâmetro da diretiva js_set [ HTTP ][ Stream ].

    Por exemplo, altere:

    js_set $foo minhaFunção;
    

    para:

    js_set $foo nome_do_módulo .minhaFunção;
    
  2. Edite os arquivos JavaScript ( module_name .js ) que definem funções referenciadas em um arquivo de configuração NGINX. Adicione uma instrução de exportação como a seguinte a cada arquivo, nomeando as funções referenciadas.

    exportar padrão { minhaFunção, outraFunção }
    

    A instrução export pode aparecer em qualquer lugar no arquivo .js , mas por convenção ela é colocada diretamente acima das funções ou no final do arquivo.

O módulo Cookie-Flag está obsoleto

O módulo Cookie-Flag de terceiros foi descontinuado no NGINX Plus R23 e, conforme anunciado naquela época, não está mais disponível no repositório de módulos NGINX a partir desta versão.

Antes de atualizar para o NGINX Plus R26 , edite sua configuração do NGINX para substituir quaisquer ocorrências da diretiva set_cookie_flag (definida no módulo obsoleto) pela diretiva proxy_cookie_flags integrada.

A negociação TLS não suporta mais o protocolo NPN

A maneira como o NGINX estabelece conexões TLS e HTTP/2 foi atualizada. Como parte do handshake TLS entre o NGINX e um cliente (geralmente um navegador), eles negociam qual protocolo de comunicação será usado na sessão estabelecida pelo handshake (na maioria das vezes, a negociação atualiza a sessão de HTTP 1. x para HTTP/2). A extensão Next Protocol Negotiation (NPN) para TLS foi o primeiro método usado para essa finalidade, mas o NPN agora é considerado obsoleto e foi substituído pela extensão Application‑Layer Protocol Negotiation (ALPN), publicada como RFC 7301 .

O NGINX Plus R26 não oferece mais suporte a NPN, então os clientes agora devem usar exclusivamente ALPN.

Além disso, nossa implementação ALPN foi estendida e reforçada – veja Handshakes TLS reforçados .

O antigo repositório de software NGINX Plus não é mais atualizado

No lançamento do NGINX Plus R24 , os repositórios de pacotes para todos os softwares NGINX foram reorganizados, resultando em alterações no procedimento de instalação do NGINX Plus.

Ao instalar ou atualizar o NGINX Plus, o gerenciador de pacotes do sistema operacional ( apt , yum ou equivalente) é configurado com o repositório de software do NGINX Plus.

Se estiver atualizando para o NGINX Plus R26 em um sistema existente configurado para usar o antigo repositório plus-pkgs.nginx.com (aqueles executando o NGINX Plus R23 ou anterior), você deve atualizar o gerenciador de pacotes para consultar o novo repositório pkgs.nginx.com/plus . Veja as instruções na Base de Conhecimento F5 .

Se estiver executando uma instalação inicial do NGINX Plus R26 , consulte Instalando o NGINX Plus no Guia de administração do NGINX Plus .

O NGINX Plus R26 não está disponível no repositório antigo , que não receberá mais atualizações.

Acesso alterado à especificação OpenAPI para a API NGINX Plus

O pacote de software NGINX Plus não inclui mais a especificação OpenAPI de formato YAML e a Swagger UI para a API NGINX Plus . Agora você pode acessá-los no Guia de Administração do NGINX Plus .

Mudanças no suporte da plataforma

Novos sistemas operacionais e arquiteturas suportados:

Sistemas operacionais mais antigos removidos:

  • Alpine Linux 3.11 (a versão mais antiga suportada é 3.12)

Sistemas operacionais e arquiteturas mais antigos foram descontinuados e programados para remoção no NGINX Plus R27 :

  • Arquitetura Power8 (ppc64le)
  • CentOS 8.1+
  • Linux Alpino 3.12

Novos recursos em detalhes

Validação JWT mais rápida com cache de conjunto de chaves da Web JSON

Ao validar JSON Web Tokens, o NGINX usa um JSON Web Key Set (JWKS) para verificar a assinatura do token ou descriptografar o token. Os JWKSs podem ser armazenados em arquivos de configuração ou obtidos de serviços externos por meio de uma solicitação HTTP. Além disso, armazenar em cache um JWKS na memória tem vários benefícios:

  • Redução significativa no uso da CPU
  • Latência de solicitação reduzida
  • Otimização da validação do JWT, porque como parte do processo de cache, as chaves JWKS são convertidas de JSON para um formato binário otimizado para operações criptográficas

Para armazenar em cache JWKSs na memória, inclua a nova diretiva auth_jwt_key_cache e especifique o tempo de expiração para cada conjunto de chaves (neste exemplo, 3 horas):

 

Quando os JWKs são obtidos de um servidor externo, também recomendamos configurar o cache de conteúdo padrão e incluir a diretiva proxy_cache_use_stale , que informa ao NGINX Plus para continuar servindo um JWKS expirado enquanto ele está sendo atualizado em segundo plano.

 

Os benefícios do cache de conteúdo, além do cache JWKS, são duplos:

  • Resiliência – O JWKS pode ser recuperado do cache mesmo quando ele tiver expirado. Isso aumenta a resiliência quando o provedor JWKS está temporariamente indisponível, mas há uma compensação pelo aumento do risco de segurança.

  • Efeito no servidor de autorização – A expiração de um JWKS armazenado em cache afeta o servidor de autenticação de forma diferente, dependendo se o cache JWKS é usado sozinho ou em combinação com o cache de conteúdo:

    • Com o cache do JWKS sozinho, todas as solicitações de autorização recebidas são encaminhadas ao servidor de autenticação até que o cache seja preenchido novamente com uma nova versão do JWKS expirado. Se o servidor de autenticação responder lentamente, pode haver um aumento repentino de solicitações HTTP repetidas para o JWKS. Essa carga extra pode sobrecarregar o serviço de autenticação, piorando o problema.

    • Quando o cache de conteúdo é habilitado com o fornecimento de JWKSs expirados, apenas uma solicitação para o JWKS é encaminhada ao servidor de autenticação, com solicitações subsequentes enfileiradas até que o NGINX possa satisfazê-las após o cache de conteúdo ser preenchido. Isso resulta em menor demanda (e, portanto, menor consumo de recursos) no serviço de autenticação.

Apertos de mão TLS reforçados

Ataques contra TLS, como ALPACA , estão aumentando. Como parte do nosso compromisso contínuo com a defesa proativa contra explorações, reforçamos o tratamento de conexões TLS pelo NGINX.

A Negociação de Protocolo da Camada de Aplicação (ALPN) é uma extensão opcional do handshake TLS, usada pelo cliente e pelo servidor durante o handshake TLS para escolher o protocolo da Camada 7 que eles usarão na sessão criptografada estabelecida pelo handshake. O caso de uso mais comum do ALPN é negociar a atualização de HTTP/1. x para HTTP/2 para a sessão entre um navegador e um servidor web ou de aplicativo.

O NGINX Plus agora rejeita um handshake TLS se o cliente propõe um protocolo via ALPN que não corresponde ao contexto de configuração NGINX da sessão que está sendo estabelecida. Por exemplo, um servidor virtual definido no contexto http{} requer um ID de protocolo ALPN para HTTP, enquanto um servidor virtual no contexto mail{} requer um ID de protocolo para SMTP, POP ou IMAP.

O NGINX Plus R26 introduz a variável $ssl_alpn_protocol [ HTTP ][ Stream ] para capturar o protocolo negociado. (A variável $ssl_preread_alpn_protocols introduzida no contexto stream{} no NGINX Plus R15 ainda captura a lista de todos os protocolos anunciados pelo cliente durante o handshake.)

Este snippet define o formato de log alpn que usa $ssl_alpn_protocol para incluir o protocolo no campo alpn= de entradas no log de acesso.

 

A nova diretiva ssl_alpn no contexto stream{} define quais protocolos o NGINX Plus aceita. Omita a diretiva para permitir que o NGINX Plus considere todos os protocolos apresentados pelo cliente.

 

Melhorias no módulo JavaScript do NGINX

NGINX Plus R26 incorpora a versão0.7.2 do módulo NGINX JavaScript (njs) e inclui dois aprimoramentos:

Observação:  Esta seção pressupõe que você entenda as construções JavaScript para operações assíncronas e criptográficas. Uma análise completa dos trechos de código está fora do escopo deste blog.

[ Editor – Os casos de uso descritos nesta seção são apenas alguns dos muitos casos de uso do módulo NGINX JavaScript. Para uma lista completa, consulte Casos de uso para o módulo JavaScript NGINX . ]

Suporte aprimorado para funções assíncronas

Em muitas linguagens de script comumente usadas, como PHP, comandos e funções são executados de forma síncrona, ou seja, depois que um script invoca uma função, ele pausa (para de executar) até que a função retorne um resultado.

O JavaScript também pode operar de forma assíncrona: quando uma função é invocada de forma assíncrona, o script continua sendo executado sem esperar o resultado retornar da função.

Veja este exemplo de script:

 

Ele retorna uma resposta vazia porque o tempo de execução do njs não espera que os tempos limite definidos decorra (se esperasse, a saída seria b,a ):

$ curl http://127.0.0.1/ $ 

Lidar corretamente com operações assíncronas é obviamente crucial para obter o resultado pretendido. O JavaScript fornece várias maneiras de fazer isso, mas nos casos de uso comuns do NGINX, muitas vezes é desejável simplesmente encapsular uma função assíncrona de uma forma que torne o fluxo de execução síncrono. É aqui que o objeto Promise e as palavras-chave async e await entram em ação.

ECMAScript 6 (a sexta edição da especificação de linguagem ECMA‑262 para Javascript) define o objeto Promise como um tipo de retorno para funções assíncronas. Ele existe em um dos três estados:

  • cumprido – A operação foi concluída com sucesso
  • rejeitado – A operação falhou
  • pendente – O estado inicial (nem cumprido nem rejeitado)

Definir uma função JavaScript com a palavra-chave async define o tipo de retorno da função como Promise . As palavras-chave async e await são importantes quando você está escrevendo funções njs que lidam com objetos Promise .

Veja este exemplo:

 

A função fs.readFile (linha 12) retorna uma Promise . Ele é encapsulado em uma função assíncrona personalizada que garante que fs.readFile() seja invocado somente se o arquivo for chamado user.text . Devido à palavra-chave await , a função de encapsulamento aguarda a Promessa e retorna os dados.

Envolver fs.readFile() em outra função facilita a detecção de erros; qualquer exceção na função async define o estado da Promise como rejected . Outra maneira de fazer isso é substituir a linha 9 por uma instrução que retorna uma Promise rejeitada:

 

Você também pode trabalhar diretamente com objetos Promise . No exemplo a seguir, as funções Promise.resolve retornam uma Promise para cada um de p1 e p2 . A função Promise.all aguarda que as promessas de p1 e p2 sejam resolvidas antes de retornar um resultado.

 

Agora, a saída do nosso comando curl é o que queremos (observe que b é retornado primeiro devido ao menor valor de tempo limite):

$ curl http://127.0.0.1/ b,a $ 

Novas funções criptográficas com a API WebCrypto

O NGINX JavaScript agora tem acesso a recursos criptográficos aprimorados por meio da API WebCrypto . Os casos comuns de uso criptográfico do njs incluem:

  • Gerando números aleatórios seguros para IDs de sessão
  • Criptografar e descriptografar mensagens, dados e cookies
  • Criação ou validação de assinaturas digitais usando algoritmos criptográficos simétricos e assimétricos

Este código njs gera um número aleatório:

 

E esta configuração do NGINX Plus invoca o código njs:

 

A saída da função é um número aleatório mais ou menos assim:

$ ondulação 127.0.0.123225320050,3668407277,1101267190,2061939102,2687933029,2361833213,32543985,4162087386

A função getRandomValues no WebCrypto é um ótimo ponto de entrada para começar a usar números aleatórios seguros e o WebCrypto em geral. Sua implementação é bastante simples, e a função retorna resultados diretamente, em vez de retornar uma Promise .

No entanto, algumas das outras funções criptográficas mais intensivas do WebCrypto operam de forma assíncrona. Por exemplo, a documentação para сrypto.subtle.digest() afirma:

Gera um resumo dos dados fornecidos. Recebe como argumentos um identificador para o algoritmo de resumo a ser usado e os dados a serem resumidos. Retorna uma Promessa que será cumprida com o resumo.

Chamar сrypto.subtle.digest() diretamente, portanto, não garante que seu resultado estará disponível para a próxima etapa, a menos que esteja encapsulado em uma função assíncrona . Então aqui nós o envolvemos em uma função com as palavras-chave async e await para garantir que a variável hash seja preenchida com um resultado antes que a função retorne:

 

A diretiva js_set nesta configuração do NGINX Plus preenche a variável $hosthash com o valor retornado pela função setReturnValue (conforme encapsulado na função host_hash ):

 

Aqui está um exemplo que faz hash do nome do host example.com .

$ curl -H "Host: example.com" 127.0.0.1 # e8e624a82179b53b78364ae14d14d63dfeccd843b026bc8d959ffe0c39fc4ded1f4dcf4c8ebe871e657a12db6f11c3af87c9a1d4f2b096ba3deb56596f06b6f4

Outras melhorias no NGINX Plus R26

Suporte para a arquitetura IBM Z (s390x)

À medida que os aplicativos modernos colonizam todos os biomas digitais disponíveis, é importante que os componentes essenciais de suporte à vida, como o NGINX, viajem com eles. Por isso, temos o prazer de oferecer suporte ao NGINX Plus na arquitetura IBM Z (s390x) com CentOS 8.1+, RHEL 8.1+ e Ubuntu 20.04. As organizações que buscam hospedar aplicativos modernos em seus ativos de mainframe existentes agora podem implantar o NGINX e o NGINX Plus como um servidor web baseado em software, balanceador de carga, proxy reverso, cache de conteúdo e gateway de API.

Suporte TCP Half-Close no módulo Stream

A nova diretiva proxy_half_close permite o fechamento independente de cada direção de uma conexão TCP, para maior eficiência em contextos de fluxo .

Suporte à biblioteca PCRE2

Versões anteriores do NGINX Plus usam a biblioteca Perl Compatible Regular Expression (PCRE) (versão 1) para avaliar expressões regulares usadas na configuração do NGINX. Este importante projeto de código aberto chegou recentemente ao fim de sua vida útil, tendo sido substituído pelo PCRE2 . O NGINX Plus é criado com PCRE2, mas oferece suporte a módulos dinâmicos criados com PCRE e PCRE2, usando a versão disponível com o sistema operacional subjacente. Não são necessárias alterações de configuração.

Atualize ou experimente o NGINX Plus

Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para o NGINX Plus R26 o mais rápido possível. Você também receberá diversas correções e melhorias adicionais, e isso ajudará o NGINX a ajudar você quando precisar abrir um tíquete de suporte.

Se você ainda não experimentou o NGINX Plus, recomendamos que experimente – para segurança, balanceamento de carga e gateway de API, ou como um servidor web totalmente suportado com APIs aprimoradas de monitoramento e gerenciamento. Você pode começar hoje mesmo com um teste gratuito de 30 dias .


"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."