BLOG | NGINX

Anunciamos NGINX Plus R26

NGINX - Parte de F5 - horizontal, negro, tipo RGB
Robert Haynes Miniatura
Robert Haynes
Publicado el 15 de febrero de 2022

Nos complace anunciar la disponibilidad de NGINX Plus Release 26 (R26) . Basado en NGINX de código abierto, NGINX Plus es el único servidor web de software todo en uno , balanceador de carga, proxy inverso, caché de contenido y puerta de enlace API.

Las características nuevas y mejoradas de NGINX Plus R26 incluyen:

  • Validación de JWT más rápida con almacenamiento en caché de conjuntos de claves web JSON : continuando con la serie de mejoras en la compatibilidad de tokens web JSON (JWT) agregadas en las últimas versiones, presentamos el almacenamiento en caché en memoria de conjuntos de claves web JSON (JWKS), que reduce sustancialmente la sobrecarga de la validación de JWT.
  • Protocolos de enlace TLS reforzados : NGINX Plus rechaza el protocolo de enlace TLS si el cliente propone un protocolo de comunicación a través de ALPN que no coincide con el contexto de configuración de NGINX para la sesión que se está estableciendo (por ejemplo, propone el protocolo de correo electrónico IMAP a un servidor virtual en el contexto http{} ).
  • Mejoras en el módulo JavaScript de NGINX : ahora se admiten funciones asincrónicas que utilizan las palabras clave async y await y el objeto Promise , y hemos implementado la API WebCrypto para operaciones criptográficas (como generar números aleatorios o cifrar cookies).

Para completar esta versión se incluyen el soporte para la arquitectura IBM System Z (s390x) , la capacidad de cerrar cada dirección de una conexión TCP de forma independiente y el soporte para la versión 2 de la biblioteca Perl Compatible Regular Expression (PCRE).

Cambios importantes en el comportamiento

El módulo JavaScript de NGINX ya no admite js_include

Como se anunció en el lanzamiento de NGINX Plus R23 , en la versión0.4.0 del módulo JavaScript de NGINX, la directiva js_import reemplazó la directiva js_include . La directiva js_include quedó obsoleta en ese momento y a partir de esta versión ya no recibe soporte.

Antes de actualizar a NGINX Plus R26 , reemplace js_include con js_import en los archivos de configuración de NGINX y también agregue una declaración de exportación a los archivos JavaScript para las funciones a las que se hace referencia en la configuración de NGINX. Siga estos pasos:

  1. Editar archivos de configuración de NGINX:

    • Reemplace js_include con js_import y tome nota del module_name implícito (el parámetro de nombre de archivo JavaScript para la directiva, sin la extensión .js ).

    • En cada directiva que haga referencia a una función de JavaScript, anteponga el nombre de la función con module_name . El nombre de la función es el primer parámetro de estas directivas:

      Es el segundo parámetro de la directiva js_set [ HTTP ][ Stream ].

    Por ejemplo, cambiar:

    js_set $foo miFuncion;

    a:

    js_set $foo nombre_del_módulo .myFunction;

  2. Edite los archivos JavaScript ( module_name .js ) que definen funciones referenciadas en un archivo de configuración NGINX. Agregue una declaración de exportación como la siguiente a cada archivo, nombrando las funciones referenciadas.

    exportar predeterminado { miFunción, otraFunción }

    La declaración de exportación puede aparecer en cualquier parte del archivo .js , pero por convención se coloca directamente encima de las funciones o al final del archivo.

El módulo Cookie-Flag está obsoleto

El módulo de terceros Cookie-Flag quedó obsoleto en NGINX Plus R23 y, como se anunció en ese momento, ya no está disponible en el repositorio de módulos NGINX a partir de esta versión.

Antes de actualizar a NGINX Plus R26 , edite su configuración de NGINX para reemplazar cualquier ocurrencia de la directiva set_cookie_flag (definida en el módulo obsoleto) con la directiva proxy_cookie_flags incorporada.

La negociación TLS ya no admite el protocolo NPN

Se ha actualizado la forma en que NGINX establece conexiones TLS y HTTP/2. Como parte del protocolo de enlace TLS entre NGINX y un cliente (generalmente un navegador), negocian qué protocolo de comunicación se utilizará en la sesión establecida por el protocolo de enlace (la mayoría de las veces, la negociación actualiza la sesión de HTTP 1. x a HTTP/2). La extensión Next Protocol Negotiation (NPN) de TLS fue el primer método utilizado para este propósito, pero NPN ahora se considera obsoleto y ha sido reemplazado por la extensión Aplicação-Layer Protocol Negotiation (ALPN), publicada como RFC 7301 .

NGINX Plus R26 ya no admite NPN, por lo que los clientes ahora deben usar ALPN exclusivamente.

Además, nuestra implementación de ALPN se ha ampliado y reforzado: consulte Protocolos de enlace TLS reforzados .

El antiguo repositorio de software NGINX Plus ya no se actualiza

Con el lanzamiento de NGINX Plus R24 , se reorganizaron los repositorios de paquetes para todo el software NGINX, lo que resultó en cambios en el procedimiento de instalación de NGINX Plus.

Cuando instala o actualiza NGINX Plus, el administrador de paquetes del sistema operativo ( apt , yum o equivalente) se configura con el repositorio de software para NGINX Plus.

Si actualiza a NGINX Plus R26 en un sistema existente configurado para usar el antiguo repositorio plus-pkgs.nginx.com (aquellos que ejecutan NGINX Plus R23 o anterior), debe actualizar el administrador de paquetes para hacer referencia al nuevo repositorio pkgs.nginx.com/plus . Consulte las instrucciones en la Base de conocimientos de F5 .

Si realiza una instalación inicial de NGINX Plus R26 , consulte Instalación de NGINX Plus en la Guía de administración de NGINX Plus .

NGINX Plus R26 no está disponible en el repositorio antiguo , que no recibirá más actualizaciones.

Se modificó el acceso a la especificación OpenAPI para la API NGINX Plus

El paquete de software NGINX Plus ya no incluye la especificación OpenAPI en formato YAML ni la interfaz de usuario Swagger para la API de NGINX Plus . Ahora puede acceder a ellos en la Guía de administración de NGINX Plus .

Cambios en el soporte de la plataforma

Nuevos sistemas operativos y arquitecturas compatibles:

Sistemas operativos más antiguos eliminados:

  • Alpine Linux 3.11 (la versión compatible más antigua es la 3.12)

Sistemas operativos y arquitecturas más antiguos obsoletos y programados para su eliminación en NGINX Plus R27 :

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

Nuevas funciones en detalle

Validación JWT más rápida con almacenamiento en caché de conjuntos de claves web JSON

Al validar tokens web JSON, NGINX utiliza un conjunto de claves web JSON (JWKS) para verificar la firma del token o descifrarlo. Los JWKS pueden almacenarse en archivos de configuración u obtenerse de servicios externos a través de una solicitud HTTP. Además, almacenar en caché un JWKS en la memoria tiene varios beneficios:

  • Reducción significativa en el uso de la CPU
  • Latencia de solicitud reducida
  • Optimización de la validación de JWT, porque como parte del proceso de almacenamiento en caché, las claves JWKS se convierten de JSON a un formato binario optimizado para operaciones criptográficas.

Para almacenar en caché los JWKS en la memoria, incluya la nueva directiva auth_jwt_key_cache y especifique el tiempo de vencimiento para cada conjunto de claves (en este ejemplo, 3 horas):

 

Cuando los JWK se obtienen de un servidor externo, también recomendamos configurar el almacenamiento en caché de contenido estándar e incluir la directiva proxy_cache_use_stale , que le indica a NGINX Plus que continúe sirviendo un JWK vencido mientras se actualiza en segundo plano.

 

Los beneficios del almacenamiento en caché de contenido además del almacenamiento en caché JWKS son dobles:

  • Resiliencia : los JWKS se pueden recuperar de la memoria caché incluso cuando haya expirado. Esto aumenta la resiliencia cuando el proveedor JWKS no está disponible temporalmente, pero implica un mayor riesgo de seguridad.

  • Efecto en el servidor de autorización : la expiración de un JWKS almacenado en caché afecta al servidor de autorización de manera diferente según si el almacenamiento en caché de JWKS se utiliza solo o en combinación con el almacenamiento en caché de contenido:

    • Con el almacenamiento en caché de JWKS únicamente, todas las solicitudes de autorización entrantes se reenvían al servidor de autenticación hasta que el caché se vuelve a llenar con una nueva versión del JWKS vencido. Si el servidor de autenticación responde lentamente, puede haber un aumento repentino en las solicitudes HTTP repetidas para JWKS. Esta carga adicional podría saturar el servicio de autenticación, empeorando el problema.

    • Cuando el almacenamiento en caché de contenido está habilitado con el servicio de JWKS vencidos, solo se envía una solicitud de JWKS al servidor de autenticación y las solicitudes posteriores se ponen en cola hasta que NGINX pueda satisfacerlas después de que se complete el caché de contenido . Esto genera una menor demanda (y, por lo tanto, un menor consumo de recursos) en el servicio de autenticación.

Protocolos de enlace TLS reforzados

Los ataques contra TLS, como ALPACA , están aumentando. Como parte de nuestro compromiso continuo con la defensa proactiva contra exploits, hemos reforzado el manejo de las conexiones TLS por parte de NGINX.

La negociación de protocolo de capa de aplicação(ALPN) es una extensión opcional del protocolo de enlace TLS, utilizada por el cliente y el servidor durante el protocolo de enlace TLS para elegir el protocolo de capa 7 que utilizarán en la sesión cifrada establecida por el protocolo de enlace. El caso de uso más común de ALPN es negociar la actualización de HTTP/1. x a HTTP/2 para la sesión entre un navegador y un servidor web o de aplicaciones.

NGINX Plus ahora rechaza un protocolo de enlace TLS si el cliente propone un protocolo a través de ALPN que no coincide con el contexto de configuración de NGINX de la sesión que se está estableciendo. Por ejemplo, un servidor virtual definido en el contexto http{} requiere un ID de protocolo ALPN para HTTP, mientras que un servidor virtual en el contexto mail{} requiere un ID de protocolo para SMTP, POP o IMAP.

NGINX Plus R26 presenta la variable $ssl_alpn_protocol [ HTTP ][ Stream ] para capturar el protocolo negociado. (La variable $ssl_preread_alpn_protocols introducida en el contexto stream{} en NGINX Plus R15 aún captura la lista de todos los protocolos anunciados por el cliente durante el protocolo de enlace).

Este fragmento define el formato de registro alpn que utiliza $ssl_alpn_protocol para incluir el protocolo en el campo alpn= de las entradas en el registro de acceso.

 

La nueva directiva ssl_alpn en el contexto stream{} define qué protocolos acepta NGINX Plus. Omita la directiva para permitir que NGINX Plus considere todos los protocolos presentados por el cliente.

 

Mejoras del módulo JavaScript de NGINX

NGINX Plus R26 incorpora la versión0.7.2 del módulo JavaScript de NGINX (njs) e incluye dos mejoras:

Nota:  Esta sección asume que usted comprende las construcciones de JavaScript para operaciones asincrónicas y criptográficas. Un análisis completo de los fragmentos de código está fuera del alcance de este blog.

[ Editor : Los casos de uso descritos en esta sección son solo algunos de los muchos casos de uso del módulo JavaScript de NGINX. Para obtener una lista completa, consulte Casos de uso del módulo JavaScript NGINX . ]

Soporte mejorado para funciones asincrónicas

En muchos lenguajes de scripting de uso común como PHP, los comandos y funciones se ejecutan de manera sincrónica, es decir, después de que un script invoca una función, se pausa (deja de ejecutarse) hasta que la función devuelve un resultado.

JavaScript también puede funcionar de forma asincrónica: cuando se invoca una función de forma asincrónica, el script continúa ejecutándose sin esperar a que la función regrese el resultado.

Tome este ejemplo de guión:

 

Devuelve una respuesta vacía porque el entorno de ejecución de njs no espera a que transcurran los tiempos de espera definidos (si esperara, la salida sería b,a ):

$ curl http://127.0.0.1/ $

Manejar correctamente las operaciones asincrónicas obviamente es crucial para obtener el resultado deseado. JavaScript proporciona varias maneras de hacer esto, pero en los casos de uso comunes de NGINX, a menudo es deseable simplemente envolver una función asincrónica de una manera que haga que el flujo de ejecución sea sincrónico. Aquí es donde el objeto Promise y las palabras clave async y await entran en juego.

ECMAScript 6 (la sexta edición de la especificación del lenguaje ECMA‑262 para JavasScript) define el objeto Promise como un tipo de retorno para funciones asincrónicas. Existe en uno de tres estados:

  • Cumplido – La operación se completó con éxito
  • rechazado – La operación falló
  • pendiente – El estado inicial (ni cumplido ni rechazado)

Definir una función de JavaScript con la palabra clave async establece el tipo de retorno de la función en Promise . Las palabras claves async y await son importantes cuando escribes funciones njs que tratan con objetos Promise .

Tomemos este ejemplo:

 

La función fs.readFile (línea 12) devuelve una Promesa . Está envuelto en una función asíncrona personalizada que garantiza que fs.readFile() se invoque solo si el archivo se llama user.text . Debido a la palabra clave await , la función de envoltura espera la Promesa y devuelve los datos.

Envolver fs.readFile() en otra función hace que sea más fácil capturar errores; cualquier excepción en la función async establece el estado de la Promesa en rechazada . Otra forma de hacer esto es reemplazar la línea 9 con una declaración que devuelva una Promesa rechazada:

 

También puedes trabajar directamente con objetos Promise . En el siguiente ejemplo, las funciones Promise.resolve devuelven una Promesa para cada uno de p1 y p2 . La función Promise.all espera a que se resuelvan las promesas de p1 y p2 antes de devolver un resultado.

 

Ahora la salida de nuestro comando curl es la que queremos (tenga en cuenta que b se devuelve primero debido al valor de tiempo de espera más corto):

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

Nuevas funciones criptográficas con la API WebCrypto

JavaScript de NGINX ahora tiene acceso a capacidades criptográficas mejoradas a través de la API WebCrypto . Algunos ejemplos comunes de uso criptográfico de NJS incluyen:

  • Generación de números aleatorios seguros para identificadores de sesión
  • Cifrado y descifrado de mensajes, datos y cookies
  • Creación o validación de firmas digitales utilizando algoritmos criptográficos simétricos y asimétricos

Este código njs genera un número aleatorio:

 

Y esta configuración de NGINX Plus invoca el código njs:

 

La salida de la función es un número aleatorio parecido a esto:

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

La función getRandomValues en WebCrypto es un excelente punto de entrada para comenzar a utilizar números aleatorios seguros y WebCrypto en general. Su implementación es bastante simple y la función devuelve resultados directamente, en lugar de devolver una Promesa .

Sin embargo, algunas de las otras funciones criptográficas más intensivas de WebCrypto funcionan de forma asincrónica. Por ejemplo, la documentación de сrypto.subtle.digest() establece:

Genera un resumen de los datos proporcionados. Toma como argumentos un identificador para el algoritmo de resumen a utilizar y los datos a digerir. Devuelve una promesa que se cumplirá con el resumen.

Por lo tanto, llamar a сrypto.subtle.digest() directamente no garantiza que su resultado esté disponible para el siguiente paso, a menos que esté envuelto en una función asíncrona . Entonces, aquí lo envolvemos en una función con las palabras claves async y await para garantizar que la variable hash se complete con un resultado antes de que la función regrese:

 

La directiva js_set en esta configuración de NGINX Plus llena la variable $hosthash con el valor devuelto por la función setReturnValue (tal como está envuelto en la función host_hash ):

 

A continuación se muestra un ejemplo que convierte el nombre de host example.com en hashes.

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

Otras mejoras en NGINX Plus R26

Compatibilidad con la arquitectura IBM Z (s390x)

A medida que las aplicações modernas colonizan cada bioma digital disponible, es importante que los componentes esenciales de soporte vital, como NGINX, viajen con ellas, por eso nos complace brindar soporte a NGINX Plus en la arquitectura IBM Z (s390x) con CentOS 8.1+, RHEL 8.1+ y Ubuntu 20.04. Las organizaciones que buscan alojar aplicações modernas en sus activos de mainframe existentes ahora pueden implementar NGINX y NGINX Plus como un servidor web basado en software, balanceador de carga, proxy inverso, caché de contenido y puerta de enlace API.

Compatibilidad con TCP Half-Close en el módulo Stream

La nueva directiva proxy_half_close permite el cierre independiente de cada dirección de una conexión TCP, para mayor eficiencia en contextos stream{} .

Soporte de la biblioteca PCRE2

Las versiones anteriores de NGINX Plus utilizan la biblioteca Perl Compatible Regular Expression (PCRE) (versión 1) para evaluar expresiones regulares utilizadas en la configuración de NGINX. Este importante proyecto de código abierto ha llegado recientemente al final de su vida útil, reemplazado por PCRE2 . NGINX Plus está construido con PCRE2, pero admite módulos dinámicos construidos con PCRE y PCRE2, utilizando la versión disponible con el sistema operativo subyacente. No se requieren cambios de configuración.

Actualice o pruebe NGINX Plus

Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R26 lo antes posible. También recibirás varias correcciones y mejoras adicionales, y ayudará a NGINX a ayudarte cuando necesites generar un ticket de soporte.

Si aún no ha probado NGINX Plus, le recomendamos que lo haga por cuestiones de seguridad, equilibrio de carga y puerta de enlace de API, o como servidor web totalmente compatible con API de administración y monitoreo mejoradas. Puede comenzar hoy con una prueba gratuita de 30 días .

Leer más publicaciones de blog sobre F5 NGINX ›

"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.