MTLS(相互TLS)详细信息

use*_*917 2 ssl

我有一个关于相互TLS(MTLS)的问题

我知道,对于MTLS,双方,客户端和服务器交换证书.这些证书应由双方可信任的CA签署,以验证证书.

我的问题是,MTLS还意味着除了验证证书(如果CA是可信的,叶证书是可信的),任何一方(服务器或客户端)也可以执行一些额外的检查,如主机名检查或客户端是否连接到服务器是否在已批准的可信实体列表中?

任何人都可以向我指出MTLS规范以及MTLS的主要内容是什么?

谢谢!

Eug*_*its 8

除了EJP所说的"MTLS"术语之外,TLS 1.2规范对要检查哪些信息以及以何种方式没有严格的要求.

由接收方决定是否信任所呈现的证书.这意味着,例如,服务器可以仅接受属于拥有服务器的公司的CA颁发的证书.这就是客户银行访问系统经常工作的方式 - 它们只接受银行颁发的证书,此类证书的通用名称必须与Web表单中提供的用户名相对应.

双方都可以自由检查证书中的任何信息,包括公钥哈希的直接比较(因此,无论其他证书属性中包含什么,只有特定的密钥对才有效).


小智 8

关于此主题的最新 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 层没有关于证书或其来源的验证检查,所有检查都在应用层执行。因此,资源服务器应以不验证客户端在握手期间提供的证书是否由受信任的 CA 证书签名的方式配置 TLS 堆栈。

这种机制在某些 GDPR 上下文中变得特别有趣,因为它不可能在客户端和服务器之间共享令牌。

总的来说,这是一个很好的隐私功能,并提高了安全性。


use*_*421 -6

没有“MTLS 规范”,因为没有“MTLS”这样的东西。你刚刚弥补了。TLS规范(包括相互身份验证)可在修订后的RFC 2246中找到。

TLS API 应该使对等证书链可供应用程序使用,以便应用程序可以执行任何额外的检查。

就其存在而言,“MTLS”指的是多路传输层安全(TLS) 的互联网草案。