Apigee Edge 4.53.00 中的 Nginx 1.26 变更

Nginx 1.26 变更概览

随着 Nginx 1.26 的发布,我们引入了一些重要变更,以增强安全性并确保符合 HTTP 标准。以下是主要更新:

处理标头名称和值中的空格

为提高安全性,我们加强了对 RFC 7230 的遵从,尤其是在处理标头中的空格方面。如需详细了解这些变更,请参阅附录

处理 Content-LengthTransfer-Encoding 标头

请求走私攻击中常用的一个技术是发送同时包含 Content-LengthTransfer-Encoding 标头的 HTTP 请求。虽然 Apigee Edge 已针对此类攻击进行了防范,但 Nginx 现在会明确屏蔽包含这两个标头的请求。如果发送此类请求,Nginx 将返回 400 Bad Request 错误。

支持的加密方式

北向请求支持的密码列表可能会随此版本而发生变化。您可以检查路由器主机上 OpenSSL 支持的加密套件,以获取更新的可用加密套件列表。

支持的密钥大小

以前,系统默认接受小于 2048 位的 RSA、DSA 和 DH 密钥,以及小于 224 位的 ECC 密钥。不过,在此次更新后,对于南向请求,单向和双向 TLS 连接都不再允许使用此类密钥。

附录

标头中的空格

主要有以下三项变更:

  1. Nginx 1.26 现在不允许使用之前允许的某些标头名称。包含这些标头的请求将导致 400 Bad Request 错误。
  2. Nginx 1.26 现在不允许使用之前允许的某些标头值。包含这些标头的请求也会导致 400 Bad Request 错误。
  3. 之前由 Nginx 接受但导致消息处理器下游出现故障的一些标头现在会被 Nginx 直接拒绝。虽然这些标头仍会导致 API 失败,但 HTTP 失败消息将发生变化。

以下部分提供了各种不允许使用的标头名称和标头值的示例。下面只是列举了一些示例,可能并非详尽无遗。建议遵循 RFC 7230 中针对标头的准则。

标头名称的更改

本部分列出了 Nginx 1.20.1 中允许使用的各种标头名称,但现在 Nginx 1.26 中不允许使用。

场景 标头名称示例
标头名称开头、结尾或中间有控制字符 { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
标头名称中的前导和尾随空格 {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
标头名称中的前导和尾随 HTAB {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
标头名称中 HTAB 和 WS 的前导和尾随组合 {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
标头名称之间有换行符 (\n),紧随其后的是 WS 或一系列 WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
标头名称之间插入换行符 (\n),紧随其后是 HTAB 或一系列 HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
标头名称之间包含回车符 (\r) 和换行符 (\n),紧随其后的是 HTAB 或一系列 HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
标头名称之间包含回车符 (\r) 和换行符 (\n),后跟 WS 或一系列 WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

标头值的更改

本部分列出了 Nginx 1.20.1 中允许但 Nginx 1.26 中不允许的各种标头值。

场景 示例
HEADERVALUE 之间允许使用 \r\n 或 \r\n 与 WS 或 HTAB 的组合 {"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"}
允许在 HEADERVALUE 之间使用 \n 或 \n 与 WS 或 HTAB 的组合 {"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"}

HTTP 失败响应发生变化

本部分介绍了旧版 Nginx 允许但上游消息处理器拒绝的标头,这会导致返回 400 状态代码。不过,在 Nginx 1.26 中,此类标头会直接在 Nginx 中导致失败,从而阻止将请求转发到消息处理器。

对于发送此类标头的客户端,HTTP 状态代码将保持 400。不过,HTTP 响应正文可能会发生变化,因为失败现在将由 Nginx 而非消息处理器生成。

场景 示例
HEADERNAME 之间有 HTAB 或 WS

消息处理器会拒绝此类请求。在 Nginx 1.26 中,Nginx 本身会拒绝这些请求。API 使用方将收到 400 错误响应,其中正文中包含 Nginx 错误消息。

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