Cambios de Nginx 1.30 en Apigee Edge 4.54.00

Descripción general de los cambios de Nginx

Apigee Edge para nube privada 4.54.00 incluye una actualización obligatoria a la versión 1.30 de Nginx en los routers de Edge.

Con el lanzamiento de Nginx 1.26, se introdujeron varios cambios importantes para mejorar la seguridad y garantizar el cumplimiento de los estándares HTTP. Estas son las actualizaciones clave:

Control de espacios en blanco en nombres y valores de encabezados

Para mejorar la seguridad, se fortaleció el cumplimiento de RFC 7230, en particular en lo que respecta al control de espacios en blanco en los encabezados. Puedes encontrar más detalles sobre estos cambios en el Apéndice.

Control de los encabezados Content-Length y Transfer-Encoding

Una de las técnicas comunes que se usan en los ataques de contrabando de solicitudes implica enviar solicitudes HTTP con los encabezados Content-Length y Transfer-Encoding. Si bien Apigee Edge ya estaba reforzado contra este tipo de ataques, Nginx ahora bloquea explícitamente las solicitudes que contienen ambos encabezados. Si se envía una solicitud de este tipo, Nginx responderá con un error 400 Bad Request.

Cifrados compatibles

La lista de cifrados compatibles para las solicitudes de salida puede cambiar con esta versión. Puedes consultar los cifrados compatibles con OpenSSL en el host de tu router para obtener la lista actualizada de cifrados disponibles.

Tamaños de clave compatibles

Anteriormente, las claves RSA, DSA y DH menores que 2048 bits y las claves ECC menores que 224 bits se aceptaban de forma predeterminada. Sin embargo, con esta actualización, ya no se permitirán esas claves para las conexiones TLS unidireccionales y bidireccionales para las solicitudes de salida.

Apéndice

Espacios en blanco en los encabezados

Hay tres cambios principales:

  1. Nginx 1.26 ahora no permite ciertos nombres de encabezados que antes sí. Las solicitudes con estos encabezados generarán un error 400 Bad Request.
  2. Nginx 1.26 ahora no permite ciertos valores de encabezados que antes sí. Las solicitudes con estos encabezados también generarán un error 400 Bad Request.
  3. Algunos encabezados que Nginx aceptaba anteriormente, pero que causaban fallas en el Message Processor, ahora son rechazados directamente por Nginx. Aunque estos encabezados aún generan fallas en la API, los mensajes de falla HTTP cambiarán.

En la siguiente sección, se proporcionan ejemplos de varios nombres y valores de encabezados que no se permiten. Estos son solo ejemplos y es posible que la lista no sea exhaustiva. Se recomienda cumplir con los lineamientos de RFC 7230 para los encabezados.

Cambios en los nombres de los encabezados

En esta sección, se enumeran varios nombres de encabezados que se permitían en Nginx 1.20.1, pero que ahora no se permiten en Nginx 1.26.

Situación Ejemplos de nombres de encabezados
Carácter de control al principio, al final o entre el nombre del encabezado { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Espacio inicial y final en el nombre del encabezado {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
HTAB inicial y final en el nombre del encabezado {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Combinación inicial y final de HTAB, WS en el nombre del encabezado {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
NewLine (\n) entre el nombre del encabezado seguido inmediatamente por WS o una serie de WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
NewLine (\n) entre el nombre del encabezado seguido inmediatamente por HTAB o una serie de HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Retorno de carro (\r) NewLine (\n) entre el nombre del encabezado seguido inmediatamente por HTAB o una serie de HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Retorno de carro (\r) NewLine (\n) entre el nombre del encabezado seguido inmediatamente por WS o una serie de WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Cambios en los valores de los encabezados

En esta sección, se muestran varios valores de encabezados que se permitían en Nginx 1.20.1, pero que no se permiten en Nginx 1.26.

Situación Ejemplos
Se permite \r\n o la combinación de \r\n con WS o HTAB 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"}
Se permite \n o la combinación de \n con WS o HTAB 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"}

Cambio en la respuesta de falla HTTP

En esta sección, se abarcan los encabezados que permitía la versión anterior de Nginx, pero que rechazaba el procesador de mensajes ascendente, lo que generaba un código de estado 400. Sin embargo, en Nginx 1.26, esos encabezados causan fallas directamente en Nginx, lo que impide que la solicitud se reenvíe al Message Processor.

Para los clientes que envían esos encabezados, el código de estado HTTP seguirá siendo 400. Sin embargo, es posible que cambie el cuerpo de la respuesta HTTP, ya que la falla ahora la generará Nginx en lugar del Message Processor.

Situación Ejemplos
HTAB o WS entre HEADERNAME

El procesador de mensajes rechaza esas solicitudes. Con Nginx 1.26, Nginx rechazará esas solicitudes. El consumidor de la API recibirá una respuesta de error 400 con un mensaje de error de Nginx en el cuerpo.

 {"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"}