Presentamos NGINX Plus R26

Robert HaynesResponsable de marketing técnico

Nos complace anunciar la disponibilidad de NGINX Plus Release 26 (R26). Basado en NGINX Open Source, NGINX Plus es el único servidor web de software todo en uno que también funciona como equilibrador de carga, proxy inverso, caché de contenido y puerta de enlace de API.

Entre las funciones nuevas y mejoradas de NGINX Plus R26 se incluyen:

• Validación de JWT más rápida gracias al almacenamiento en caché de conjuntos de claves web JSON – Como continuación de la serie de mejoras en la compatibilidad con los tokens web JSON (JWT) incorporadas en las últimas versiones, presentamos el almacenamiento en caché en memoria de conjuntos de claves web JSON (JWKS), que reduce considerablemente la sobrecarga de la validación de JWT.
• Negociaciones TLS reforzadas – NGINX Plus rechaza la negociación TLS si el cliente propone mediante ALPN un protocolo de comunicación que no coincide con el contexto de configuración de NGINX para la sesión que se está estableciendo (por ejemplo, si 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 las funciones asíncronas que utilizan las palabras clave async y await, así como el objeto Promise, y hemos implementado la API WebCrypto para realizar operaciones criptográficas (como generar números aleatorios o cifrar cookies).

Para completar esta versión se incluyen la compatibilidad con la arquitectura IBM System Z (s390x), la posibilidad de cerrar de forma independiente cada sentido de una conexión TCP y la compatibilidad con la versión 2 de la biblioteca de expresiones regulares compatibles con Perl (PCRE).

Cambios importantes de comportamiento

El módulo JavaScript de NGINX ya no admite js_include

Tal como se anunció con el lanzamiento de NGINX Plus R23, en la versión 0.4.0 del módulo JavaScript de NGINX, la directiva js_import sustituyó a la directiva js_include. La directiva js_include quedó obsoleta en ese momento y, a partir de esta versión, ya no es compatible.

Antes de actualizar a NGINX Plus R26, sustituya js_include por js_import en los archivos de configuración de NGINX y añada también una instrucción export a los archivos JavaScript para las funciones a las que se hace referencia en la configuración de NGINX. Siga estos pasos:

1. Edite los archivos de configuración de NGINX. Por ejemplo, cambie:

js_set $foo myFunction;

1. a:

js_set $foo module_name.myFunction;

• Sustituya js_include por js_import y anote el module_name implícito (el parámetro de nombre de archivo JavaScript de la directiva, sin la extensión .js).
• En cada directiva que haga referencia a una función de JavaScript, anteponga al nombre de la función el 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].
  • js_body_filter
  • js_content
  • js_filter
  • js_header_filter

1. Edite los archivos JavaScript (module_name.js) que definen las funciones a las que se hace referencia en un archivo de configuración de NGINX. Añada una instrucción export como la siguiente a cada archivo, indicando las funciones referenciadas.

export default { myFunction, otherFunction }

1. La sentencia export puede aparecer en cualquier parte del archivo .js, pero, por convención, se coloca justo 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, tal como se anunció en aquel momento ya no está disponible en el repositorio de módulos de NGINX a partir de esta versión.

Antes de actualizar a NGINX Plus R26, edite la configuración de NGINX para sustituir todas las apariciones de la directiva set_cookie_flag (definida en el módulo obsoleto) por la directiva integrada proxy_cookie_flags.

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 (normalmente un navegador), ambos negocian qué protocolo de comunicación se utilizará en la sesión establecida mediante dicho protocolo de enlace (en la mayoría de los casos, 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 fin, pero actualmente NPN se considera obsoleta y ha sido sustituida por la extensión Application-Layer Protocol Negotiation (ALPN), publicada como RFC 7301.

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

Además, hemos ampliado y reforzado nuestra implementación de ALPN. Consulte «Refuerzo de los protocolos de enlace TLS».

El antiguo repositorio de software de NGINX Plus ya no se actualiza

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

Al instalar o actualizar NGINX Plus, el gestor de paquetes del sistema operativo (apt, yum o equivalente) se configura con el repositorio de software de NGINX Plus.

Si actualiza a NGINX Plus R26 en un sistema existente configurado para usar el repositorio antiguo plus-pkgs.nginx.com (es decir, uno que ejecute NGINX Plus R23 o una versión anterior), debe actualizar el gestor de paquetes para que haga referencia al nuevo repositorio pkgs.nginx.com/plus. Consulte las instrucciones en la base de conocimientos de F5.

Si va a realizar 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.

Cambio en el acceso a la especificación OpenAPI de la API de NGINX Plus

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

Cambios en la compatibilidad con plataformas

Nuevos sistemas operativos y arquitecturas compatibles:

• Alpine Linux 3.15 (x86_64, arm64)
• La plataforma IBM Z (s390x) con CentOS 8.1+, RHEL 8.1+ y Ubuntu 20.04; consulte Compatibilidad con la arquitectura IBM Z s390x

Sistemas operativos antiguos eliminados:

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

Sistemas operativos y arquitecturas antiguos obsoletos y cuya eliminación está prevista en NGINX Plus R27:

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

Nuevas funcionalidades en detalle

Validación de JWT más rápida gracias al 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 mediante una solicitud HTTP. Además, almacenar un JWKS en la memoria caché ofrece varias ventajas:

• Reducción significativa del uso de la CPU
• Reducción de la latencia de las solicitudes
• Optimización de la validación de JWT, ya que, 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 los JWKS en la memoria caché, incluya la nueva directiva auth_jwt_key_cache y especifique el tiempo de expiración de cada conjunto de claves (en este ejemplo, 3 horas):

Cargando ejemplo de código…

Cuando las JWK se obtienen de un servidor externo, también recomendamos configurar el almacenamiento en caché de contenido e incluir la directiva proxy_cache_use_stale, que indica a NGINX Plus que siga sirviendo un JWKS caducado mientras se actualiza en segundo plano.

Cargando ejemplo de código…

Las ventajas de almacenar en caché el contenido, además de las JWKS, son dos:

• Resiliencia – Las JWKS se pueden recuperar de la caché incluso después de que hayan caducado. Esto aumenta la resiliencia cuando el proveedor de JWKS no está disponible temporalmente, pero conlleva un mayor riesgo de seguridad.
• Efecto en el servidor de autorización – La caducidad de un JWKS almacenado en caché afecta al servidor de autorización de forma diferente en función de si el almacenamiento en caché de JWKS se utiliza por sí solo o junto con el almacenamiento en caché de contenido:
  • Si solo se utiliza el almacenamiento en caché de JWKS, todas las solicitudes de autorización entrantes se reenvían al servidor de autorización hasta que la caché vuelve a llenarse con una nueva versión del JWKS caducado. Si el servidor de autorización responde lentamente, puede producirse un aumento repentino de las solicitudes HTTP repetidas del JWKS. Esta carga adicional podría saturar el servicio de autorización y agravar el problema.
  • Cuando se habilita el almacenamiento en caché de contenido y se permite servir JWKS caducados, solo se reenvía al servidor de autenticación una solicitud del JWKS, mientras que las solicitudes posteriores quedan en cola hasta que NGINX pueda atenderlas una vez que se haya rellenado la caché de contenido. Esto reduce la demanda (y, por tanto, el consumo de recursos) del servicio de autenticación.

Negociaciones TLS reforzadas

Los ataques contra TLS, como ALPACA, están aumentando. Como parte de nuestro compromiso continuo con la defensa proactiva frente a vulnerabilidades, hemos reforzado la gestión de las conexiones TLS por parte de NGINX.

La negociación de protocolos de la capa de aplicación (ALPN) es una extensión opcional del protocolo de enlace TLS que el cliente y el servidor utilizan durante dicho proceso para elegir el protocolo de capa 7 que usarán en la sesión cifrada establecida mediante el protocolo de enlace. El uso más habitual 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 el protocolo de enlace TLS si el cliente propone mediante ALPN un protocolo 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 identificador de protocolo ALPN para HTTP, mientras que un servidor virtual en el contexto mail{} requiere un identificador de protocolo para SMTP, POP o IMAP.

NGINX Plus R26 incorpora 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 sigue capturando 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 del registro de acceso.

Cargando ejemplo de código…

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

Cargando ejemplo de código…

Mejoras del módulo JavaScript de NGINX

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

• Compatibilidad mejorada con funciones asíncronas mediante las palabras clave async y await, así como el objeto Promise, introducidos en ECMAScript 6
• Una implementación de la API WebCrypto

Nota: En esta sección se presupone que comprende las estructuras de JavaScript para realizar operaciones asíncronas y criptográficas. Un análisis completo de los fragmentos de código queda 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 consultar una lista completa, consulte Casos de uso del módulo JavaScript de NGINX.]

Compatibilidad mejorada con funciones asíncronas

En muchos lenguajes de scripting de uso habitual, como PHP, los comandos y las funciones se ejecutan de forma síncrona; es decir, cuando un script invoca una función, se pausa (detiene su ejecución) hasta que la función devuelve un resultado.

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

Veamos este script de ejemplo:

Cargando ejemplo de código…

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/
$ 

Gestionar correctamente las operaciones asíncronas es, obviamente, fundamental para obtener el resultado deseado. JavaScript ofrece varias formas de hacerlo, pero, en los casos de uso habituales de NGINX, a menudo resulta conveniente encapsular una función asíncrona de modo que el flujo de ejecución sea síncrono. Aquí es donde entran en juego el objeto «Promise» y las palabras clave «async» y «await».

ECMAScript 6 (la sexta edición de la especificación del lenguaje ECMA‑262 para JavasScript) define el objeto Promise como tipo de retorno para las funciones asíncronas. Puede encontrarse en uno de estos tres estados:

• cumplida – La operación se completó correctamente
• rechazada – La operación ha fallado
• pendiente – El estado inicial (ni cumplida ni rechazada)

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

Veamos este ejemplo:

Cargando ejemplo de código…

La función fs.readFile (línea 12) devuelve una Promise. Está encapsulada en una función async personalizada que garantiza que fs.readFile() solo se invoque si el archivo se llama user.text. Debido a la palabra clave await, la función contenedora espera a que se resuelva la Promise y devuelve los datos.

Encapsular fs.readFile() en otra función facilita la captura de errores; cualquier excepción en la función async establece el estado de la Promise como rejected. Otra forma de hacerlo es sustituir la línea 9 por una instrucción que devuelva una Promise rechazada:

Cargando ejemplo de código…

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

Cargando ejemplo de código…

Ahora, la salida de nuestro comando curl es la que queremos (ten en cuenta que b se devuelve primero debido al menor tiempo de espera):

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

Nuevas funciones criptográficas con la API WebCrypto

NGINX JavaScript ahora dispone de funciones criptográficas avanzadas a través de la API WebCrypto. Entre los casos de uso criptográfico habituales de njs se incluyen:

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

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

Cargando ejemplo de código…

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

Cargando ejemplo de código…

La función devuelve un número aleatorio similar a este:

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

La función getRandomValues de WebCrypto es un excelente punto de partida para iniciarse en el uso de números aleatorios seguros y de WebCrypto en general. Su implementación es bastante sencilla y devuelve los resultados directamente, en lugar de devolver una Promise.

Sin embargo, algunas de las otras funciones criptográficas de WebCrypto que requieren más recursos funcionan de forma asíncrona. Por ejemplo, la documentación de сrypto.subtle.digest() indica lo siguiente:

Genera un resumen de los datos proporcionados. Recibe como argumentos un identificador del algoritmo de resumen que se va a utilizar y los datos cuyo resumen se desea calcular. Devuelve una Promise que se resolverá con el resumen.

Por lo tanto, llamar directamente a сrypto.subtle.digest() no garantiza que su resultado esté disponible para el siguiente paso, a menos que se incluya en una función async. Así que aquí lo incluimos en una función con las palabras clave async y await para garantizar que la variable hash contenga un resultado antes de que la función devuelva el control:

Cargando ejemplo de código…

La directiva js_set de esta configuración de NGINX Plus asigna a la variable $hosthash el valor devuelto por la función setReturnValue (encapsulada en la función host_hash):

Cargando ejemplo de código…

Este es un ejemplo que genera un hash del nombre de host «example.com».

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

Otras mejoras de NGINX Plus R26

Compatibilidad con la arquitectura IBM Z (s390x)

A medida que las aplicaciones modernas colonizan todos los biomas digitales disponibles, es importante que los componentes esenciales de soporte vital —como NGINX— las acompañen. Por eso, nos complace ofrecer compatibilidad con NGINX Plus en la arquitectura IBM Z (s390x) con CentOS 8.1+, RHEL 8.1+ y Ubuntu 20.04. Las organizaciones que deseen alojar aplicaciones modernas en sus actuales sistemas mainframe ya pueden implementar NGINX y NGINX Plus como servidor web basado en software, equilibrador de carga, proxy inverso, caché de contenido y puerta de enlace de API.

Compatibilidad con el cierre parcial de TCP en el módulo Stream

La nueva directiva «proxy_half_close» permite cerrar de forma independiente cada sentido de una conexión TCP, lo que mejora la eficiencia en contextos stream{}.

Compatibilidad con la biblioteca PCRE2

Las versiones anteriores de NGINX Plus utilizan la biblioteca de expresiones regulares compatibles con Perl (PCRE) (versión 1) para evaluar las 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 y ha sido sustituido por PCRE2. NGINX Plus se compila con PCRE2, pero admite módulos dinámicos compilados tanto con PCRE como con PCRE2, utilizando la versión disponible en el sistema operativo subyacente. No es necesario realizar ningún cambio en la configuración.

Actualice o pruebe NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R26 lo antes posible. También obtendrá varias correcciones y mejoras adicionales, y facilitará que NGINX pueda ayudarle cuando necesite abrir una incidencia de soporte.

Si aún no ha probado NGINX Plus, le animamos a hacerlo, ya sea para seguridad, balanceo de carga y puerta de enlace de API, o como servidor web con soporte completo y API avanzadas de supervisión y gestión. Puede empezar hoy mismo con una prueba gratuita de 30 días.

Sobre el autor

Robert HaynesResponsable de marketing técnico

Más artículos de Robert Haynes