双向 TLS（mTLS）实现模式

标准 TLS 仅通过证书向客户端验证服务器身份。双向 TLS（mTLS）对此进行了扩展：双方都出示并验证证书。服务器通过 CertificateRequest 在 TLS 握手中请求客户端证书，客户端随后出示该证书。服务器会根据受信任的 CA 验证客户端证书。mTLS 是零信任网络的基础：服务不再依赖网络边界安全，而是在每次连接中通过密码学方式相互验证身份。Istio、Linkerd 和 Consul Connect 等服务网格会在微服务之间透明地实现 mTLS。

mTLS 握手按以下方式扩展 TLS 1.3：在 ServerHello 以及服务器证书和 Finished 之后，服务器发送 CertificateRequest 消息，指定可接受的证书颁发机构和签名算法。客户端使用其 Certificate（客户端证书链）和 CertificateVerify（使用客户端私钥对转录内容生成的签名）进行响应。服务器根据其受信任的 CA 存储区验证客户端证书链，并验证 CertificateVerify 签名。如果两项验证都通过，连接双方就完成了相互身份验证。没有与该证书对应的私钥，客户端就无法伪造 CertificateVerify。

在服务网格环境中，客户端证书通常由内部 CA 签发。Istio 使用 SPIFFE（面向所有人的安全生产身份框架）身份凭证：每个工作负载都会获得一张证书，其中包含 SPIFFE URI SAN（主题备用名称），例如 spiffe://cluster.local/ns/default/sa/payment-service。这些证书的生命周期很短（24 小时），并由网格控制平面（istiod）自动轮换。在面向用户的 mTLS 场景中（例如企业 VPN、API 客户端），证书可能由企业 CA 签发，具有更长的生命周期，并通过 MDM（移动设备管理）下发到员工设备。

服务器端 mTLS 验证包括多个步骤：(1) 链验证——验证客户端证书是否链至服务器客户端 CA 存储区中的受信任根 CA；(2) 有效期检查——确保该证书既未过期，也已到生效时间；(3) 撤销检查——通过 OCSP 或 CRL 验证证书尚未被撤销；(4) SAN/CN 匹配——从证书 SAN 中提取身份声明（SPIFFE URI、DNS 名称或电子邮件地址）；(5) 授权——检查经过身份验证的身份是否有权访问请求的资源。第 4 步和第 5 步需要应用层逻辑，超出基本 TLS 配置的范围。

短生命周期证书不需要显式撤销：如果证书在 24 小时后过期，泄露造成的影响窗口就会受到限制。轮换需要包括：(1) 预轮换——在旧证书过期前签发新证书（在生命周期达到 80% 时进行轮换）；(2) 零停机切换——服务必须在过渡窗口内同时接受新旧证书；(3) 平滑重载——TLS 协议栈必须在不终止现有连接的情况下重新加载凭据（nginx：nginx -s reload；Envoy：动态 xDS 证书更新）。SPIFFE 工作负载 API（由 SPIRE 实现）通过 Unix 域套接字 API 自动完成证书下发和轮换。

Istio 通过向每个 Pod 注入 Envoy 边车代理，以透明方式实现 mTLS。控制平面（istiod）使用由网格根 CA 签署的中间证书，充当 CA。每个 Pod 的边车代理都通过 SDS（秘密发现服务）API 接收 SPIFFE SVID。PeerAuthentication 策略配置 mTLS 模式：STRICT（必须使用 mTLS）、PERMISSIVE（同时接受 mTLS 和明文，用于迁移）或 DISABLE。AuthorizationPolicy 资源定义允许哪些服务通信，并根据客户端证书中的 SPIFFE 身份进行检查。这样无需修改应用程序代码，就能在集群内部实现零信任。

对于外部 API 客户端，mTLS 比 API 密钥或 OAuth 令牌提供更强的身份验证。客户端将私钥存放在安全存储中（HSM、操作系统密钥库或带密码短语的软件密钥）。客户端证书固定为 API 端点所信任的 CA。每个 API 请求都在 TLS 层完成身份验证，无需单独的授权请求头。Cloudflare 的 API Shield、AWS API Gateway 客户端证书以及 Google Cloud 的服务账户 mTLS 都实现了这一模型。被盗用的 API 密钥可以从任何地方使用；而被盗用的 mTLS 私钥还要求攻击者窃取运行客户端的设备。

部署 mTLS 会面临若干运营挑战。(1) 证书分发——安全地向所有服务交付客户端证书，尤其是在 Pod 动态扩缩的环境中。(2) CA 泄露——内部 CA 是高价值目标；一旦遭到破坏，所有服务证书都会失效。由 HSM 保护的 CA 和离线根 CA 可以降低这一风险。(3) 调试——加密的 mTLS 流量对标准调试工具不可见；因此需要使用服务网格可观测性工具（Jaeger、Kiali）。(4) 中间盒兼容性——TLS 检查代理会破坏 mTLS，除非明确配置为透传客户端证书。(5) 证书过期事故——轮换失败可能导致整个服务中断。

SPIFFE（面向所有人的安全生产环境身份框架）使用 X.509 SVID 定义了一种工作负载身份标准。SPIRE（SPIFFE 运行时环境）是其参考实现。SPIRE Server 充当注册机构和 CA。SPIRE Agents 运行在每个节点上，通过节点证明器（AWS 实例身份、Kubernetes 服务账户 JWT、TPM）和工作负载证明器（Unix PID、容器运行时元数据）证明工作负载身份。Workload API 通过 Unix 域套接字，使用简单的 gRPC API 向工作负载交付 SVID。SPIRE 可与 Envoy、Nginx 以及主要服务网格集成，作为证书来源。

对于高安全性的 mTLS 部署，私钥应存放在硬件安全模块（HSM）中，而不是软件密钥库中。TLS 库（OpenSSL、BoringSSL）通过 PKCS#11 接口加载私钥，该接口会将签名操作转发到 HSM。私钥永远不会以明文形式离开 HSM 边界。云 HSM 选项包括 AWS CloudHSM、Azure Dedicated HSM 和 Google Cloud HSM。对于设备级 mTLS（物联网、企业笔记本电脑），TPM 2.0 提供类似功能：TLS 客户端密钥绑定到 TPM，签名操作需要 TPM 授权，因此从遭到破坏的设备中提取密钥会极其困难。

测试 mTLS 需要支持提供客户端证书的工具。OpenSSL s_client：openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem。curl：curl --cert client.pem --key client.key --cacert server-ca.pem https://host。测试服务网格时，istioctl proxy-config secret pod/name 会显示当前证书及其过期时间。执行 kubectl exec 进入 Pod，然后使用 curl 访问边车管理端点（localhost:15000），即可检查活动监听器及其 mTLS 配置。自动化轮换测试应验证连接在证书轮换事件期间是否保持稳定。

与标准 TLS 相比，mTLS 增加了哪一步？

mTLS 在 TLS 中加入了客户端证书身份验证，双方都会验证对方的证书。SPIFFE SVID 通过证书 SAN 中的 SPIFFE URI 提供标准化的工作负载身份。Istio 通过 Envoy 边车透明地实现 mTLS，并支持 STRICT/PERMISSIVE 模式。短期证书（24h）无需进行吊销管理，并能缩短密钥泄露后的风险窗口。SPIRE 通过 Workload API 自动完成证书签发和轮换。对于高安全性部署，mTLS 私钥应存放在 HSM 或 TPM 中。运营挑战包括保护 CA 密钥、确保中间盒兼容性以及实现零停机轮换。