Annonce de NGINX Plus R26

Robert HaynesResponsable marketing technique

Nous sommes heureux d’annoncer la disponibilité de NGINX Plus Release 26 (R26). Basé sur NGINX Open Source, NGINX Plus est la seule solution logicielle tout-en-un faisant office de serveur web, d’équilibreur de charge, de proxy inverse, de cache de contenu et de passerelle API.

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

• Validation JWT plus rapide grâce à la mise en cache des ensembles de clés Web JSON – Dans la continuité des améliorations apportées à la prise en charge des jetons Web JSON (JWT) 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 liée à la validation des JWT.
• Échanges TLS renforcés – NGINX Plus rejette l’établissement de la connexion TLS si le client propose via ALPN un protocole de communication qui ne correspond pas au contexte de configuration NGINX de la session en cours d’établissement (par exemple, s’il propose le protocole de messagerie IMAP à un serveur virtuel dans le contexte http{} ).
• Améliorations apportées au module JavaScript NGINX – Les fonctions asynchrones utilisant les mots-clés async et await ainsi que 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 chiffrement de cookies).

Cette version est complétée par la prise en charge de l’architecture IBM System Z (s390x), la possibilité de fermer indépendamment chaque sens d’une connexion TCP et la prise en charge de la version 2 de la bibliothèque d’expressions régulières compatibles Perl (PCRE).

Modifications importantes du comportement

Le module JavaScript de NGINX ne prend plus en charge js_include

Comme annoncé lors de la sortie de NGINX Plus R23, dans la version 0.4.0 du module JavaScript NGINX, la directive js_import a remplacé la directive js_include. La directive js_include a alors été déclarée obsolète et n’est désormais plus prise en charge depuis 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 export dans les fichiers JavaScript pour les fonctions référencées dans la configuration NGINX. Procédez comme suit :

1. Modifiez les fichiers de configuration NGINX. Par exemple, remplacez :

js_set $foo myFunction;

1. en :

js_set $foo module_name.myFunction;

• Remplacez js_include par js_import et notez le nom de module implicite « module_name » (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, faites précéder le nom de la fonction de module_name. Le nom de la fonction est le premier paramètre de ces directives. Il s’agit du deuxième paramètre de la directive js_set[HTTP][Stream].
  • js_body_filter
  • js_content
  • js_filter
  • js_header_filter

1. 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 export comme celle ci-dessous à chaque fichier, en indiquant le nom des fonctions référencées.

export default { myFunction, otherFunction }

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

Le module Cookie-Flag est obsolète

Le module tiers Cookie‑Flag a été déclaré obsolète dans NGINX Plus R23 et, comme annoncé à l’époque il n’est désormais plus disponible dans le dépôt de modules NGINX à compter de cette version.

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

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. Lors de l’établissement d’une liaison TLS entre NGINX et un client (généralement un navigateur), ils négocient le protocole de communication à utiliser pour la session ainsi établie (le plus souvent, cette négociation fait passer la session de HTTP 1.x à HTTP/2). L’extension Next Protocol Negotiation (NPN) de TLS a été la première méthode utilisée à cette fin, mais elle est désormais considérée comme obsolète et a été remplacée par l’extension Application-Layer Protocol Negotiation (ALPN), publiée sous la référence RFC 7301.

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

En outre, notre implémentation d’ALPN a été étendue et renforcée – voir « Renforcement des négociations TLS ».

L’ancien dépôt de logiciels NGINX Plus n’est plus mis à jour

Lors de la sortie de NGINX Plus R24, les dépôts de paquets de tous les logiciels NGINX ont été réorganisés, ce qui a entraîné des modifications de la procédure d’installation de NGINX Plus.

Lorsque vous installez ou mettez à niveau NGINX Plus, le gestionnaire de paquets du système d’exploitation (apt, yum ou équivalent) est configuré avec le dépôt de logiciels de NGINX Plus.

Si vous effectuez une mise à niveau vers NGINX Plus R26 sur un système existant configuré pour utiliser l’ancien dépôt plus-pkgs.nginx.com (c’est-à-dire un système exécutant NGINX Plus R23 ou une version antérieure), vous devez mettre à jour le gestionnaire de paquets afin qu’il utilise le nouveau dépôt pkgs.nginx.com/plus. Consultez les instructions dans la base de connaissances F5.

Si vous effectuez une première installation de NGINX Plus R26, consultez la section « Installation de NGINX Plus » du Guide d’administration de NGINX Plus.

NGINX Plus R26 n’est pas disponible dans l’ancien dépôt, qui ne recevra plus aucune mise à jour.

Modification de l’accès à la spécification OpenAPI de 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 de NGINX Plus.

Modifications de la prise en charge des plateformes

Nouveaux systèmes d’exploitation et nouvelles 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)

Anciens systèmes d’exploitation et anciennes architectures obsolètes 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 grâce à la mise en cache des ensembles de clés Web JSON

Lors de la validation de jetons Web JSON (JWT), NGINX utilise un ensemble de clés Web JSON (JWKS) pour vérifier la signature du jeton ou le déchiffrer. Les JWKS peuvent être stockés dans des fichiers de configuration ou obtenus auprès de services externes au moyen d’une requête HTTP. En outre, la mise en cache d’un JWKS en mémoire présente plusieurs avantages :

• Réduction significative de l’utilisation du processeur
• Réduction de la latence des requêtes
• Optimisation de la validation des JWT, car, dans le cadre du processus de mise en cache, les clés JWKS sont converties du format JSON vers un format binaire optimisé pour les opérations cryptographiques

Pour mettre en cache les JWKS en mémoire, ajoutez la nouvelle directive auth_jwt_key_cache et indiquez la durée d’expiration de chaque jeu de clés (dans cet exemple, 3 heures) :

Chargement de l’exemple de code…

Lorsque les JWK sont obtenues à partir d’un serveur externe, nous recommandons également de configurer la mise en cache du contenu standard et d’inclure la directive proxy_cache_use_stale, qui indique à NGINX Plus de continuer à fournir un JWKS expiré pendant son actualisation en arrière-plan.

Chargement de l’exemple de code…

La mise en cache du contenu, en complément de celle des JWKS, présente un double avantage :

• Résilience – Le JWKS peut être récupéré depuis le cache même après son expiration. Cela améliore la résilience lorsque le fournisseur de JWKS est temporairement indisponible, mais augmente en contrepartie le risque de sécurité.
• Effet sur le serveur d’autorisation – L’expiration d’un JWKS mis en cache affecte différemment le serveur d’autorisation selon que la mise en cache du JWKS est utilisée seule ou conjointement avec la mise en cache du contenu :
  • Lorsque seule la mise en cache du JWKS est utilisée, toutes les demandes d’autorisation entrantes sont transmises au serveur d’autorisation jusqu’à ce que le cache soit de nouveau alimenté avec une nouvelle version du JWKS arrivé à expiration. Si le serveur d’autorisation répond lentement, le nombre de requêtes HTTP répétées visant à récupérer le JWKS peut augmenter soudainement. Cette charge supplémentaire risque de saturer le service d’autorisation et d’aggraver le problème.
  • Lorsque la mise en cache du contenu est activée avec la diffusion de JWKS expirés, une seule requête de JWKS est transmise au serveur d’authentification. Les requêtes suivantes sont mises en file d’attente jusqu’à ce que NGINX puisse y répondre une fois le cache de contenu alimenté. Cela réduit la sollicitation du service d’authentification et, par conséquent, sa consommation de ressources.

Échanges TLS renforcés

Les attaques contre TLS, telles que ALPACA, se multiplient. 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 de protocole de couche applicative (ALPN) est une extension facultative de la négociation TLS, utilisée par le client et le serveur au cours de celle-ci pour choisir le protocole de couche 7 qu’ils emploieront dans la session chiffrée ainsi établie. Le cas d’usage le plus courant d’ALPN consiste à négocier le passage de HTTP/1.x à HTTP/2 pour la session entre un navigateur et un serveur web ou applicatif.

NGINX Plus rejette désormais toute négociation TLS si le client propose via ALPN un protocole 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 identifiant de protocole ALPN pour HTTP, tandis qu’un serveur virtuel défini dans le contexte mail{} nécessite un identifiant 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, continue de capturer la liste de tous les protocoles annoncés par le client lors de la négociation.)

Cet extrait définit le format de journalisation « alpn », qui utilise $ssl_alpn_protocol pour inclure le protocole dans le champ alpn= des entrées du journal d’accès.

Chargement de l’exemple de code…

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

Chargement de l’exemple de code…

Améliorations du module JavaScript de NGINX

NGINX Plus R26 intègre la version 0.7.2 du module JavaScript NGINX (njs) et comprend deux améliorations :

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

Remarque : Cette section suppose que vous maîtrisez les concepts JavaScript liés aux opérations asynchrones et cryptographiques. Une analyse complète des extraits de code dépasse le cadre de cet article.

[Éditeur – Les cas d’utilisation décrits dans cette section ne représentent qu’une partie des nombreux cas d’utilisation du module JavaScript NGINX. Pour obtenir la liste complète, consultez 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 : lorsqu’un script appelle une fonction, il se met en pause (cesse 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 appelée de manière asynchrone, le script poursuit son exécution sans attendre que la fonction renvoie un résultat.

Prenons cet exemple de script :

Chargement de l’exemple de code…

Il renvoie une réponse vide, car l’environnement d’exécution njs n’attend pas l’expiration des délais définis (s’il attendait, la sortie serait b,a ):

$ curl http://127.0.0.1/
$ 

Il est évidemment essentiel de gérer correctement les opérations asynchrones pour obtenir le résultat souhaité. JavaScript offre plusieurs façons de procéder, mais dans les cas d’utilisation courants de NGINX, il est souvent préférable d’encapsuler simplement une fonction asynchrone de manière à rendre le flux d’exécution synchrone. C’est là qu’interviennent l’objet « Promise » et les mots-clés « async » et « await ».

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

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

Définir 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 await sont importants lorsque vous écrivez des fonctions njs qui manipulent des objets Promise.

Prenons cet exemple :

Chargement de l’exemple de code…

La fonction « fs.readFile » (ligne 12) renvoie une Promise. Elle est encapsulée dans une fonction async personnalisée qui garantit que fs.readFile() n’est appelée que si le fichier se nomme user.text. Grâce au mot-clé await, la fonction d’encapsulation attend ensuite la résolution de la Promise et renvoie les données.

Le fait d’encapsuler « fs.readFile() » dans une autre fonction facilite la gestion des erreurs ; toute exception dans la fonction async fait passer la Promise à l’état rejected. Une autre façon de procéder consiste à remplacer la ligne 9 par une instruction qui renvoie une Promise rejetée :

Chargement de l’exemple de code…

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

Chargement de l’exemple de code…

À présent, la sortie de notre commande « curl » correspond à ce que nous souhaitons (notez que « b » est renvoyé en premier en raison du délai d’expiration plus court) :

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

Nouvelles fonctions cryptographiques avec l’API WebCrypto

NGINX JavaScript dispose désormais de fonctionnalités cryptographiques avancées grâce à l’API WebCrypto. Parmi les cas d’usage cryptographiques courants de njs figurent :

• Génération de nombres aléatoires sécurisés pour les identifiants de session
• Chiffrement et déchiffrement des messages, des données et des cookies
• Création ou validation de signatures numériques à l’aide d’algorithmes cryptographiques symétriques et asymétriques

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

Chargement de l’exemple de code…

Et cette configuration NGINX Plus appelle le code njs :

Chargement de l’exemple de code…

La fonction renvoie un nombre aléatoire semblable à celui-ci :

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

La fonction getRandomValues de WebCrypto constitue un excellent point de départ pour découvrir les nombres aléatoires sécurisés et WebCrypto en général. Son implémentation est assez simple et, contrairement aux fonctions qui renvoient une Promise, elle renvoie directement les résultats.

Cependant, certaines des autres fonctions cryptographiques WebCrypto plus gourmandes en ressources s’exécutent de manière asynchrone. Par exemple, la documentation de сrypto.subtle.digest() indique :

Génère une empreinte des données fournies. Prend comme arguments un identifiant de l’algorithme de hachage à utiliser et les données dont il faut calculer l’empreinte. Renvoie une Promise qui sera résolue avec l’empreinte.

Par conséquent, appeler directement « сrypto.subtle.digest() » ne garantit pas que son résultat sera disponible à l’étape suivante, sauf si cet appel est encapsulé dans une fonction async. Nous l’encapsulons donc ici dans une fonction avec les mots-clés async et await afin de nous assurer que la variable hash contient bien un résultat avant que la fonction ne se termine :

Chargement de l’exemple de code…

La directive « js_set » de cette configuration NGINX Plus affecte à la variable $hosthash la valeur renvoyée par la fonction setReturnValue (encapsulée dans la fonction host_hash) :

Chargement de l’exemple de code…

Voici un exemple qui hache le nom d’hôte « example.com ».

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

Autres améliorations de NGINX Plus R26

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

Alors que les applications modernes colonisent tous les biotopes numériques disponibles, il est important que les composants essentiels à leur fonctionnement, tels que NGINX, les accompagnent. Nous sommes donc heureux de proposer la prise en charge de NGINX Plus sur l’architecture IBM Z (s390x) avec CentOS 8.1+, RHEL 8.1+ et Ubuntu 20.04. Les entreprises qui souhaitent héberger des applications modernes sur leurs systèmes mainframe existants peuvent désormais déployer NGINX et NGINX Plus sous forme logicielle en tant que serveur web, équilibreur de charge, proxy inverse, cache de contenu et passerelle d’API.

Prise en charge de la semi-fermeture TCP dans le module Stream

La nouvelle directive « proxy_half_close » permet de fermer indépendamment chaque sens d’une connexion TCP, pour une efficacité accrue dans les contextes stream{}.

Prise en charge de la bibliothèque PCRE2

Les versions précédentes de NGINX Plus utilisent la bibliothèque d’expressions régulières compatibles avec Perl (PCRE) (version 1) pour évaluer les expressions régulières utilisées dans la configuration de NGINX. Cet important projet open source est récemment arrivé en fin de vie et a été remplacé par PCRE2. NGINX Plus est compilé avec PCRE2, mais prend en charge les modules dynamiques compilés avec PCRE ou PCRE2, selon la version disponible sur le système d’exploitation sous-jacent. Aucune modification de la configuration n’est nécessaire.

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R26 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela permettra à NGINX de mieux vous aider lorsque vous aurez besoin d’ouvrir un ticket d’assistance.

Si vous n’avez pas encore essayé NGINX Plus, nous vous invitons à le découvrir – pour la sécurité, l’équilibrage de charge et la passerelle d’API, ou comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. Vous pouvez commencer dès aujourd’hui avec un essai gratuit de 30 jours.

À propos de l’auteur

Robert HaynesResponsable marketing technique

Autres articles de Robert Haynes