1. Introduction (简介)

1. Introduction (简介)

对于HTTPS应用程序来说, 一种相当常见的部署模式是让源HTTP应用服务器位于反向代理 (reverse proxy) 之后, 该代理终止来自客户端的TLS连接。该代理可从互联网访问, 并将客户端请求分派到私有网络或受保护网络内的适当源服务器。源服务器不能被客户端直接访问, 只能通过反向代理访问。这种部署类型的后端细节对于向代理服务器发出请求的客户端来说通常是不透明的, 客户端看到的响应就好像是来自代理服务器本身。虽然代理和源服务器之间通常也使用HTTPS, 但客户端为HTTPS建立的TLS连接仅在其自身与反向代理服务器之间。

这种部署模式存在多种变体, 例如n层架构 (n-tier architectures), 内容分发网络 (content delivery networks), 应用负载均衡服务 (application load-balancing services) 和入口控制器 (ingress controllers)。

尽管并不特别普遍, 但有时会采用TLS客户端证书认证 (TLS client certificate authentication), 在这种情况下, 源服务器通常需要关于客户端证书的信息用于其应用逻辑。此类逻辑可能包括访问控制决策, 审计日志记录, 以及将已颁发的令牌 (tokens) 或cookie绑定到证书, 包括对此类绑定的相应验证。证书所需的具体细节也会随应用需求而变化。为了使这些类型的应用部署在实践中发挥作用, 反向代理需要向源应用服务器传递关于客户端证书的信息。在撰写本文时, 传递此信息的常见方式是使用非标准字段 (non-standard fields) 在分派到源服务器的HTTP请求中携带证书 (以某种编码形式) 或其个别部分。这个解决方案是有效的, 但独立开发的组件之间的互操作性可能会很麻烦甚至不可能, 这取决于各自所做的实现选择 (例如使用或可配置的字段名称, 公开证书的哪些部分, 或证书如何编码)。对于这种常见功能, 采用一种众所周知的可预测方法可以改善和简化独立实现之间的互操作性。

本文档的范围是描述现有实践, 同时编纂足以促进改进和更低接触互操作性的具体细节。因此, 本文档描述了两个HTTP头字段, "Client-Cert" 和 "Client-Cert-Chain", TLS终止反向代理 (TLS Terminating Reverse Proxy, TTRP) 将其添加到发送到后端源服务器的请求中。Client-Cert字段值包含来自发起客户端与TTRP之间相互认证的TLS连接的端实体客户端证书 (end-entity client certificate)。可选地, Client-Cert-Chain字段值包含用于验证端实体证书的证书链 (certificate chain)。这使得后端源服务器能够在其应用逻辑中利用客户端证书信息。虽然TTRP与源服务器之间可能存在额外的代理或跃点 (hops) (甚至它们之间可能存在相互认证的TLS连接), 但Client-Cert头字段的范围被有意限制为向源服务器公开发起客户端在其与TTRP的连接中提供的证书。