互联网工程任务组 (IETF) B. Campbell
请求注释： 9440 Ping Identity
类别：信息性 M. Bishop，编辑
ISSN: 2070-1721 Akamai
2023 年 7 月

Client-Cert HTTP 头字段

摘要

本文档描述了 HTTP 扩展头字段，使 TLS 终止的反向代理（TTRP）能够以通用且可预测的方式将双向认证 TLS 连接的客户端证书信息传递给源服务器。

本备忘录的状态

本文档不是互联网标准轨道规范；其发布为信息性文档。

本文档是互联网工程任务组 (IETF) 的产物。它代表了 IETF 社区的共识。它已接受公开审查并已获互联网工程指导小组 (IESG) 批准发布。并非所有经 IESG 批准的文档都适合作为任何级别的互联网标准；参见 RFC 7841 第2节。

有关本文档的当前状态、任何勘误以及如何提供反馈的信息，可在 https://www.rfc-editor.org/info/rfc9440 查询。

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

1. 简介

HTTPS 应用的一个相当常见的部署模式是将源 HTTP 应用服务器置于一个终止来自客户端 TLS 连接的反向代理之后。该代理可被 Internet 访问，并将客户端请求分发到私有或受保护网络中的相应源服务器。源服务器对客户端不可直接访问，只能通过反向代理到达。这类部署的后端细节通常对向代理服务器发出请求并将响应视为来自代理服务器本身的客户端来说是不可见的。尽管在代理与源服务器之间通常也采用 HTTPS，但客户端为 HTTPS 建立的 TLS 连接仅存在于客户端与反向代理服务器之间。

该部署模式存在多种变体，例如 n 层架构、内容分发网络、应用负载均衡服务和 ingress 控制器等。

虽然不算特别普遍，但有时会使用 TLS 客户端证书认证，在这种情况下，源服务器通常需要有关客户端证书的信息以供其应用逻辑使用。此类逻辑可能包括访问控制决策、审计日志记录，以及将签发的令牌或 cookie 绑定到证书（以及对这些绑定的相应验证）。所需的证书具体细节也随应用要求而异。为了使这类应用部署在实践中可行，反向代理需要将关于客户端证书的信息传递给源应用服务器。在撰写本文档时，一种常见的做法是使用非标准字段在分发到源服务器的 HTTP 请求中携带证书（以某种编码）或其各个部分。这种解决方案可行，但独立开发的组件之间的互操作性可能因为实现选择（例如使用或可配置的字段名、暴露证书的哪些部分、或证书如何编码）而变得繁琐甚至不可能。为这种常见功能提供一种广为人知且可预测的方法，可以改善并简化独立实现之间的互操作性。

本文档的范围是描述现有做法，同时对足以促进改进并降低互操作成本的具体细节进行编码。因此，本文档描述了两个 HTTP 头字段 "Client-Cert" 和 "Client-Cert-Chain"，TLS 终止的反向代理（TTRP）在向后端源服务器发送请求时会添加它们。Client-Cert 字段值包含发起客户端与 TTRP 之间相互认证 TLS 连接中使用的终端实体（end-entity）客户端证书。可选地，Client-Cert-Chain 字段值包含用于验证该终端实体证书的证书链。这使得后端源服务器能够在其应用逻辑中使用客户端证书信息。尽管在 TTRP 与源服务器之间可能存在额外的代理或跳数（甚至它们之间可能也有相互认证的 TLS 连接），但 Client-Cert 头字段的范围有意被限制为向源服务器暴露原始客户端在其与 TTRP 的连接中所呈现的证书。

1.1. 需求标注与约定

本文档中关键字 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY” 和 “OPTIONAL” 应按 BCP 14 中的定义解释（见 RFC2119 与 RFC8174），仅当这些词以全大写形式出现时按此解释。

1.2. 术语与适用性

本文档使用来自 RFC8941 第 3 节的术语以指定语法和解析：List 和 Byte Sequence。

本文档中经常使用短语如 “TLS 客户端证书认证” 或 “相互认证的 TLS”（mutually authenticated TLS），指的是在正常的 TLS 服务器证书认证之外，客户端在协商 TLS 连接或恢复该连接时向服务器出示其 X.509 证书并证明对相应私钥的持有。在当前版本的 TLS（见 RFC8446/TLS 1.3 与 RFC5246/TLS1.2）中，相互认证要求客户端在握手期间发送 Certificate 和 CertificateVerify 消息，并要求服务器验证 CertificateVerify 与 Finished 消息。

HTTP/2 限制了 TLS 1.2 的重新协商（参见 RFC9113 第 9.2.1 节），并禁止 TLS 1.3 的后握手认证（参见 RFC9113 第 9.2.3 节）。然而，它们有时被用于在 HTTP/1.1 中实现反应式的客户端证书认证，其中服务器根据 HTTP 请求决定是否请求客户端证书。在这样的连接上，在接收并验证客户端证书之后发送的 HTTP 应用数据也是相互认证的，因此适用于本文档中描述的机制。使用后握手认证时，也存在（在实践中不太可能）在连接上来自客户端的多个证书和证书链的可能性。在这种情况下，应仅使用最后一次后握手认证的证书和链来填充本文所述的头字段。

2. HTTP 头字段及处理规则

本文档指定以下头字段（在第 2.2 节 和 第 2.3 节 中进一步定义），用于携带相互认证 TLS 连接的客户端证书信息。该等头字段将信息从反向代理传递到源服务器。

Client-Cert:
客户端在与反向代理进行 TLS 握手时使用的终端实体证书。
Client-Cert-Chain:
用于验证客户端在与反向代理进行 TLS 握手时提供的终端实体证书的证书链。

2.1. 编码

本文档中的头字段将证书编码为 Byte Sequences（参见 RFC8941 第 3.3.5 节），其中二进制数据的值为 DER 编码的 ITU.X690/X.509 证书（参见 RFC5280）。实际上，这意味着二进制 DER 证书使用 base64 编码（不带换行、空格或 base64 字母表之外的字符），并在两侧用冒号分隔。

注意证书通常以某种文本编码格式存储，例如 RFC7468 第 5.1 节 所述的格式，这种格式已经几乎与 Byte Sequence 兼容。如果证书以该文本格式编码，只需将 "-----BEGIN CERTIFICATE-----" 和 "-----END CERTIFICATE-----" 替换为 ":" 并移除换行，即可生成合适的项。

2.3. Client-Cert-Chain HTTP 头字段

在 TLS 终止的反向代理部署场景中，代理MAY通过 Client-Cert-Chain HTTP 头字段将证书链提供给后端应用。

Client-Cert-Chain 是一个 List（见 RFC8941 第 3.1 节）。List 中的每个项MUST是按第 2.1 节 所述 编码的 Byte Sequence。顺序与 TLS 中的顺序相同（见 RFC8446 第 4.4.2 节）。

除非同时存在 Client-Cert，否则 Client-Cert-ChainMUST NOT 出现，并且其自身不应包含已经在 Client-Cert 中存在的终端实体证书。根证书MAY从 Client-Cert-Chain 中省略，前提是目标源服务器已知具有被省略的信任锚。

Client-Cert-Chain 头字段仅用于 HTTP 请求，MUST NOT 用于 HTTP 响应。它MAY包含值列表或在请求中出现多次。为了头压缩的目的，将列表拆分为多个实例可能具有优势。

附录 A 中的 图 3 给出了 Client-Cert-Chain 头字段的示例。

2.4. 处理规则

本节概述了 TTRP 在协商相互认证 TLS 连接并将该连接中的客户端证书传递给后端源服务器时适用的处理规则。该技术应作为一种配置或部署选项使用，本节所述的处理规则适用于启用该选项的服务器。

TTRP 与客户端协商使用相互认证的 TLS 连接（例如 RFC8446/TLS 或 RFC5246/TLS1.2 所述），并根据其策略和受信任的证书颁发机构验证客户端证书。基础 TLS 连接上的每个 HTTP 请求在分发到源服务器时应作如下修改：

  1. The client certificate is placed in the Client-Cert header field of the dispatched request, as described in Section 2.2.
  2. If so configured, the validation chain of the client certificate is placed in the Client-Cert-Chain header field of the request, as described in Section 2.3.
  3. Any occurrence of the Client-Cert or Client-Cert-Chain header fields in the original incoming request MUST be removed or overwritten before forwarding the request. An incoming request that has a Client-Cert or Client-Cert-Chain header field MAY be rejected with an HTTP 400 response.

在与 TTRP 之间的 TLS 连接上未协商使用客户端证书认证的请求，MUST 在转发到后端服务器之前清除所有出现的 Client-Cert 和 Client-Cert-Chain 头字段。

后端源服务器随后可以使用请求中的 Client-Cert 头字段来确定客户端到 TTRP 的连接是否是相互认证的，以及在是的情况下客户端所呈现的证书。基于客户端证书（或其缺失）的访问控制决策可以通过选择适当的响应内容或返回 HTTP 403 响应来传达（如果在给定上下文中证书被视为不可接受）。注意，依赖于 TLS 层错误指示来处理不可接受证书的 TLS 客户端将不会接收到这些信号。

当使用 Client-Cert 请求头字段的值来选择响应（例如，响应内容受访问控制）时，响应MUST要么不可缓存（例如，通过发送 Cache-Control: no-store），要么仅在随后请求具有相同 Client-Cert 请求头字段值时可选择重用（通过发送 "Vary: Client-Cert" 响应头）。如果 TTRP 遇到包含 Client-Cert 或 Client-Cert-Chain 的 Vary 响应头字段（见 RFC9110 第 12.5.5 节），它SHOULD通过将 Vary 响应头字段的值转换为 "*" 来阻止用户代理缓存该响应。

前向代理和其他中间节点MUST NOT 向请求添加或修改 Client-Cert 或 Client-Cert-Chain 头字段。同样，客户端MUST NOT 在请求中使用 Client-Cert 或 Client-Cert-Chain 头字段。

3. 部署注意事项

3.1. 头字段压缩

如果 TTRP 与源之间的连接支持字段压缩（例如 HPACK 或 QPACK），并且 TTRP 在该连接中复用多个客户端的请求，则 Client-Cert 与 Client-Cert-Chain 字段值的大小和差异性会显著降低压缩效率。源可以通过增大动态表的大小来缓解效率损失。如果 TTRP 判断源的动态表不够大，则可能更有利的是始终将字段值作为字面量发送，而不是将其写入动态表。

3.2. 消息头大小

接收方如果收到超出其愿意处理的消息头大小，可以根据 RFC6585 第 5 节 返回 HTTP 431（Request Header Fields Too Large）状态码。由于包含证书数据的字段值通常较大，接收方可能需要配置为允许更大的最大头大小。生成客户端证书头字段的中间节点在能够通告可接受的最大头大小（例如 HTTP/2 或 HTTP/3）时，应考虑其发送的请求头大小与其接收的请求头大小之间的差异，通过向客户端通告一个足够较小的值以允许添加证书数据。

3.3. TLS 会话恢复

一些 TLS 实现不会在会话恢复时保留客户端证书信息。在恢复时提供不一致的 Client-Cert 与 Client-Cert-Chain 值可能导致错误，因此无法提供这些值的实现SHOULD要么为带有客户端证书的连接禁用恢复，要么在可能在恢复后不可用时最初省略 Client-Cert 或 Client-Cert-Chain 字段。

4. 安全性考虑

此处描述的头字段使得 TTRP 与后端或源服务器能够协同工作，使得从客户端的角度看它们如同在相互认证的 TLS 连接上作为单一逻辑服务器端部署的 HTTPS。然而，在该预期用例之外使用这些头字段可能会削弱 TLS 客户端证书认证所提供的保护。因此，需要采取下述步骤以防止头字段在发送或依赖其值时的意外滥用。

生成与消费 Client-Cert 和 Client-Cert-Chain 头字段应当分别在 TTRP 与后端服务器（或服务器中的个别应用）中作为可配置选项。两者的默认配置应为不使用这些头字段，从而需要“显式启用”该功能。

为了防止字段注入，后端服务器MUST仅接受来自受信任 TTRP（或来自 TTRP 的受信任路径中的其他代理）的 Client-Cert 与 Client-Cert-Chain 头字段。TTRPMUST在转发前对传入请求进行消毒，移除或覆盖任何已存在的这些字段。否则，任意客户端可以控制后端服务器所见和使用的字段值。需要注意的是，忽视防止字段注入并不会“安全失败”，即名义功能在存在恶意行为时仍可能按预期工作。因此，建议在确保适当字段消毒方面格外谨慎。

TTRP 与后端服务器之间的通信需要针对窃听和未授权修改进行保护。

配置选项与请求消毒是各自服务器所需的功能。其他要求可以通过多种方式满足，因具体部署而异。例如，TTRP 与后端或源服务器之间的通信可能以某种方式进行身份验证，从而仅在该连接上插入和消费 Client-Cert 与 Client-Cert-Chain 头字段。附录 B.3 在 HTTPSIG（HTTP Message Signatures）中给出了其中一种示例。或者，网络拓扑可能规定后端应用仅能接受来自 TTRP 的请求，且代理只能向该服务器发出请求。也存在满足本文要求的其他部署方式。

5. IANA 注意事项

5.1. HTTP 字段名注册

IANA 已在 “Hypertext Transfer Protocol (HTTP) Field Name Registry”（由 "HTTP Semantics" 定义）中注册了以下条目：

Table 1: Hypertext Transfer Protocol (HTTP) Field Name Registry
Field Name Status Reference
Client-Cert permanent RFC 9440, Section 2
Client-Cert-Chain permanent RFC 9440, Section 2

6. 参考文献

6.2. 补充参考文献

[HPACK]
Peon, R. and H. Ruellan, “HPACK: Header Compression for HTTP/2”, RFC 7541, DOI 10.17487/RFC7541, May 2015, <https://www.rfc-editor.org/info/rfc7541>.
[HTTP/1.1]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP/1.1”, STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[HTTP/2]
Thomson, M., Ed. and C. Benfield, Ed., “HTTP/2”, RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.
[HTTP/3]
Bishop, M., Ed., “HTTP/3”, RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[HTTPSIG]
Backman, A., Ed., Richer, J., Ed., and M. Sporny, “HTTP Message Signatures”, draft-ietf-httpbis-message-signatures-17, Work in Progress, May 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-17>.
[QPACK]
Krasic, C., Bishop, M., and A. Frindell, Ed., “QPACK: Field Compression for HTTP/3”, RFC 9204, DOI 10.17487/RFC9204, June 2022, <https://www.rfc-editor.org/info/rfc9204>.
[RFC6585]
Nottingham, M. and R. Fielding, “Additional HTTP Status Codes”, RFC 6585, DOI 10.17487/RFC6585, April 2012, <https://www.rfc-editor.org/info/rfc6585>.
[RFC7239]
Petersson, A. and M. Nilsson, “Forwarded HTTP Extension”, RFC 7239, DOI 10.17487/RFC7239, June 2014, <https://www.rfc-editor.org/info/rfc7239>.
[RFC7468]
Josefsson, S. and S. Leonard, “Textual Encodings of PKIX, PKCS, and CMS Structures”, RFC 7468, DOI 10.17487/RFC7468, April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC8705]
Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens”, RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/info/rfc8705>.
[TLS1.2]
Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[TLS]
Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

Appendix A. 示例

在一个假设示例中，如果 TLS 客户端在与 TTRP 建立相互认证的 TLS 连接时会出示来自 图 1 的客户端和中间证书，则代理会向后端发送附录中 图 2 所示的 Client-Cert 字段。请注意，图 2 与图 3 中的字段值仅为显示和格式化目的而添加了换行和额外空格。 

-----BEGIN CERTIFICATE-----
MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJMZXQncyBB
dXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0yMDAx
MTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmckC8vdgJ1p
5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDVR0TBAIw
ADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf8EBAMC
BsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV4YW1w
bGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6bMje
SkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIB5jCCAYugAwIBAgIBFjAKBggqhkjOPQQDAjBWMQswCQYDVQQGEwJVUzEbMBkG
A1UECgwSTGV0J3MgQXV0aGVudGljYXRlMSowKAYDVQQDDCFMZXQncyBBdXRoZW50
aWNhdGUgUm9vdCBBdXRob3JpdHkwHhcNMjAwMTE0MjEzMjMwWhcNMzAwMTExMjEz
MjMwWjA6MRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxB
IEludGVybWVkaWF0ZSBDQTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJf+aA54
RC5pyLAR5yfXVYmNpgd+CGUTDp2KOGhc0gK91zxhHesEYkdXkpS2UN8Kati+yHtW
CV3kkhCngGyv7RqjZjBkMB0GA1UdDgQWBBRm3WjLa38lbEYCuiCPct0ZaSED2DAf
BgNVHSMEGDAWgBTEA2Q6eecKu9g9yb5glbkhhVINGDASBgNVHRMBAf8ECDAGAQH/
AgEAMA4GA1UdDwEB/wQEAwIBhjAKBggqhkjOPQQDAgNJADBGAiEA5pLvaFwRRkxo
mIAtDIwg9D7gC1xzxBl4r28EzmSO1pcCIQCJUShpSXO9HDIQMUgH69fNDEMHXD3R
RX5gP7kuu2KGMg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICBjCCAaygAwIBAgIJAKS0yiqKtlhoMAoGCCqGSM49BAMCMFYxCzAJBgNVBAYT
AlVTMRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdGUxKjAoBgNVBAMMIUxldCdz
IEF1dGhlbnRpY2F0ZSBSb290IEF1dGhvcml0eTAeFw0yMDAxMTQyMTI1NDVaFw00
MDAxMDkyMTI1NDVaMFYxCzAJBgNVBAYTAlVTMRswGQYDVQQKDBJMZXQncyBBdXRo
ZW50aWNhdGUxKjAoBgNVBAMMIUxldCdzIEF1dGhlbnRpY2F0ZSBSb290IEF1dGhvc
ml0eTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABFoaHU+Z5bPKmGzlYXtCf+E6H
Yj62fORaHDOrt+yyh3H/rTcs7ynFfGn+gyFsrSP3Ez88rajv+U2NfD0o0uZ4PmjY
zBhMB0GA1UdDgQWBBTEA2Q6eecKu9g9yb5glbkhhVINGDAfBgNVHSMEGDAWgBTEA
2Q6eecKu9g9yb5glbkhhVINGDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQE
AwIBhjAKBggqhkjOPQQDAgNIADBFAiEAmAeg1ycKHriqHnaD4M/UDBpQRpkmdcRF
YGMg1Qyrkx4CIB4ivz3wQcQkGhcsUZ1SOImd/lq1Q0FLf09rGfLQPWDc
-----END CERTIFICATE-----

Figure 1: Certificate Chain (with Client Certificate First)

Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJ
 MZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0
 yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFkwEwYHKoZ
 Izj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmckC8vdgJ1p5Be
 5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDVR0TBAIwADAfBgN
 VHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf8EBAMCBsAwEwYDVR0
 lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV4YW1wbGUuY29tMAoGCCq
 GSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6bMjeSkC3dFCOOB8TAiEAx/k
 HSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:

Figure 2: Header Field in HTTP Request to Origin Server

如果代理也配置为包含证书链，则还会包含 Client-Cert-Chain 头字段。请注意，尽管下面的示例演示了 TTRP 插入根证书，但许多部署会选择省略信任锚。

Client-Cert-Chain: :MIIB5jCCAYugAwIBAgIBFjAKBggqhkjOPQQDAjBWMQsw
 CQYDVQQGEwJVUzEbMBkGA1UECgwSTGV0J3MgQXV0aGVudGljYXRlMSowKAYDVQQ
 DDCFMZXQncyBBdXRoZW50aWNhdGUgUm9vdCBBdXRob3JpdHkwHhcNMjAwMTE0Mj
 EzMjMwWhcNMzAwMTExMjEzMjMwWjA6MRswGQYDVQQKDBJMZXQncyBBdXRoZW50a
 WNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTBZMBMGByqGSM49AgEG
 CCqGSM49AwEHA0IABJf+aA54RC5pyLAR5yfXVYmNpgd+CGUTDp2KOGhc0gK91zx
 hHesEYkdXkpS2UN8Kati+yHtWCV3kkhCngGyv7RqjZjBkMB0GA1UdDgQWBBRm3W
 jLa38lbEYCuiCPct0ZaSED2DAfBgNVHSMEGDAWgBTEA2Q6eecKu9g9yb5glbkhh
 VINGDASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjAKBggqhkjO
 PQQDAgNJADBGAiEA5pLvaFwRRkxomIAtDIwg9D7gC1xzxBl4r28EzmSO1pcCIQC
 JUShpSXO9HDIQMUgH69fNDEMHXD3RRX5gP7kuu2KGMg==:, :MIICBjCCAaygAw
 IBAgIJAKS0yiqKtlhoMAoGCCqGSM49BAMCMFYxCzAJBgNVBAYTAlVTMRswGQYDV
 QQKDBJMZXQncyBBdXRoZW50aWNhdGUxKjAoBgNVBAMMIUxldCdzIEF1dGhlbnRp
 Y2F0ZSBSb290IEF1dGhvcml0eTAeFw0yMDAxMTQyMTI1NDVaFw00MDAxMDkyMTI
 1NDVaMFYxCzAJBgNVBAYTAlVTMRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdG
 UxKjAoBgNVBAMMIUxldCdzIEF1dGhlbnRpY2F0ZSBSb290IEF1dGhvcml0eTBZM
 BMGByqGSM49AgEGCCqGSM49AwEHA0IABFoaHU+Z5bPKmGzlYXtCf+E6HYj62fOR
 aHDOrt+yyh3H/rTcs7ynFfGn+gyFsrSP3Ez88rajv+U2NfD0o0uZ4PmjYzBhMB0
 GA1UdDgQWBBTEA2Q6eecKu9g9yb5glbkhhVINGDAfBgNVHSMEGDAWgBTEA2Q6ee
 cKu9g9yb5glbkhhVINGDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBh
 jAKBggqhkjOPQQDAgNIADBFAiEAmAeg1ycKHriqHnaD4M/UDBpQRpkmdcRFYGMg
 1Qyrkx4CIB4ivz3wQcQkGhcsUZ1SOImd/lq1Q0FLf09rGfLQPWDc:

Figure 3: Certificate Chain in HTTP Request to Origin Server

Appendix B. 若干设计考虑

B.1. 字段注入

本文档要求 TTRP 对传入请求的字段进行消毒，在将请求转发到后端应用之前移除或覆盖任何已存在的 Client-Cert 和 Client-Cert-Chain 头字段。否则，客户端可能注入其自己的值，使后端误以为这些值来自 TTRP。虽然存在许多其他检测和防止字段注入的方法，例如在字段名或字段值中使用唯一的秘密值，或应用签名、HMAC 或 AEAD，但没有通用的通用机制。客户端字段注入的问题并非本文档特有；因此为本文档定义一次性解决方案并不合适。鉴于当前不存在通用的通用解决方案，去除和消毒字段是实践中对抗字段注入的事实手段。正确实现时，字段消毒足以提供保护，并且是第 4 节（Security Considerations）的规范性要求。

B.2. Forwarded HTTP 扩展

RFC7239 定义的 Forwarded HTTP 头字段允许代理组件公开在代理过程中丢失的信息。本文关注的 TLS 客户端证书信息本可以作为 Forwarded 字段的扩展参数进行通信；然而那样做会带来一些本文力求避免的缺点。Forwarded 字段语法允许表达关于多跳代理 HTTP 请求链的完整信息，而本文档的 Client-Cert 与 Client-Cert-Chain 头字段仅关注将发起客户端在与 TTRP 的 TLS 连接中所呈现的证书信息传递给后端应用。Forwarded 的多跳语法虽然表达力强，但也更复杂，会使处理更繁琐，更重要的是，会使按照第 4 节 的要求正确清理其内容以防止字段注入变得更加困难且容易出错。因此，本文档选择了更扁平且更直接的结构。

B.3. 整个证书与证书链

不同应用对来自客户端证书的信息需求各不相同，例如主体和/或颁发者的可辨别名称、主题备用名、序列号、主体公钥信息、指纹等。此外，一些应用（如 RFC8705 所述的方案）使用整个证书。为了兼容后者并通过不挑选证书的特定信息来确保广泛适用性，本文档选择将完整的编码证书作为 Client-Cert 字段的值传递。

相互认证 TLS 连接的客户端证书和链的验证通常由 TTRP 在握手期间执行。由于证书验证的责任落在 TTRP 上，终端实体证书通常足以满足源服务器的需求。对于需要额外信息的源服务器部署，可以通过单独的 Client-Cert-Chain 字段传递证书链。

致谢

作者想感谢以下在不同方面为本文档作出贡献的个人，他们的贡献范围从对推进本文档总体的支持到提供具体的反馈或内容：

  • Evan Anderson

  • Annabelle Backman

  • Alan Frindell

  • Rory Hewitt

  • Fredrik Jeansson

  • Benjamin Kaduk

  • Torsten Lodderstedt

  • Kathleen Moriarty

  • Mark Nottingham

  • Erik Nygren

  • Mike Ounsworth

  • Lucas Pardue

  • Matt Peterson

  • Eric Rescorla

  • Justin Richer

  • Michael Richardson

  • Joe Salowey

  • Rich Salz

  • Mohit Sethi

  • Rifaat Shekh-Yusef

  • Travis Spencer

  • Nick Sullivan

  • Willy Tarreau

  • Martin Thomson

  • Peter Wu

  • Hans Zandbelt

作者地址

Brian Campbell
Ping Identity
EMail: bcampbell@pingidentity.com
Mike Bishop (editor)
Akamai
EMail: mbishop@evequefou.be