Modifications apportées à Nginx 1.30 dans Apigee Edge 4.54.00

Présentation des modifications apportées à Nginx

Apigee Edge pour le cloud privé 4.54.00 inclut une mise à niveau obligatoire vers Nginx version 1.30 sur les routeurs Edge.

Avec la sortie de Nginx 1.26, plusieurs modifications importantes ont été apportées pour améliorer la sécurité et garantir la conformité aux normes HTTP. Voici les principales mises à jour :

Gestion des espaces blancs dans les noms et les valeurs d'en-tête

Pour améliorer la sécurité, le respect de la RFC 7230 a été renforcé, en particulier en ce qui concerne la gestion des espaces blancs dans les en-têtes. Pour en savoir plus sur ces modifications, consultez l'annexe.

Gestion des en-têtes Content-Length et Transfer-Encoding

L'une des techniques courantes utilisées dans les attaques de trafic de requêtes consiste à envoyer des requêtes HTTP avec les en-têtes Content-Length et Transfer-Encoding. Bien qu'Apigee Edge soit déjà protégé contre de telles attaques, Nginx bloque désormais explicitement les requêtes contenant les deux en-têtes. Si une telle requête est envoyée, Nginx répond avec une erreur 400 Bad Request.

Algorithmes de chiffrement compatibles

La liste des algorithmes de chiffrement compatibles pour les requêtes en amont peut changer avec cette version. Vous pouvez vérifier les algorithmes de chiffrement compatibles avec OpenSSL sur votre hôte de routeur pour obtenir la liste mise à jour des algorithmes de chiffrement disponibles.

Tailles de clé compatibles

Auparavant, les clés RSA, DSA et DH inférieures à 2 048 bits, ainsi que les clés ECC inférieures à 224 bits, étaient acceptées par défaut. Toutefois, avec cette mise à jour, ces clés ne seront plus autorisées pour les connexions TLS unidirectionnelles et bidirectionnelles pour les requêtes en amont.

Annexe

Espaces blancs dans les en-têtes

Trois modifications principales ont été apportées :

  1. Certains noms d'en-tête qui étaient auparavant autorisés sont désormais interdits par Nginx 1.26. Les requêtes avec ces en-têtes génèrent une erreur 400 Bad Request.
  2. Certaines valeurs d'en-tête qui étaient auparavant autorisées sont désormais interdites par Nginx 1.26. Les requêtes avec ces en-têtes génèrent également une erreur 400 Bad Request.
  3. Certains en-têtes qui étaient auparavant acceptés par Nginx, mais qui entraînaient des échecs en aval dans le processeur de messages, sont désormais directement rejetés par Nginx. Bien que ces en-têtes entraînent toujours des échecs d'API, les messages d'échec HTTP changent.

La section ci-dessous fournit des exemples de différents noms et valeurs d'en-tête qui ne sont pas autorisés. Il ne s'agit que d'exemples et la liste n'est peut-être pas exhaustive. Il est recommandé de respecter les consignes de la RFC 7230 pour les en-têtes.

Modifications apportées aux noms d'en-tête

Cette section répertorie différents noms d'en-tête qui étaient autorisés dans Nginx 1.20.1, mais qui ne le sont plus dans Nginx 1.26.

Scénario Exemples de noms d'en-tête
Caractère de contrôle au début, à la fin ou entre le nom d'en-tête { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Espaces blancs au début et à la fin du nom d'en-tête {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
HTAB au début et à la fin du nom d'en-tête {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Combinaison de HTAB et d'espaces blancs au début et à la fin du nom d'en-tête {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
Saut de ligne (\n) entre le nom d'en-tête, suivi immédiatement d'un espace blanc ou d'une série d'espaces blancs {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Saut de ligne (\n) entre le nom d'en-tête, suivi immédiatement d'un HTAB ou d'une série de HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Retour chariot (\r) et saut de ligne (\n) entre le nom d'en-tête, suivis immédiatement d'un HTAB ou d'une série de HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Retour chariot (\r) et saut de ligne (\n) entre le nom d'en-tête, suivis immédiatement d'un espace blanc ou d'une série d'espaces blancs {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Modifications apportées aux valeurs d'en-tête

Cette section présente différentes valeurs d'en-tête qui étaient autorisées dans Nginx 1.20.1, mais qui ne le sont plus dans Nginx 1.26.

Scénario Exemples
\r\n ou combinaison de \r\n avec un espace blanc ou un HTAB autorisé entre HEADERVALUE {"Header47", "Value47\r\n MultiLine"},
{"Header48", "Value48\r\n MultiLine"},
{"Header49b", "Value49b\r\n \r\nMultiLine"},
{"Header50", "Value50 \r\n MultiLine"},
{"Header51", "Value51\r\n\tMultiLine"},
{"Header52", "Value52\r\n\t\tMultiLine"},
{"Header53", "Value53\t\r\n\tMultiLine"}
\n ou combinaison de \n avec un espace blanc ou un HTAB autorisé entre HEADERVALUE {"Header61", "Value\n 61Multiline"},
{"Header62", "Value\n 63Multiline"},
{"Header65", "Value\n\t65"},
{"Header66", "Value\n\t\t66"},
{"Header67", "Value\n 67"},
{"Header68", "Value\n 68"}

Modification de la réponse d'échec HTTP

Cette section couvre les en-têtes qui étaient autorisés par l'ancienne version de Nginx, mais qui étaient rejetés par le processeur de messages en amont, ce qui entraînait un code d'état 400. Toutefois, dans Nginx 1.26, ces en-têtes entraînent des échecs directement dans Nginx, ce qui empêche la requête d'être transmise au processeur de messages.

Pour les clients qui envoient de tels en-têtes, le code d'état HTTP reste 400. Toutefois, le corps de la réponse HTTP peut changer, car l'échec est désormais généré par Nginx au lieu du processeur de messages.

Scénario Exemples
HTAB ou espace blanc entre HEADERNAME

Le processeur de messages rejette ces requêtes. Avec Nginx 1.26, ces requêtes sont rejetées par Nginx lui-même. Le consommateur d'API reçoit une réponse d'erreur 400 avec un message d'erreur Nginx dans le corps.

 {"Header 5", "Value5"},
{"Header\t14", "Value14"},
{"Header\t 32", "Value32"},
{"Header \t33", "Value33"},
{"Header- 36", "Value36"},
{"Header-\t40", "Value40"},
{"Header 4a", "Value4a"},
{"Header\t 59", "Value59"},
{"Header\t 60", "Value60"}