我知道对于 MTLS ,双方、客户端和服务器交换证书。这些证书应由双方都可以信任的 CA 签名,以验证证书。
我的问题是,MTLS 是否还意味着除了验证证书(如果 CA 是可信的,叶子证书是可信的),任何一方(服务器或客户端)还可以做一些额外的检查,比如主机名检查或客户端是否连接到服务器是否在批准的受信任实体列表中?
谁能指出 mTLS 规范以及 mTLS 的开销是什么?
我知道对于 MTLS ,双方、客户端和服务器交换证书。这些证书应由双方都可以信任的 CA 签名,以验证证书。
我的问题是,MTLS 是否还意味着除了验证证书(如果 CA 是可信的,叶子证书是可信的),任何一方(服务器或客户端)还可以做一些额外的检查,比如主机名检查或客户端是否连接到服务器是否在批准的受信任实体列表中?
谁能指出 mTLS 规范以及 mTLS 的开销是什么?
除了 EJP 所说的“MTLS”术语外,TLS 1.2 规范对检查哪些信息以及检查方式没有严格要求。
由接收方决定所提供的证书是否可信。这意味着,例如,服务器可以只接受属于拥有服务器的公司的 CA 颁发的证书。这就是客户银行访问系统通常的工作方式——它们只接受银行颁发的证书,并且此类证书的通用名称必须与 Web 表单中提供的用户名相对应。
双方都可以自由检查证书中的任何信息,包括直接比较公钥哈希(因此,无论其他证书属性中包含什么,只有特定的密钥对才能工作)。
关于这个主题的最新 RFC 是:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ 这是 OAuth 2.0 的扩展
本文档的目的是定义一种机制,如何在替换客户端 ID 和机密(又名客户端凭据)的上下文中使用 TLS 证书
该标准建立了两种机制,如何将 TLS 证书用作客户端凭据,以及相关的令牌流和属性。
对此的一般总结是:
(a) 授权服务器:根据 PKI(由有效根签名)检查证书 RFC 没有定义选项,但它们非常不言自明并且取决于用例。但它可以是(1)证书由受信任的根签名并且未被撤销,(2)基于某种逻辑单独识别每个证书。
(b) 资源服务器检查令牌和客户端证书(客户端凭据,或 CC),并在底层 TLS 会话中使用。请注意,在 TLS 层没有关于证书或其来源的验证检查,所有检查都在应用程序层执行。因此,资源服务器应配置 TLS 堆栈,使其不验证客户端在握手期间提供的证书是否由受信任的 CA 证书签名。
这种机制在某些 GDPR 上下文中变得特别有趣,因为它使客户端和服务器之间无法共享令牌。
总体而言,这是一个很好的隐私功能,并提高了安全性。
mTLS 可以通过向所有各方颁发 CA 证书并将其添加到所有通信方来实现,这是一种访问控制列表。在您的应用程序的信任存储中拥有 CA 证书的任何人都可以连接。
但是,在 https 连接的情况下,信任系统与 TLS 相同 - 您可以从同一个 CA 颁发多个证书,并将根 CA 证书添加到应用程序的信任库中。它将信任从同一根颁发的所有证书。这可以说更容易设置,因为您只需添加应用程序自己的证书和 CA 根。但是,如果你想撤销证书,它会变得有点复杂。
我在这里写了一个生成证书的指南:
没有“MTLS 规范”,这是因为没有“MTLS”之类的东西。你只是弥补了。包括相互认证在内的TLS规范可以在RFC 2246中找到。
TLS API 应该使对等证书链对应用程序可用,因此它可以进行任何它喜欢的额外检查。
'MTLS',就其存在而言,指的是用于多路复用TLS 的 Internet 草案。