介绍应用程序负载均衡器的mTLS

AWS最近宣布支持对呈现X509证书的客户端进行互相认证的应用程序负载均衡器 (ALB)。在本文中，我们将讨论实现此新功能的选项以及实现过程中需要考虑的事项。

ALB在应用层（OSI模型中的第7层）运行，并将传入的HTTP/HTTPS请求负载均衡到后端目标。它通常用于创建可扩展和安全的Web应用程序，并支持高级路由规则，允许您基于应用程序属性（如主机名、完整路径或基于HTTP头条件的路由）进行负载均衡。有关更多详细信息，请查看应用程序负载均衡器文档。

从安全角度看，ALB允许您创建HTTPS监听器。使用HTTPS监听器，ALB将终止客户端的TLS会话。ALB还与AWS WAF 原生集成，允许您为Web应用程序创建规则并保护在ALB后运行的应用程序。

mTLS概念

相互传输层安全（mTLS）扩展了用于保护网络通信的TLS协议。TLS通常用于在互联网上建立安全连接，确保身份验证、数据保密性和完整性。然而，在传统的TLS中，身份验证是单向的，即服务器向客户端验证自己，而客户端的身份未被验证。

相比之下，mTLS通过要求服务器和客户端互相验证来增加一层额外的安全性，因此称为“相互”或“双向”TLS。与mTLS相关的一些概念包括：

• 证书颁发机构（CA）： 向企业提供TLS证书的组织/实体。CA在颁发TLS证书之前验证域名和所有者详细信息。
• TLS证书： 允许系统（如Web客户端）验证另一系统（如Web服务器）身份的数字对象。TLS证书中的详细信息允许客户端与服务器建立加密连接。
• 服务器证书： 证明服务器身份的TLS证书。
• 客户端证书： 证明客户端身份的TLS证书。
• 证书信任链： TLS证书的有序列表。链始于左证书（或客户端/服务器的TLS证书），以根证书结束。叶子和根证书之间的任何证书称为中间证书。链中的每个证书均由下一个证书标识的组织/实体签名。见图1。

图1：证书信任链

• TLS握手： 允许客户端和服务器使用其TLS证书相互验证、协商加密标准并创建安全通道以传输数据的过程。有关更多详细信息，请参考TLS文档。客户端在TLS握手期间与服务器共享其TLS证书。这使得服务器能够验证客户端。
• 证书吊销列表（CRL）： 列出了不应被信任的被列入禁止名单的证书。

mTLS过程通常用于保护智能设备、API、微服务之间的通信，以及在双方必须建立彼此身份信任的任何情况下，如满足监管要求。它也用于虚拟专用网络（VPN）和组织内部通信的安全。

为了实现mTLS，服务器和客户端都必须拥有由受信任CA颁发的数字证书。这些证书可以由相同或不同的CA生成，并用于在握手过程中证明每一方的真实性。

在应用程序负载均衡器中使用mTLS客户端认证

当客户端的证书链在一定深度和大小范围内时，应用程序负载均衡器支持mTLS。请查看应用程序负载均衡器的配额文档，了解当前支持的最大尺寸和深度。您可以分别使用Application Load Balancer的_ClientCertExceedsDepthLimit_和_ClientCertExceedsSizeLimit_ Amazon CloudWatch指标来跟踪任何超出这些限制的请求。

应用程序负载均衡器支持两种mTLS操作模式：mTLS验证模式和mTLS透传模式。

mTLS验证模式

要在应用程序负载均衡器中使用mTLS验证模式，您必须创建一个信任存储。信任存储包含一个CA证书包，用于验证客户端证书。您可以自带证书或使用AWS Certificate Manager (ACM)生成证书。您可以使用AWS管理的CA在应用程序负载均衡器中进行mTLS验证模式。AWS Private Certificate Authority是一种高可用的托管CA服务，帮助组织使用私有证书保护应用程序和设备。有关颁发和管理证书的更多信息，请参考ACM文档。

要指定不受信任的客户端证书，您需要将一个或多个证书吊销列表（CRL）与信任存储关联。将吊销列表上传到S3存储桶，并在信任存储中指定该存储桶。ALB从S3导入CRL，ALB在进行CRL检查时不会每次都从S3获取CRL。因此，ALB在对客户端进行CRL验证时不会增加任何延迟。有关CRL配置的更多详细信息，请查看在应用程序负载均衡器中使用TLS的相互认证页面。

在此模式下，应用程序负载均衡器将使用信任存储验证客户端证书。这确保只有通过有效证书验证的客户端才能与后端目标通信。ALB会阻止未经验证的用户请求。这允许您将mTLS认证所需的计算密集型处理卸载到应用程序负载均衡器，并使用后端目标的处理资源来交付您的应用程序服务。图2显示了验证模式的架构。

图2：配置为mTLS验证模式的应用程序负载均衡器

ALB验证模式下的mTLS阶段如下：

[1] 将CA证书包上传到Amazon S3，并可选上传CRL。

[2] 创建信任存储，并提供CA证书包的Amazon S3路径。可选提供CRL的Amazon S3路径。

[3] 客户端发起与ALB的TLS会话。在TLS握手期间，客户端呈现其TLS证书。

[4] TLS会话在ALB终止。在TLS握手期间，ALB呈现服务器端证书并接收客户端证书。

[5] ALB查阅信任存储并验证证书。如果客户端证书未由受信任的CA签署，证书在CRL中列出或客户端证书已过期，则客户端认证将失败。有关客户端认证可能在应用程序负载均衡器的mTLS验证模式下失败的完整场景列表，请参考在应用程序负载均衡器中使用TLS的相互认证页面。如果客户端认证失败，应用程序负载均衡器将拒绝TLS连接。对于过期证书，您可以选择配置ALB以允许此类连接。

[6] TLS会话在客户端和ALB之间成功建立。

[7] ALB创建与后端目标的单独会话。

由于应用程序负载均衡器终止了TLS会话，您可以使用任何ALB的路由算法将流量负载均衡到后端目标。例如，您可以使用加权轮询规则创建Web应用程序的蓝/绿部署。

除了执行客户端认证，应用程序负载均衡器还将以下证书元数据发送到后端目标：

X-Amzn-Mtls-Clientcert-Serial-Number – 客户端证书的十六进制表示，例如，0ABC1234
X-Amzn-Mtls-Clientcert-Issuer – 发行者识别名（DN），使用X509_NAME_print_ex和XN_FLAG_RFC2253标志打印
X-Amzn-Mtls-Clientcert-Subject – 使用X509_NAME_print_ex和XN_FLAG_RFC2253标志打印的主题DN
X-Amzn-Mtls-Clientcert-Validity – ISO8601格式的notBefore和notAfter日期，例如，NotBefore=2023-09-21T01:50:17Z; NotAfter=2024-09-20T01:50:17Z
X-Amzn-Mtls-Clientcert-Leaf – URL编码的PEM格式的客户端证书

这些信息允许您在后端目标上基于这些元数据字段实现逻辑。例如，您可以解析X-Amzn-Mtls-Clientcert-Leaf字段以获取证书的过期日期，并在证书即将到期时向客户端发送自定义消息。

mTLS透传模式

在此模式下，ALB通过名为AMZN-MTLS-CLIENT-CERT的HTTP标头将整个证书链转发给后端目标以进行客户端认证。ALB插入整个证书链，包括客户端证书，以URL编码的PEM格式，其中+、=和/作为安全字符。以下是AMZN-MTLS-CLIENT-CERT标头的示例：

X-Amzn-Mtls-Clientcert: 

-----BEGIN%20CERTIFICATE-----%0AMIID&lt;...reduced<br />...&gt;do0g%3D%3D%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICAT<br />E-----%0AMIID1&lt;...reduced...&gt;3eZlyKA%3D%3D%0A-----END%20CERTIFICATE---<br />--%0A

后端目标必须能够解析此HTTP标头，提取证书并执行客户端认证。如果您希望保留客户端认证过程的控制权，请使用此模式。图3显示了此架构。

图3：配置为mTLS透传模式的应用程序负载均衡器

ALB透传模式下的mTLS阶段如下：

[1] 客户端发起与ALB的TLS会话。在TLS握手期间，客户端呈现其TLS证书。

[2] TLS会话在ALB终止。在TLS握手期间，ALB呈现服务器端证书并接收客户端证书。

[3] ALB与后端目标创建新会话。该会话可以是HTTP或HTTPS，具体取决于用户配置。ALB在名为AMZN-MTLS-CLIENT-CERT的HTTP标头中包含整个证书链。

[4] 后端目标接收客户端证书，并必须实现解析AMZN-MTLS-CLIENT-CERT HTTP标头中的客户端证书链的逻辑。目标还必须实现客户端认证的逻辑。

如果启用了mTLS透传模式时没有客户端证书存在，应用程序负载均衡器将不会添加任何额外的HTTP标头。后端目标必须实现处理不带客户端证书的传入请求的逻辑。

如果后端目标上的客户端认证失败，目标必须处理发送HTTP错误代码回到应用程序负载均衡器。ALB将此错误代码中继回客户端。

对于HTTPS监听器，后端目标基于证书进行客户端认证，应用程序负载均衡器终止客户端与后端目标之间的TLS连接，并打开与后端目标的新TLS会话。ALB与后端目标之间的TLS会话是使用安装在目标上的证书创建的。

由于ALB终止了TLS会话，您可以使用任何ALB的路由算法将流量负载均衡到后端目标。

一些智能设备可能会离线一段时间，例如临时失去互联网连接的智能汽车。在这些情况下，您需要确保后端目标实现处理过期TLS证书的逻辑。

实现基于应用程序的Cookie是另一种实现透传模式的用例。在此用例中，后端目标为认证的客户端颁发Cookie，客户端可以使用这些Cookie进行通信。这确保了后端目标不需要为每个传入请求处理整个证书链。您可以使用开源库在后端目标上实现Cookie，并实现基于Cookie跟踪客户端认证状态的逻辑。

监控

应用程序负载均衡器为所有发送到负载均衡器的请求提供连接日志。这些日志发送到Amazon Simple Storage Service (Amazon S3)存储桶，并包含客户端的IP地址、TLS密码的详细信息以及请求被拒绝时的错误代码。有关详细信息，请参考应用程序负载均衡器的连接日志。

有关应用程序负载均衡器的mTLS支持的完整CloudWatch指标列表，请参阅应用程序负载均衡器的CloudWatch指标。

比较ALB的mTLS模式与网络负载均衡器（NLB）

如果您有HTTPS应用程序，我们建议您考虑使用ALB以执行应用程序级别的路由。例如，对HTTPS请求执行加权轮询负载均衡，这将允许您创建蓝/绿部署。ALB还允许您卸载TLS/mTLS操作。由于ALB终止了客户端的TLS会话，您需要为ALB上传证书。

另一方面，NLB在传输层（OSI模型的第4层）操作，并提供低延迟的TCP/UDP连接负载均衡。对于HTTPS应用程序，如果您有特定的安全合规规则需要服务器终止客户端的TLS连接，我们建议使用网络负载均衡器（NLB）。

下表比较了应用程序负载均衡器的透传模式和验证模式与网络负载均衡器的支持，并列出了每个选项的考虑因素。

	ALB + mTLS验证模式	ALB + mTLS透传模式	NLB
客户端认证	由ALB完成，由AWS管理	由后端目标完成，由客户管理	由后端目标完成，由客户管理
客户端的SSL/TLS会话终止	在ALB，由AWS管理	在ALB，由AWS管理	在后端目标，由客户管理
路由规则能力	ALB的应用程序级别路由规则	ALB的应用程序级别路由规则	NLB的基于端口和协议的路由规则

结论

在本文中，我们讨论了应用程序负载均衡器的mTLS验证模式和透传模式，以及使用每种模式时需要考虑的事项。您在应用程序负载均衡器上使用mTLS验证模式以进行客户端认证。当您希望在后端目标上保持客户端认证控制时，mTLS透传模式最适合。使用信任存储和启用mTLS时存在额外费用。有关详细信息，请访问弹性负载均衡定价页面。

此功能现已可用，请尝试并联系AWS支持告诉我们您是否有任何问题或建议。

本文翻译自：Introducing mTLS for Application Load Balancer