Annonce de NGINX Plus R26

Nous sommes heureux d'annoncer la disponibilité de NGINX Plus Release 26 (R26) . Basé sur NGINX Open Source, NGINX Plus est le seul serveur Web logiciel tout-en-un , équilibreur de charge, proxy inverse, cache de contenu et passerelle API.

Les fonctionnalités nouvelles et améliorées de NGINX Plus R26 incluent :

• Validation JWT plus rapide avec la mise en cache des ensembles de clés Web JSON – Poursuivant la série d’améliorations apportées à la prise en charge des jetons Web JSON (JWT) ajoutées au cours des dernières versions, nous introduisons la mise en cache en mémoire des ensembles de clés Web JSON (JWKS), ce qui réduit considérablement la surcharge de validation JWT.
• Poignées de main TLS renforcées – NGINX Plus rejette la poignée de main TLS si le client propose un protocole de communication via ALPN qui ne correspond pas au contexte de configuration NGINX pour la session en cours d'établissement (par exemple, propose le protocole de messagerie IMAP à un serveur virtuel dans le contexte http{} ).
• Améliorations apportées au module JavaScript NGINX – Les fonctions asynchrones qui utilisent les mots-clés async et wait et l’objet Promise sont désormais prises en charge, et nous avons implémenté l’API WebCrypto pour les opérations cryptographiques (comme la génération de nombres aléatoires ou le cryptage des cookies).

Cette version est complétée par la prise en charge de l'architecture IBM System Z (s390x) , la possibilité de fermer chaque direction d'une connexion TCP indépendamment et la prise en charge de la version 2 de la bibliothèque Perl Compatible Regular Expression (PCRE).

Changements importants dans le comportement

Le module JavaScript NGINX ne prend plus en charge js_include

Comme annoncé lors de la sortie de NGINX Plus R23 , en version0.4.0 du module JavaScript NGINX, la directive js_import a remplacé la directive js_include . La directive js_include était obsolète à cette époque et n'est plus prise en charge à partir de cette version.

Avant de procéder à la mise à niveau vers NGINX Plus R26 , remplacez js_include par js_import dans les fichiers de configuration NGINX et ajoutez également une instruction d'exportation aux fichiers JavaScript pour les fonctions référencées dans la configuration NGINX. Suivez ces étapes :

1. Modifier les fichiers de configuration NGINX :

   • Remplacez js_include par js_import et notez le module_name implicite (le paramètre de nom de fichier JavaScript de la directive, sans l'extension .js ).

   • Dans chaque directive qui fait référence à une fonction JavaScript, préfixez le nom de la fonction avec module_name . Le nom de la fonction est le premier paramètre de ces directives :

     • js_body_filter
     • js_content
     • js_filter
     • js_header_filter

     Il s'agit du deuxième paramètre de la directive js_set [ HTTP ][ Stream ].

   Par exemple, changez :

   js_set $foo maFonction;
   

   à:

   js_set $foo nom_module .myFunction;
   

2. Modifiez les fichiers JavaScript ( module_name .js ) qui définissent les fonctions référencées dans un fichier de configuration NGINX. Ajoutez une instruction d’exportation comme celle-ci à chaque fichier, en nommant les fonctions référencées.

   exportation par défaut { maFonction, autreFonction }
   

   L'instruction d'exportation peut apparaître n'importe où dans le fichier .js , mais par convention, elle est placée soit directement au-dessus des fonctions, soit à la fin du fichier.

Le module Cookie-Flag est obsolète

Le module Cookie-Flag tiers est obsolète dans NGINX Plus R23 et, comme annoncé à l’époque, n’est plus disponible dans le référentiel de modules NGINX à partir de cette version.

Avant de procéder à la mise à niveau vers NGINX Plus R26 , modifiez votre configuration NGINX pour remplacer toutes les occurrences de la directive set_cookie_flag (définie dans le module obsolète) par la directive proxy_cookie_flags intégrée.

La négociation TLS ne prend plus en charge le protocole NPN

La manière dont NGINX établit les connexions TLS et HTTP/2 a été mise à jour. Dans le cadre de la négociation TLS entre NGINX et un client (généralement un navigateur), ils négocient le protocole de communication qui sera utilisé dans la session établie par la négociation (le plus souvent, la négociation met à niveau la session de HTTP 1. x vers HTTP/2). L'extension Next Protocol Negotiation (NPN) de TLS a été la première méthode utilisée à cette fin, mais NPN est désormais considéré comme obsolète et remplacé par l'extension Application‑Layer Protocol Negotiation (ALPN), publiée sous la forme RFC 7301 .

NGINX Plus R26 ne prend plus en charge NPN, les clients doivent donc désormais utiliser exclusivement ALPN.

De plus, notre implémentation ALPN a été étendue et renforcée – voir Handshakes TLS renforcés .

L'ancien référentiel de logiciels NGINX Plus n'est plus mis à jour

Lors de la sortie de NGINX Plus R24 , les référentiels de packages pour tous les logiciels NGINX ont été réorganisés, ce qui a entraîné des modifications dans la procédure d'installation de NGINX Plus.

Lorsque vous installez ou mettez à niveau NGINX Plus, le gestionnaire de packages du système d'exploitation ( apt , yum ou équivalent) est configuré avec le référentiel de logiciels pour NGINX Plus.

Si vous effectuez une mise à niveau vers NGINX Plus R26 sur un système existant configuré pour utiliser l'ancien référentiel plus-pkgs.nginx.com (ceux exécutant NGINX Plus R23 ou une version antérieure), vous devez mettre à jour le gestionnaire de paquets pour faire référence au nouveau référentiel pkgs.nginx.com/plus . Consultez les instructions dans la base de connaissances F5 .

Si vous effectuez une installation initiale de NGINX Plus R26 , consultez Installation de NGINX Plus dans le Guide d'administration de NGINX Plus .

NGINX Plus R26 n'est pas disponible dans l'ancien référentiel , qui ne recevra plus de mises à jour.

Accès modifié à la spécification OpenAPI pour l'API NGINX Plus

Le package logiciel NGINX Plus n'inclut plus la spécification OpenAPI au format YAML ni l'interface utilisateur Swagger pour l' API NGINX Plus . Vous pouvez désormais y accéder dans le Guide d'administration NGINX Plus .

Modifications apportées à la prise en charge de la plateforme

Nouveaux systèmes d'exploitation et architectures pris en charge :

• Alpine Linux 3.15 (x86_64, arm64)
• La plateforme IBM Z (s390x) avec CentOS 8.1+, RHEL 8.1+ et Ubuntu 20.04 ; voir Prise en charge de l'architecture IBM Z s390x

Anciens systèmes d’exploitation supprimés :

• Alpine Linux 3.11 (la version la plus ancienne prise en charge est la 3.12)

Systèmes d'exploitation et architectures plus anciens obsolètes et dont la suppression est prévue dans NGINX Plus R27 :

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

Nouvelles fonctionnalités en détail

Validation JWT plus rapide avec la mise en cache des jeux de clés Web JSON

Lors de la validation des jetons Web JSON, NGINX utilise un ensemble de clés Web JSON (JWKS) pour vérifier la signature du jeton ou décrypter le jeton. Les JWKS peuvent être stockés dans des fichiers de configuration ou obtenus à partir de services externes via une requête HTTP. De plus, la mise en cache d’un JWKS en mémoire présente plusieurs avantages :

• Réduction significative de l'utilisation du processeur
• Latence de demande réduite
• Rationalisation de la validation JWT, car dans le cadre du processus de mise en cache, les clés JWKS sont converties de JSON en un format binaire optimisé pour les opérations cryptographiques

Pour mettre en cache les JWKS en mémoire, incluez la nouvelle directive auth_jwt_key_cache et spécifiez le délai d'expiration pour chaque ensemble de clés (dans cet exemple, 3 heures) :

Lorsque les JWK sont obtenus à partir d'un serveur externe, nous vous recommandons également de configurer la mise en cache de contenu standard et d'inclure la directive proxy_cache_use_stale , qui indique à NGINX Plus de continuer à diffuser un JWKS expiré pendant qu'il est actualisé en arrière-plan.

Les avantages de la mise en cache de contenu en plus de la mise en cache JWKS sont doubles :

• Résilience – Le JWKS peut être récupéré à partir du cache même lorsqu’il a expiré. Cela augmente la résilience lorsque le fournisseur JWKS est temporairement indisponible, mais il existe un compromis en termes de risque de sécurité accru.

• Effet sur le serveur d'autorisation – L'expiration d'un JWKS mis en cache affecte le serveur d'authentification différemment selon que la mise en cache JWKS est utilisée seule ou en combinaison avec la mise en cache de contenu :

  • Avec la mise en cache JWKS seule, toutes les demandes d’autorisation entrantes sont transmises au serveur d’authentification jusqu’à ce que le cache soit repeuplé avec une nouvelle version du JWKS expiré. Si le serveur d'authentification répond lentement, il peut y avoir une augmentation soudaine des requêtes HTTP répétées pour le JWKS. Cette charge supplémentaire pourrait surcharger le service d’authentification, aggravant ainsi le problème.

  • Lorsque la mise en cache de contenu est activée avec la diffusion de JWKS expirés, une seule demande pour le JWKS est transmise au serveur d'authentification, les demandes suivantes étant mises en file d'attente jusqu'à ce que NGINX puisse les satisfaire une fois le cache de contenu rempli. Cela entraîne une demande plus faible (et donc une consommation de ressources plus faible) sur le service d'authentification.

Poignées de main TLS renforcées

Les attaques contre TLS, telles que ALPACA , sont en augmentation. Dans le cadre de notre engagement continu en faveur d'une défense proactive contre les exploits, nous avons renforcé la gestion des connexions TLS par NGINX.

La négociation du protocole de couche application (ALPN) est une extension facultative de la négociation TLS, utilisée par le client et le serveur pendant la négociation TLS pour choisir le protocole de couche 7 qu'ils utiliseront dans la session chiffrée établie par la négociation. Le cas d’utilisation le plus courant d’ALPN est de négocier la mise à niveau de HTTP/1. x vers HTTP/2 pour la session entre un navigateur et un serveur Web ou d’application.

NGINX Plus rejette désormais une négociation TLS si le client propose un protocole via ALPN qui ne correspond pas au contexte de configuration NGINX de la session en cours d'établissement. Par exemple, un serveur virtuel défini dans le contexte http{} nécessite un ID de protocole ALPN pour HTTP, tandis qu'un serveur virtuel dans le contexte mail{} nécessite un ID de protocole pour SMTP, POP ou IMAP.

NGINX Plus R26 introduit la variable $ssl_alpn_protocol [ HTTP ][ Stream ] pour capturer le protocole négocié. (La variable $ssl_preread_alpn_protocols introduite dans le contexte stream{} dans NGINX Plus R15 capture toujours la liste de tous les protocoles annoncés par le client pendant la négociation.)

Cet extrait définit le format du journal alpn qui utilise $ssl_alpn_protocol pour inclure le protocole dans le champ alpn= des entrées du journal d'accès.

La nouvelle directive ssl_alpn dans le contexte stream{} définit les protocoles acceptés par NGINX Plus. Omettez la directive pour permettre à NGINX Plus de prendre en compte tous les protocoles présentés par le client.

Améliorations du module JavaScript NGINX

NGINX Plus R26 intègre la version0.7.2 du module JavaScript NGINX (njs) et inclut deux améliorations :

• Prise en charge améliorée des fonctions asynchrones avec les mots-clés async et wait et l'objet Promise introduits dans ECMAScript 6
• Une implémentation de l'API WebCrypto

Note: Cette section suppose que vous comprenez les constructions JavaScript pour les opérations asynchrones et cryptographiques. Une analyse complète des extraits de code dépasse le cadre de ce blog.

[ Éditeur – Les cas d’utilisation décrits dans cette section ne sont que quelques-uns des nombreux cas d’utilisation du module JavaScript NGINX. Pour une liste complète, voir Cas d'utilisation du module JavaScript NGINX . ]

Prise en charge améliorée des fonctions asynchrones

Dans de nombreux langages de script couramment utilisés comme PHP, les commandes et les fonctions s'exécutent de manière synchrone – c'est-à-dire qu'après qu'un script a appelé une fonction, il s'arrête (arrête de s'exécuter) jusqu'à ce que la fonction renvoie un résultat.

JavaScript peut également fonctionner de manière asynchrone : lorsqu'une fonction est invoquée de manière asynchrone, le script continue de s'exécuter sans attendre le retour du résultat de la fonction.

Prenez cet exemple de script :

Il renvoie une réponse vide car l'environnement d'exécution njs n'attend pas que les délais d'attente définis s'écoulent (s'il attendait, la sortie serait b,a ) :

$ curl http://127.0.0.1/ $ 

La gestion correcte des opérations asynchrones est évidemment cruciale pour obtenir le résultat escompté. JavaScript fournit un certain nombre de façons de procéder, mais dans les cas d'utilisation courants de NGINX, il est souvent souhaitable de simplement encapsuler une fonction asynchrone de manière à rendre le flux d'exécution synchrone. C'est ici qu'entrent en jeu l'objet Promise et les mots-clés async et wait .

ECMAScript 6 (la sixième édition de la spécification du langage ECMA‑262 pour JavaScript) définit l'objet Promise comme un type de retour pour les fonctions asynchrones. Il existe dans l'un des trois états suivants :

• accompli – L’opération s’est terminée avec succès
• rejeté – L’opération a échoué
• en attente – L’état initial (ni satisfait ni rejeté)

La définition d'une fonction JavaScript avec le mot clé async définit le type de retour de la fonction sur Promise . Les mots-clés async et wait sont importants lorsque vous écrivez des fonctions njs traitant des objets Promise .

Prenons cet exemple :

La fonction fs.readFile (ligne 12) renvoie une Promise . Il est enveloppé dans une fonction asynchrone personnalisée qui garantit que fs.readFile() n'est invoqué que si le fichier est appelé user.text . En raison du mot-clé wait , la fonction d'encapsulation attend ensuite la promesse et renvoie les données.

Envelopper fs.readFile() dans une autre fonction facilite la détection des erreurs ; toute exception dans la fonction asynchrone définit l'état de la promesse sur rejeté . Une autre façon de procéder consiste à remplacer la ligne 9 par une instruction qui renvoie une promesse rejetée :

Vous pouvez également travailler directement avec les objets Promise . Dans l'exemple suivant, les fonctions Promise.resolve renvoient une promesse pour chacun des p1 et p2 . La fonction Promise.all attend que les promesses de p1 et p2 soient résolues avant de renvoyer un résultat.

Maintenant, la sortie de notre commande curl est ce que nous voulons (notez que b est renvoyé en premier en raison de la valeur de délai d'attente plus courte) :

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

Nouvelles fonctions cryptographiques avec l'API WebCrypto

NGINX JavaScript a désormais accès à des fonctionnalités cryptographiques améliorées via l' API WebCrypto . Les cas d'utilisation cryptographiques courants de NGINX incluent :

• Générer des nombres aléatoires sécurisés pour les identifiants de session
• Cryptage et décryptage des messages, des données et des cookies
• Créer ou valider des signatures numériques à l'aide d'algorithmes de cryptographie symétriques et asymétriques

Ce code njs génère un nombre aléatoire :

Et cette configuration NGINX Plus invoque le code njs :

La sortie de la fonction est un nombre aléatoire quelque chose comme ceci :

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

La fonction getRandomValues dans WebCrypto est un excellent point d'entrée pour démarrer avec les nombres aléatoires sécurisés et WebCrypto en général. Son implémentation est assez simple et la fonction renvoie des résultats directement, au lieu de renvoyer une Promise .

Cependant, certaines des autres fonctions cryptographiques WebCrypto plus intensives fonctionnent de manière asynchrone. Par exemple, la documentation de сrypto.subtle.digest() indique :

Génère un condensé des données fournies. Prend comme arguments un identifiant pour l'algorithme de digestion à utiliser et les données à digérer. Renvoie une promesse qui sera remplie avec le condensé.

L'appel direct de сrypto.subtle.digest() ne garantit donc pas que son résultat sera disponible à l'étape suivante, à moins qu'il ne soit encapsulé dans une fonction asynchrone . Nous l'enveloppons donc ici dans une fonction avec les mots-clés async et wait pour garantir que la variable de hachage est renseignée avec un résultat avant que la fonction ne renvoie :

La directive js_set dans cette configuration NGINX Plus remplit la variable $hosthash avec la valeur renvoyée par la fonction setReturnValue (comme encapsulée dans la fonction host_hash ) :

Voici un exemple qui hache le nom d'hôte example.com .

$ curl -H "Hôte : exemple.com" 127.0.0.1 # e8e624a82179b53b78364ae14d14d63dfeccd843b026bc8d959ffe0c39fc4ded1f4dcf4c8ebe871e657a12db6f11c3af87c9a1d4f2b096ba3deb56596f06b6f4

Autres améliorations dans NGINX Plus R26

Prise en charge de l'architecture IBM Z (s390x)

Alors que les applications modernes colonisent chaque biome numérique disponible, il est important que les composants essentiels au maintien de la vie, comme NGINX, voyagent avec elles. Nous sommes donc heureux de prendre en charge NGINX Plus sur l'architecture IBM Z (s390x) avec CentOS 8.1+, RHEL 8.1+ et Ubuntu 20.04. Les organisations souhaitant héberger des applications modernes sur leurs ressources mainframe existantes peuvent désormais déployer NGINX et NGINX Plus en tant que serveur Web logiciel, équilibreur de charge, proxy inverse, cache de contenu et passerelle API.

Prise en charge de TCP Half-Close dans le module Stream

La nouvelle directive proxy_half_close permet la fermeture indépendante de chaque direction d'une connexion TCP, pour une efficacité supplémentaire dans les contextes stream{} .

Prise en charge de la bibliothèque PCRE2

Les versions précédentes de NGINX Plus utilisent la bibliothèque Perl Compatible Regular Expression (PCRE) (version 1) pour évaluer les expressions régulières utilisées dans la configuration NGINX. Cet important projet open source a récemment atteint sa fin de vie, remplacé par PCRE2 . NGINX Plus est construit avec PCRE2, mais il prend en charge les modules dynamiques construits avec PCRE et PCRE2, en utilisant la version disponible avec le système d'exploitation sous-jacent. Aucune modification de configuration n'est requise.

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R26 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela aidera NGINX à vous aider lorsque vous aurez besoin de créer un ticket d'assistance.

Si vous n'avez pas essayé NGINX Plus, nous vous encourageons à l'essayer - pour la sécurité, l'équilibrage de charge et la passerelle API, ou en tant que serveur Web entièrement pris en charge avec des API de surveillance et de gestion améliorées. Vous pouvez commencer dès aujourd'hui avec un essai gratuit de 30 jours .