Annonce de NGINX Plus R28

Robert HaynesResponsable marketing technique

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

• Métriques TLS supplémentaires – NGINX Plus R28 collecte des statistiques TLS supplémentaires à l’échelle du système, ainsi qu’au niveau du client et du serveur. Ces données fournissent des informations essentielles pour résoudre les erreurs liées à SSL/TLS dans la configuration du proxy et dans les connexions aux clients et aux serveurs en amont. Le tableau de bord de surveillance de l’activité en temps réel de NGINX Plus a été mis à jour afin d’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 à la disposition de clients externes par l’intermédiaire d’un « service privé » dans AWS, Google Cloud Platform et Microsoft Azure, l’identifiant client propre au service, représenté par un vecteur type-longueur-valeur (TLV) dans l’en-tête du protocole PROXY v2, n’est par défaut pas transmis aux services backend. NGINX Plus R28 introduit des modules pour les contextes http et stream, qui décodent le TLV et définissent une variable permettant de transmettre l’identifiant client aux services backend.
• Prise en charge des variables pour le paramètre samesite du cookie persistant – Dans NGINX Plus R28, la valeur du paramètre samesite de la directive sticky cookie peut être une variable. Cette amélioration facilite la gestion du trafic et renforce la sécurité.

Pour compléter cette version viennent s’ajouter de nouvelles fonctionnalités et des corrections de bugs héritées de NGINX Open Source, ainsi que des mises à jour du module JavaScript de NGINX.

Modifications importantes du comportement

Remarque : Si vous effectuez une mise à niveau depuis une version autre que NGINX Plus R27, veillez à consulter la section « Modifications importantes du comportement » dans les billets d’annonce de toutes les versions comprises entre votre version actuelle et celle-ci.

Modifications de la prise en charge des plateformes

Nouveaux systèmes d’exploitation et nouvelles 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, dont la fin de vie (EOL) a été atteinte en août 2022

Anciens systèmes d’exploitation et anciennes architectures obsolètes dont la suppression est prévue dans NGINX Plus R29 :

• Alpine 3.13, dont la fin de vie a été atteinte le 1er novembre 2022

Modification de la gestion de plusieurs en-têtes portant le même nom

• La plupart des en-têtes de réponse en amont connus comme étant dupliqués sont désormais ignorés et un avertissement est émis
• Les en-têtes Content-Length et Transfer-Encoding en double sont désormais rejetés, tout comme les réponses contenant des en-têtes Content-Length ou Transfer-Encoding non valides, ou lorsque les deux en-têtes Content-Length et Transfer-Encoding sont présents dans la réponse

Nouvelles fonctionnalités en détail

Métriques TLS supplémentaires

L’observabilité des événements et erreurs SSL/TLS est importante pour résoudre les problèmes liés à TLS concernant 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 collecte trois métriques TLS à l’échelle du système :

• handshakes – Nombre de négociations SSL réussies
• handshakes_failed – Nombre d’échecs de négociation SSL (à l’exclusion des échecs de vérification du certificat qui surviennent après la négociation SSL)
• session_reuses – Nombre de réutilisations de sessions SSL

À partir de NGINX Plus R27<.htmla>, vous pouvez configurer la collecte des trois métriques pour chaque serveur en amont et chaque serveur virtuel.

NGINX Plus R28 enrichit l’ensemble des métriques TLS avec de nouveaux compteurs pour les erreurs de négociation et les échecs de validation des certificats 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 en savoir plus sur la configuration de la collecte des métriques pour chaque serveur en amont et serveur virtuel, consultez le blog d’annonce de NGINX Plus R27<.htmlspan>.

Erreurs de négociation

Les compteurs correspondant aux erreurs de négociation suivantes sont nouveaux dans NGINX Plus R28 :

• handshake_timeout – Nombre d’échecs de négociation dus à l’expiration du délai de négociation
• no_common_cipher – Nombre d’échecs de négociation dus à l’absence d’un chiffrement commun entre les parties impliquées dans 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 dus à l’absence de 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 à l’envoi 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 utilisant les directives propres à chaque protocole suivantes :
  • grpc_ssl_verify
  • proxy_ssl_verify[HTTP][Flux]
  • uwsgi_ssl_verify

Lorsqu’un échec de vérification du certificat se produit, la métrique correspondant à la cause concernée est incrémentée et la connexion est interrompue. Notez toutefois que le compteur de base handshakes est tout de même incrémenté, car ces échecs se produisent après la réussite de la négociation.

Les métriques relatives aux échecs de validation des certificats sont les suivantes :

• expired_cert – Le 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é
• other – Compteur explicite pour les autres échecs de vérification de certificat

Exemple de sortie des métriques

Voici un exemple de métriques TLS pour les connexions HTTP à l’échelle du système :

$ curl 127.0.0.1:8080/api/8/ssl{    "handshakes": 32,    "session_reuses": 0,    "handshakes_failed": 8,    "no_common_protocol": 4,    "no_common_cipher": 2,    "handshake_timeout": 0,    "peer_rejected_cert": 0,    "verify_failures": {        "no_cert": 0,        "expired_cert": 2,        "revoked_cert": 1,        "hostname_mismatch": 2,        "other": 1    }}

Voici un exemple de métriques 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 ce type de connexions) :

$ curl 127.0.0.1:8080/api/8/http/server_zones/s9{    ...    "ssl": {        "handshakes": 0,        "session_reuses": 0,        "handshakes_failed": 1,        "no_common_protocol": 0,        "no_common_cipher": 1,        "handshake_timeout": 0,        "peer_rejected_cert": 0,        "verify_failures": {            "no_cert": 0,            "expired_cert": 0,            "revoked_cert": 0,            "other": 0        }    }    ...}

Voici un exemple de métriques 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 ce type de connexions) :

$ curl 127.0.0.1:8080/api/8/http/upstreams/u2{    "peers": [        {            "id": 0,            "server": "127.0.0.1:8082",            "name": "127.0.0.1:8082",            ...            "ssl": {                "handshakes": 1,                "session_reuses": 0,                "handshakes_failed": 0,                "no_common_protocol": 0,                "handshake_timeout": 0,                "peer_rejected_cert": 0,                "verify_failures": {                    "expired_cert": 1,                    "revoked_cert": 0,                    "hostname_mismatch": 0,                    "other": 0                }            },            ...        }    ],}

Le tableau de bord NGINX Plus affiche les métriques TLS étendues

À partir de NGINX Plus R28, le tableau de bord de surveillance de l’activité en temps réel affiche les nouvelles métriques TLS décrites ci-dessus. Cette capture d’écran présente les métriques relatives aux connexions avec les clients. Pour afficher les nouvelles métriques, placez le pointeur de la souris sur la valeur de la colonne SSL > Échecs de négociation comme illustré.

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

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

• AWS PrivateLink – PP2_SUBTYPE_AWS_VPCE_ID
• GCP Private Service Connect – pscConnectionId
• Microsoft Azure Private Link – PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID

Par défaut, ces identifiants clients ne sont pas transmis aux services backend. 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 permettant de 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 les adresses IP et d’autres informations sur les clients, consultez la section « Acceptation du protocole PROXY » du Guide d’administration de NGINX Plus.

Prise en charge du protocole PROXY v2 pour AWS

Dans AWS, l’adresse IP source du trafic provenant de clients via un service de point de terminaison de cloud privé virtuel (VPC) est l’adresse IP privée du nœud de l’équilibreur de charge réseau. Si l’application backend a besoin des adresses IP réelles et d’autres identifiants des clients, elle peut les obtenir à partir des en-têtes du protocole PROXY v2.

Dans AWS, un vecteur TLV personnalisé encode l’ID du VPC du point de terminaison dans l’en-tête PROXY protocol 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 backend dans la variable « $proxy_protocol_tlv_aws_vpce_id ».

Remarque : Dans le bloc server où vous référencez la variable $proxy_protocol_tlv_aws_vpce_id, vous devez également inclure le paramètre proxy_protocol dans la directive listen[HTTP][Stream]. Pour obtenir un exemple, consultez la ligne 8 du fichier proxy_protocol_v2.conf ci-dessous.

Cet exemple de configuration pour AWS vérifie que l’ID du VPC est autorisé et, si c’est le cas, le transmet à l’application backend en tant que deuxième paramètre de la directive add_header :

Chargement de l’exemple de code…

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 appartenant à l’un des sous-réseaux Private Service Connect du réseau VPC du producteur de services ». Si l’application backend a besoin des adresses IP réelles et d’autres identifiants des clients, elle peut les obtenir à partir des en-têtes du protocole PROXY v2.

Dans GCP, un vecteur TLV personnalisé encode l’identifiant de connexion unique (à cet instant) 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 backend dans la variable $proxy_protocol_tlv_gcp_conn_id.

Remarque : Dans le bloc server où vous référencez la variable $proxy_protocol_tlv_gcp_conn_id, vous devez également inclure le paramètre proxy_protocol dans la directive listen[HTTP][Stream]. Pour obtenir un exemple, consultez la ligne 8 du fichier 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 « traduite par translation d’adresses réseau (NAT) côté fournisseur de services à l’aide de l’[adresse] IP NAT allouée à partir du réseau virtuel du fournisseur ». Si l’application backend a besoin des adresses IP réelles et d’autres identifiants des clients, ceux-ci 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 backend dans la variable « $proxy_protocol_tlv_azure_pel_id ».

Remarque : Dans le bloc server 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 obtenir un exemple, consultez la ligne 8 du fichier proxy_protocol_v2.conf ci-dessus.

Prise en charge des variables pour le paramètre samesite du cookie de persistance

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

Par défaut (en l’absence du paramètre « samesite »), NGINX n’ajoute pas l’attribut « SameSite » au cookie. Lorsque le paramètre « samesite » est une variable, le résultat dépend de la valeur prise par celle-ci lors de l’exécution :

• À l’une des valeurs standard (« strict », « lax » et « none ») – NGINX injecte l’attribut « SameSite » défini sur cette valeur
• À une valeur vide ("") – NGINX n’injecte pas l’attribut SameSite attribute
• À toute autre valeur, ce qui indique une erreur de 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 (ce qui convient aux anciens clients qui ne prennent pas en charge l’attribut SameSite ):

Chargement de l’exemple de code…

Autres améliorations de NGINX Plus R28

Modifications héritées de NGINX Open Source

NGINX Plus R28 est basé sur NGINX Open Source 1.23.2 et bénéficie des évolutions fonctionnelles et des corrections de bogues apportées depuis la sortie de NGINX Plus R27 (dans les versions NGINX 1.23.0 à 1.23.2). Ces évolutions et corrections comprennent notamment :

• Le nouveau paramètre « ipv4=off » de la directive HTTP resolver désactive la recherche d’adresses IPv4.
• Lorsque vous activez un cache partagé pour les informations de session HTTP à l’aide du paramètre « shared » de la directive « ssl_session_cache », les clés des tickets de session TLS font désormais l’objet d’une rotation automatique.
• Le niveau de gravité auquel plusieurs types d’erreurs TLS/SSL sont consignés passe de « crit » à « info ».

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

Modifications apportées au module JavaScript de NGINX

NGINX Plus R28 intègre les modifications et correctifs apportés dans les versions 0.7.5 à 0.7.8 du module JavaScript NGINX (njs). Nous avons présenté certains des plus importants dans l’article « Rendez votre configuration NGINX encore plus modulaire et réutilisable avec njs 0.7.7 » sur notre blog. Pour obtenir la liste complète, consultez le fichier « Modifications ».

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R28 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