Annonce de NGINX Plus R28

Nous sommes heureux d'annoncer la disponibilité de NGINX Plus Release 28 (R28) . 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 R28 incluent :

• Mesures TLS supplémentaires – NGINX Plus R28 collecte des statistiques TLS supplémentaires au niveau du système, côté client et côté serveur, fournissant des informations essentielles lors du dépannage des erreurs liées à SSL/TLS dans la configuration du proxy et pour les connexions aux clients et aux serveurs en amont.

  Le tableau de bord de surveillance des activités en direct de NGINX Plus est mis à jour pour afficher les nouvelles données de session SSL.

• Prise en charge des TLV du protocole PROXY v2 dans les services privés cloud – Lorsque vous mettez des ressources à disposition de clients externes via un « service privé » dans AWS, Google Cloud Platform et Microsoft Azure, par défaut, l'identifiant client spécifique au service représenté dans un vecteur type-longueur-valeur (TLV) dans l'en-tête du protocole PROXY v2 n'est pas transmis aux services principaux. NGINX Plus R28 introduit des modules pour les contextes http et stream qui décodent le TLV et définissent une variable pour transmettre l'identifiant client aux services backend.
• Prise en charge variable pour le paramètre samesite du cookie collant – Dans NGINX Plus R28 , la valeur du paramètre samesite de la directive sticky cookie peut être une variable. Cette amélioration permet une gestion plus facile du trafic et plus de sécurité.

La version est complétée par de nouvelles fonctionnalités et des corrections de bugs héritées de NGINX Open Source et des mises à jour du module JavaScript NGINX.

Changements importants dans le comportement

Note: Si vous effectuez une mise à niveau à partir d'une version autre que NGINX Plus R27 , assurez-vous de consulter la section Modifications importantes du comportement dans les blogs d'annonces pour toutes les versions entre votre version actuelle et celle-ci.

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

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

• AlmaLinux 8 et 9 (x86_64, aarch64)
• Alpine 3.17 (x86_64, arm64)
• Oracle Linux 9 (x86_64)
• Rocky Linux 8 et 9 (x86_64, aarch64)

Anciens systèmes d’exploitation supprimés :

• Debian 10, qui a atteint la fin de vie (EOL) en août 2022

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

• Alpine 3.13, qui a atteint la fin de vie le 1er novembre 2022

Modification de la gestion de plusieurs en-têtes portant des noms identiques

• La plupart des en-têtes de réponse en amont en double connus sont désormais ignorés avec un avertissement
• Les en-têtes Content-Length et Transfer-Encoding en double sont désormais rejetés, ainsi que les réponses avec des en-têtes Content-Length ou Transfer-Encoding non valides, ou si Content-Length et Transfer-Encoding sont tous deux présents dans la réponse

Nouvelles fonctionnalités en détail

Mesures TLS supplémentaires

L’observabilité des événements et des erreurs SSL/TLS est importante lors du dépannage des problèmes liés à TLS avec la configuration du proxy, les serveurs en amont et les clients. Depuis l’introduction de l’ API NGINX Plus dans NGINX Plus R13 , NGINX Plus a collecté trois mesures TLS au niveau du système :

• poignées de main – Nombre de poignées de main SSL réussies
• handshakes_failed – Nombre d'échecs de négociation SSL (qui n'incluent pas les échecs de vérification de certificat qui se produisent après la négociation SSL)
• session_reuses – Nombre de réutilisations de sessions SSL

Dans NGINX Plus R27<.htmla> et versions ultérieures, vous pouvez configurer la collecte des trois métriques pour les serveurs en amont individuels et les serveurs virtuels.

NGINX Plus R28 étend l'ensemble des métriques TLS avec de nouveaux compteurs pour les erreurs de négociation et les échecs de validation de certificat dans les modules HTTP et Stream (nous fournissons ici des exemples uniquement pour les modules HTTP, mais les métriques Stream disponibles sont similaires). Pour plus de détails sur la configuration de la collecte de métriques pour les serveurs en amont individuels et les serveurs virtuels, consultez le blog d'annonces NGINX Plus R27<.htmlspan> .

Erreurs de poignée de main

Les compteurs pour les erreurs de négociation suivantes sont nouveaux dans NGINX Plus R28 :

• handshake_timeout – Nombre d'échecs de négociation en raison d'un dépassement de délai de négociation
• no_common_cipher – Nombre d'échecs de négociation en raison de l'absence d'un chiffrement commun entre les parties à la négociation (non collecté pour les connexions aux serveurs en amont car cela ne s'applique pas)
• no_common_protocol – Nombre d’échecs de négociation en raison de l’absence d’un protocole commun entre les parties
• peer_rejected_cert – Nombre d'échecs de négociation dus au rejet par l'autre partie du certificat présenté par NGINX Plus et à la fourniture du message d'alerte approprié

Échecs de vérification des certificats

Les échecs de vérification des certificats sont désormais signalés dans la nouvelle section verify_failures de la sortie de l'API lorsque vous configurez la vérification des certificats :

• Pour les connexions aux clients avec la directive ssl_verify_client [ HTTP ][ Stream ]

• Pour les connexions aux serveurs avec ces directives spécifiques au protocole :

  • vérification_grpc_ssl
  • proxy_ssl_verify [ HTTP ][ Flux ]
  • uwsgi_ssl_verify

Lorsqu'un échec de vérification de certificat se produit, la métrique de la cause correspondante est incrémentée et la connexion est interrompue. Notez cependant que le compteur de poignées de main de base est toujours incrémenté car ces échecs se produisent après la réussite de la poignée de main.

Les mesures pour une validation de certificat échouée sont :

• expired_cert – Un pair a présenté un certificat expiré
• hostname_mismatch – Le certificat du serveur ne correspond pas au nom d'hôte (non collecté pour les connexions aux clients)
• no_cert – Le client n'a pas fourni de certificat comme requis (non collecté pour les connexions aux serveurs en amont)
• revoked_cert – Le pair a présenté un certificat révoqué
• autre – Compteur explicite pour les autres échecs de vérification de certificat

Exemple de sortie de mesures

Voici un ensemble d’exemples de mesures TLS pour les connexions HTTP au niveau du système :

$ curl 127.0.0.1:8080/api/8/ssl { "poignées de main": 32, « session_reuses » : 0, « échec de la poignée de main » : 8, « no_common_protocol » : 4, "no_common_cipher": 2, « délai d'attente de la poignée de main » : 0, « certificat_rejeté_par_le_pair » : 0, "vérifier_échecs": { "no_cert": 0, « certificat expiré » : 2, « certificat_révoqué » : 1, « hostname_mismatch » : 2, « autre » : 1 } }

Voici un ensemble d'exemples de mesures pour les connexions entre les clients et le serveur virtuel HTTP s9 (comme indiqué précédemment, le compteur hostname_mismatch n'est pas collecté pour ces connexions) :

$ curl 127.0.0.1:8080/api/8/http/server_zones/s9 { ... "ssl": { "poignées de main": 0, « session_reuses » : 0, « échec de la poignée de main » : 1, « no_common_protocol » : 0, "no_common_cipher": 1, « délai d'attente de la poignée de main » : 0, « certificat_rejeté_par_le_pair » : 0, "vérifier_échecs": { "no_cert": 0, « certificat expiré » : 0, « certificat_révoqué » : 0, "autre" : 0 } } ... }

Voici un ensemble d'exemples de mesures pour les connexions HTTP aux serveurs du groupe en amont u2 (comme indiqué précédemment, les compteurs no_cert et no_common_cipher ne sont pas collectés pour ces connexions) :

$ curl 127.0.0.1:8080/api/8/http/upstreams/u2 { "pairs": [ { "id": 0, "serveur" : "127.0.0.1:8082", "nom": "127.0.0.1:8082", ... "ssl": { "poignées de main": 1, « session_reuses » : 0, « échec de la poignée de main » : 0, "no_common_protocol": 0, « délai d'attente de la poignée de main » : 0, « certificat_rejeté_par_le_pair » : 0, "verify_failures": { "expired_cert": 1, « certificat_révoqué » : 0, « hostname_mismatch » : 0, "autre" : 0 } }, ... } ], }

Le tableau de bord NGINX Plus affiche les mesures TLS étendues

Pour NGINX Plus R28 et versions ultérieures, le tableau de bord de surveillance des activités en direct affiche les nouvelles mesures TLS décrites ci-dessus. Cette capture d'écran montre les métriques des connexions aux clients. Pour afficher les nouvelles mesures, passez la souris sur la valeur dans la colonne SSL > Échec des poignées de main comme indiqué.

Prise en charge des TLV du protocole PROXY v2 dans les services privés Cloud

Les trois principaux fournisseurs de cloud – Amazon Web Services (AWS), Google Cloud Platform (GCP) et Microsoft Azure – proposent chacun un « service privé » qui vous permet de permettre à des clients externes d’accéder à vos services sans les exposer sur l’Internet public. Chaque service utilise un identifiant client qui est représenté dans un vecteur type-longueur-valeur (TLV) dans un en-tête de protocole PROXY v2. Les identifiants spécifiques au service sont :

• AWS PrivateLink – PP2_SUBTYPE_AWS_VPCE_ID
• Connexion au service privé GCP – pscConnectionId
• Lien privé Microsoft Azure – PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID

Par défaut, ces identifiants client ne sont pas transmis aux services back-end. NGINX Plus R28 introduit des modules pour les contextes http et stream – ngx_http_proxy_protocol_vendor_module et ngx_stream_proxy_protocol_vendor_module – qui décodent le TLV et définissent une variable pour transmettre l'identifiant aux services backend.

Pour obtenir des informations générales sur la manière dont NGINX Plus utilise le protocole PROXY pour obtenir des adresses IP et d'autres informations sur les clients, consultez Acceptation du protocole PROXY dans le Guide d'administration de NGINX Plus.

Prise en charge du protocole PROXY v2 pour AWS

Dans AWS, l’adresse IP source du trafic provenant des clients via un service de point de terminaison Virtual Private Cloud (VPC) est l’adresse IP privée du nœud Network Load Balancer. Si l'application backend nécessite les adresses IP réelles et d'autres identifiants pour les clients, ils peuvent être obtenus à partir des en-têtes du protocole PROXY v2.

Dans AWS, un vecteur TLV personnalisé encode l'ID VPC du point de terminaison dans l'en-tête du protocole PROXY v2 PP2_SUBTYPE_AWS_VPCE_ID . (Pour plus d'informations, consultez la documentation AWS .)

NGINX Plus R28 décode le TLV et transmet l'ID du point de terminaison aux applications back-end dans la variable $proxy_protocol_tlv_aws_vpce_id .

Note: Dans le bloc serveur où vous référencez la variable $proxy_protocol_tlv_aws_vpce_id , vous devez également inclure le paramètre proxy_protocol à la directive listen [ HTTP ][ Stream ]. Pour un exemple, voir la ligne 8 de proxy_protocol_v2.conf juste en dessous.

Cet exemple de configuration pour AWS vérifie que l'ID VPC est acceptable et, si tel est le cas, le transmet à l'application back-end en tant que deuxième paramètre de la directive add_header :

Prise en charge du protocole PROXY v2 pour GCP

Dans GCP Private Service Connect, l’adresse IP source du trafic provenant des clients est une « adresse dans l’un des sous-réseaux Private Service Connect du réseau VPC du producteur de services ». Si l’application backend nécessite les adresses IP réelles et d’autres identifiants pour les clients, ils peuvent être obtenus à partir des en-têtes du protocole PROXY v2.

Dans GCP, un vecteur TLV personnalisé encode l'ID de connexion unique (à ce moment-là) dans l'en-tête du protocole PROXY v2 pscConnectionId . (Pour plus d'informations, consultez la documentation GCP .)

NGINX Plus R28 décode le TLV et transmet la valeur de pscConnectionId aux applications back-end dans la variable $proxy_protocol_tlv_gcp_conn_id .

Note: Dans le bloc serveur où vous référencez la variable $proxy_protocol_tlv_gcp_conn_id , vous devez également inclure le paramètre proxy_protocol à la directive listen [ HTTP ][ Stream ]. Pour un exemple, voir la ligne 8 de proxy_protocol_v2.conf ci-dessus.

Prise en charge du protocole PROXY v2 pour Microsoft Azure

Dans Microsoft Azure Private Link, l’adresse IP source du trafic provenant des clients est « l’adresse réseau traduite (NAT) côté fournisseur de services à l’aide de l’adresse IP NAT [adresse] allouée à partir du réseau virtuel du fournisseur ». Si l’application backend nécessite les adresses IP réelles et d’autres identifiants pour les clients, ils peuvent être obtenus à partir des en-têtes du protocole PROXY v2.

Dans Azure, un vecteur TLV personnalisé encode le LinkID du client dans l'en-tête du protocole PROXY v2 PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID . (Pour plus d'informations, consultez la documentation Azure .)

NGINX Plus R28 décode le TLV et transmet le LinkID aux applications back-end dans la variable $proxy_protocol_tlv_azure_pel_id .

Note: Dans le bloc serveur où vous référencez la variable $proxy_protocol_tlv_azure_pel_id , vous devez également inclure le paramètre proxy_protocol dans la directive listen [ HTTP ][ Stream ]. Pour un exemple, voir la ligne 8 de proxy_protocol_v2.conf ci-dessus.

Prise en charge variable pour le paramètre Sticky Cookie samesite

Dans les versions précédentes de NGINX Plus, trois valeurs statiques ( strict , lax et none ) étaient acceptables pour le paramètre samesite de la directive sticky cookie . Dans NGINX Plus R28 , la valeur peut également être une variable.

Par défaut (il n'y a pas de paramètre samesite ), NGINX n'injecte pas l'attribut SameSite dans le cookie. Lorsque le paramètre samesite est une variable, le résultat dépend de la manière dont la variable est résolue au moment de l'exécution :

• Pour l'une des valeurs standard ( strict , lax et none ) – NGINX injecte l'attribut SameSite défini sur cette valeur
• Vers une valeur vide ( "" ) – NGINX n'injecte pas l'attribut SameSite
• Pour toute autre valeur indiquant une mauvaise configuration, NGINX injecte l'attribut SameSite défini sur Strict (le paramètre le plus sécurisé)

Cet exemple de configuration définit l'attribut samesite en fonction de la valeur de l'en-tête HTTP User-Agent (cela convient aux clients hérités qui ne prennent pas en charge l'attribut SameSite ) :

Autres améliorations dans NGINX Plus R28

Modifications héritées de NGINX Open Source

NGINX Plus R28 est basé sur NGINX Open Source 1.23.2. et hérite des modifications fonctionnelles et des corrections de bugs apportées depuis la sortie de NGINX Plus R27 (dans NGINX 1.23.0 à 1.23.2). Les modifications et corrections de bogues incluent :

• Le nouveau paramètre ipv4=off de la directive de résolution HTTP désactive la recherche d'adresses IPv4.
• Lorsque vous activez un cache partagé pour les informations de session HTTP avec le paramètre shared de la directive ssl_session_cache , les clés de ticket de session TLS sont désormais tournées automatiquement.
• Le niveau de gravité auquel plusieurs types d’erreurs TLS/SSL sont enregistrés est abaissé de crit à info .

Pour la liste complète des nouvelles fonctionnalités, modifications et corrections de bogues héritées de ces versions, consultez le fichier CHANGES .

Modifications apportées au module JavaScript NGINX

NGINX Plus R28 intègre les modifications et les correctifs apportés dans les versions 0.7.5 à 0.7.8 du module JavaScript NGINX (njs). Nous avons mis en évidence certains des plus importants dans Rendez votre configuration NGINX encore plus modulaire et réutilisable avec njs 0.7.7 sur notre blog. Pour une liste complète, voir le fichier Modifications .

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R28 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 .