4. 安全考虑

4. 安全考虑

本文所述头字段使 TTRP 与后端或源服务器能够协同工作, 从客户端视角看, 它们就像是在相互认证 TLS 连接上运行 HTTPS 的单个逻辑服务器端部署. 但是, 在预期用例之外使用这些头字段, 可能削弱 TLS 客户端证书认证所提供的保护. 因此, 无论是在发送该头字段时, 还是在依赖其值时, 都需要采取如下所述的步骤来防止非预期使用.

生成和消费 Client-Cert 与 Client-Cert-Chain 头字段应 (SHOULD) 分别是 TTRP 和后端服务器 (或该服务器中单个应用) 的可配置选项. 两者的默认配置都应是不使用这些头字段, 因而要求显式 "选择加入" 该功能.

为了防止字段注入, 后端服务器必须 (MUST) 只接受来自受信任 TTRP (或从 TTRP 开始的受信任路径上的其他代理) 的 Client-Cert 和 Client-Cert-Chain 头字段. TTRP 在继续转发传入请求之前, 必须 (MUST) 通过移除或覆盖这些字段的任何现有实例来清理请求. 否则, 任意客户端都可以控制后端服务器所看到并使用的字段值. 需要特别注意的是, 忽视防止字段注入并不会 "安全失败", 因为即使恶意行为成为可能, 名义上的功能仍会按预期工作. 因此, 建议格外谨慎, 确保已进行适当的字段清理.

TTRP 与后端服务器之间的通信需要受到保护, 以防非预期方窃听和修改.

配置选项和请求清理是相应服务器的必要功能. 其他要求可以通过多种方式满足, 具体方式会因部署而异. 例如, TTRP 与后端或源服务器之间的通信可以通过某种方式进行认证, 并且 Client-Cert 和 Client-Cert-Chain 头字段的插入与消费只发生在该连接上. [HTTPSIG] 附录 B.3 给出了一个使用 HTTP Message Signatures 的示例. 或者, 网络拓扑可能规定使用私有网络, 使后端应用只能接受来自 TTRP 的请求, 且代理只能向该服务器发出请求. 也可以采用其他满足本文所列要求的部署方式.