Anunciando o NGINX Plus R26

Robert HaynesGerente de Marketing Técnico

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 26 (R26). Baseado no NGINX Open Source, o NGINX Plus é o único software completo que reúne servidor web, 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 de JWT mais rápida com armazenamento em cache de conjuntos de chaves Web JSON – Dando continuidade à série de melhorias no suporte a JSON Web Tokens (JWT) adicionadas nas últimas versões, introduzimos o armazenamento em cache na memória de conjuntos de chaves Web JSON (JWKS), o que reduz substancialmente a sobrecarga da validação de JWT.
• Handshakes TLS reforçados – O NGINX Plus rejeita o handshake TLS se o cliente propuser, via ALPN, um protocolo de comunicação que não corresponda ao contexto de configuração do NGINX para a sessão que está sendo estabelecida (por exemplo, se propuser o protocolo de e-mail IMAP a um servidor virtual no contexto http{} ).
• Aprimoramentos no módulo JavaScript do NGINX – Agora há suporte a funções assíncronas que usam as palavras-chave async e await e o objeto Promise, e implementamos a API WebCrypto para operações criptográficas (como gerar números aleatórios ou criptografar cookies).

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

Mudanças importantes de comportamento

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

Conforme anunciado no lançamento do NGINX Plus R23, na versão 0.4.0 do módulo NGINX JavaScript, a diretiva js_import substituiu a diretiva js_include. A diretiva js_include foi descontinuada naquela ocasião e, a partir desta versão, não é mais compatível.

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 as funções referenciadas na configuração do NGINX. Siga estas etapas:

1. Edite os arquivos de configuração do NGINX. Por exemplo, altere:

js_set $foo myFunction;

1. para:

js_set $foo module_name.myFunction;

• Substitua js_include por js_import e anote o module_name implícito (o parâmetro de nome do arquivo JavaScript da diretiva, sem a extensão .js).
• Em cada diretiva que faz referência a uma função JavaScript, adicione o prefixo module_name ao nome da função. O nome da função é o primeiro parâmetro dessas diretivas. Ele é o segundo parâmetro da diretiva js_set[HTTP][Stream].
  • js_body_filter
  • js_content
  • js_filter
  • js_header_filter

1. Edite os arquivos JavaScript (module_name.js) que definem as funções referenciadas em um arquivo de configuração do NGINX. Adicione uma instrução export como a seguinte a cada arquivo, especificando as funções referenciadas.

export default { myFunction, otherFunction }

1. A instrução export pode aparecer em qualquer lugar no arquivo .js, mas, por convenção, ela é inserida 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 na ocasião, não está mais disponível no repositório de módulos do NGINX a partir desta versão.

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

A negociação TLS não oferece mais suporte ao protocolo NPN

A forma 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) do TLS foi o primeiro método usado para essa finalidade, mas agora é considerada obsoleta e foi substituída pela extensão Application-Layer Protocol Negotiation (ALPN), publicada como RFC 7301.

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

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

O antigo repositório de software do NGINX Plus não recebe mais atualizações

Com o lançamento do NGINX Plus R24, os repositórios de pacotes de todos os softwares NGINX foram reorganizados, o que resultou 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 repositório antigo plus-pkgs.nginx.com (sistemas que executam o NGINX Plus R23 ou uma versão anterior), você deverá atualizar o gerenciador de pacotes para que ele use o novo repositório pkgs.nginx.com/plus. Consulte as instruções na Base de conhecimento da F5.

Se estiver realizando uma instalação inicial do NGINX Plus R26, consulte Instalação do 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.

Alteração no acesso à especificação OpenAPI da API do NGINX Plus

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

Alterações no suporte a plataformas

Novos sistemas operacionais e arquiteturas compatíveis:

• Alpine Linux 3.15 (x86_64, arm64)
• A plataforma IBM Z (s390x) com CentOS 8.1+, RHEL 8.1+ e Ubuntu 20.04; consulte Suporte à arquitetura IBM Z s390x

Sistemas operacionais mais antigos removidos:

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

Sistemas operacionais e arquiteturas mais antigos, descontinuados e com remoção programada no NGINX Plus R27:

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

Novos recursos em detalhes

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

Ao validar JSON Web Tokens, o NGINX usa um JSON Web Key Set (JWKS) para verificar a assinatura do token ou descriptografá-lo. 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 um JWKS em cache na memória oferece vários benefícios:

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

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

Carregando exemplo de código…

Quando as JWKs são obtidas de um servidor externo, também recomendamos configurar o cache de conteúdo padrão e incluir a diretiva proxy_cache_use_stale, que instrui o NGINX Plus a continuar fornecendo um JWKS expirado enquanto ele é atualizado em segundo plano.

Carregando exemplo de código…

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

• Resiliência – O JWKS pode ser recuperado do cache mesmo após expirar. Isso aumenta a resiliência quando o provedor de JWKS está temporariamente indisponível, mas, em contrapartida, aumenta o risco de segurança.
• Efeito no servidor de autorização – A expiração de um JWKS armazenado em cache afeta o servidor de autorização de maneiras diferentes, dependendo de o cache de JWKS ser usado isoladamente ou em conjunto com o cache de conteúdo:
  • Ao usar apenas o cache de JWKS, todas as solicitações de autorização recebidas são encaminhadas ao servidor de autorização até que o cache seja preenchido novamente com uma nova versão do JWKS expirado. Se o servidor de autorização responder lentamente, poderá ocorrer um aumento repentino nas solicitações HTTP repetidas do JWKS. Essa carga adicional pode sobrecarregar o serviço de autorização, agravando o problema.
  • Quando o cache de conteúdo está habilitado com o fornecimento de JWKSs expirados, apenas uma solicitação do JWKS é encaminhada ao servidor de autenticação, enquanto as solicitações subsequentes ficam na fila até que o NGINX possa atendê-las após o preenchimento do cache de conteúdo. Isso reduz a demanda (e, consequentemente, o consumo de recursos) no serviço de autenticação.

Handshakes TLS reforçados

Os ataques contra o TLS, como o ALPACA, estão aumentando. Como parte do nosso compromisso contínuo com a defesa proativa contra exploits, 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 esse processo para escolher o protocolo da Camada 7 que será utilizado na sessão criptografada estabelecida pelo handshake. O caso de uso mais comum da ALPN é negociar a atualização de HTTP/1.x para HTTP/2 na sessão entre um navegador e um servidor web ou de aplicações.

O NGINX Plus agora rejeita um handshake TLS se o cliente propuser, via ALPN, um protocolo que não corresponda ao contexto de configuração do 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 apresenta 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 trecho define o formato de log alpn, que usa $ssl_alpn_protocol para incluir o protocolo no campo alpn= das entradas do log de acesso.

Carregando exemplo de código…

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.

Carregando exemplo de código…

Aprimoramentos do módulo JavaScript do NGINX

O NGINX Plus R26 incorpora a versão 0.7.2 do módulo JavaScript do NGINX (njs) e inclui duas melhorias:

• Suporte aprimorado a funções assíncronas com as palavras-chave async e await e o objeto Promise, introduzidos no ECMAScript 6
• Uma implementação da API WebCrypto

Observação: Esta seção pressupõe que você compreenda os recursos do 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 JavaScript do NGINX. Para ver uma lista completa, consulte Casos de uso do módulo JavaScript do NGINX.]

Suporte aprimorado a funções assíncronas

Em muitas linguagens de script amplamente utilizadas, como PHP, os comandos e as funções são executados de forma síncrona — ou seja, depois que um script chama uma função, ele é pausado (interrompe a execução) até que a função retorne um resultado.

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

Veja este exemplo de script:

Carregando exemplo de código…

Ele retorna uma resposta vazia porque o ambiente de execução do njs não aguarda o término dos tempos limite definidos (se aguardasse, 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 desejado. O JavaScript oferece várias maneiras de fazer isso, mas, nos casos de uso comuns do NGINX, muitas vezes é conveniente simplesmente encapsular uma função assíncrona de modo a tornar síncrono o fluxo de execução. É aí que entram em cena o objeto Promise e as palavras-chave async e await.

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 pode estar em um de três estados:

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

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 ao escrever funções njs que lidam com objetos Promise.

Veja este exemplo:

Carregando exemplo de código…

A função fs.readFile (linha 12) retorna uma Promise. Ela é encapsulada em uma função async personalizada que garante que fs.readFile() seja invocada somente se o arquivo se chamar user.text. Por causa da palavra-chave await, a função que a encapsula aguarda a resolução da Promise e retorna os dados.

Encapsular fs.readFile() em outra função facilita a captura 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 retorne uma Promise rejeitada:

Carregando exemplo de código…

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

Carregando exemplo de código…

Agora, a saída do nosso comando curl é a 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 avançados por meio da API WebCrypto. Os casos de uso criptográfico comuns do njs incluem:

• Geração de 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:

Carregando exemplo de código…

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

Carregando exemplo de código…

A saída da função é um número aleatório parecido com este:

$ curl 127.0.0.123225320050,3668407277,1101267190,2061939102,2687933029,2361833213,32543985,4162087386

A função getRandomValues da WebCrypto é um ótimo ponto de partida para começar a trabalhar com números aleatórios seguros e com a WebCrypto em geral. Sua implementação é bastante simples, e a função retorna os 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 de сrypto.subtle.digest() afirma:

Gera um resumo criptográfico dos dados fornecidos. Recebe como argumentos um identificador do algoritmo de resumo criptográfico a ser usado e os dados a serem processados. Retorna uma Promise que será resolvida com o resumo criptográfico.

Portanto, chamar сrypto.subtle.digest() diretamente não garante que o resultado estará disponível para a próxima etapa, a menos que a chamada esteja encapsulada em uma função async. Por isso, aqui a encapsulamos 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:

Carregando exemplo de código…

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

Carregando exemplo de código…

Veja um exemplo que gera o hash do nome do host example.com.

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

Outras melhorias no NGINX Plus R26

Suporte à arquitetura IBM Z (s390x)

À medida que as aplicações modernas colonizam todos os biomas digitais disponíveis, é importante que os componentes essenciais de suporte à vida — como o NGINX — as acompanhem. 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 desejam hospedar aplicações modernas em seus ativos de mainframe existentes agora podem implantar o NGINX e o NGINX Plus como servidor web baseado em software, balanceador de carga, proxy reverso, cache de conteúdo e gateway de API.

Suporte a conexões TCP semiabertas no módulo Stream

A nova diretiva proxy_half_close permite encerrar de forma independente cada direção de uma conexão TCP, proporcionando maior eficiência em contextos stream{}.

Suporte à biblioteca PCRE2

As versões anteriores do NGINX Plus usam a biblioteca de expressões regulares compatíveis com Perl (PCRE) (versão 1) para avaliar as expressões regulares usadas na configuração do NGINX. Esse importante projeto de código aberto chegou recentemente ao fim de sua vida útil e foi substituído pelo PCRE2. O NGINX Plus é compilado com o PCRE2, mas oferece suporte a módulos dinâmicos compilados tanto com o PCRE quanto com o PCRE2, usando a versão disponível no sistema operacional subjacente. Não é necessário fazer nenhuma alteração na configuração.

Atualize ou experimente o NGINX Plus

Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para o NGINX Plus R26 o mais rápido possível. Você também terá acesso a várias correções e melhorias adicionais, além de facilitar o suporte da NGINX quando precisar abrir um chamado.

Se você ainda não experimentou o NGINX Plus, recomendamos que o teste – para segurança, balanceamento de carga e gateway de API, ou como um servidor web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Você pode começar hoje mesmo com uma avaliação gratuita de 30 dias.

Sobre o autor

Robert HaynesGerente de Marketing Técnico

Mais publicações de Robert Haynes