思科邮件安全的TLS验证流程

简介

本文档介绍 思科邮件安全设备(ESA)的传输层安全(TLS)服务器身份验证流程

思科邮件安全的TLS验证流程

TLS验证过程基本上是一个两阶段的验证过程：

I -证书验证

这涉及验证：

• 证书有效期-证书有效期
• 证书链颁发者
• 吊销列表等

II -服务器身份验证

这是根据服务器参考身份对服务器提供的身份（包含在X.509公钥证书中）的验证过程。

背景

让我们继续使用RFC 6125中介绍的身份名称术语。  

注意：提供的标识是由服务器X.509公钥证书提供的标识符，该标识符可以包含多个不同类型的提供的标识符。对于SMTP服务，它包含为dNSName类型的subjectAltName扩展名或派生自subject字段的CN（公用名称）。

注意：参考身份是从客户端期望应用服务出现在证书中的完全限定DNS域名构建的标识符。

验证过程对于TLS客户端来说最为重要，因为通常客户端会发起TLS会话，而客户端需要对通信进行身份验证。为此，客户端需要验证提供的身份是否与参考身份匹配。重点在于了解TLS验证过程的安全性几乎完全基于TLS客户端。

第一步

服务器身份验证的第一步是通过TLS客户端确定参考身份。这取决于应用中TLS客户端认为可接受的引用标识符列表。此外，还必须构建一个可接受的引用标识符列表，该列表与服务提供的标识符无关。[rfs6125#6.2.1]

参考标识必须是完全限定的DNS域名，并且可以从任何输入进行解析（客户端可以接受该域名并且认为它是安全的）。  参考标识必须是客户端尝试连接的DNS主机名。 

收件人邮件域名是参考标识，由用户通过有意向特定域中的特定用户发送邮件直接表示，这也符合作为用户尝试连接的FQDN的要求。仅在自托管SMTP服务器的情况下（SMTP服务器由同一所有者拥有和管理，并且服务器未托管过多的域），此规则是一致的。因为每个域都需要列在证书中（作为subjectAltName： dNSName值之一）。从实施角度来看，大多数证书颁发机构(CA)将域名值的数量限制为低至25个条目（高至100个）。这在托管环境中不被接受，让我们考虑一下邮件服务提供商(ESP)，其中目标SMTP服务器托管成千上万个域。这根本无法扩展。

显式配置的参考标识似乎是答案，但这会施加一些限制，因为对于每个目标域，都必须手动将参考标识与源域相关联，或者“从第三方域映射服务获取数据，在该服务中用户已显式地放置信任，并且客户端通过连接或关联与其通信，该连接或关联提供相互身份验证和完整性检查”。[RFC6125#6.2.1]

从概念上讲，在配置时，这可以视为一次性“安全MX查询”，其结果永久缓存在MTA上，以在运行状态下防止任何DNS危害。[2]

这只能通过“合作伙伴”域进行更强大的身份验证，但对于尚未映射的通用域，这无法通过考试，也无法避免目标域端发生配置更改（例如主机名或IP地址更改）。

第二步

该过程的下一步是确定提供的身份。提供的身份由服务器X.509公钥证书提供，作为dNSName类型的subjectAltName扩展或在主题字段中找到的公用名(CN)。其中，subject字段完全可以为空，只要证书包含至少包含一个subjectAltName条目的subjectAltName扩展名。

尽管实际上仍在使用Common Name，但认为已弃用，当前建议使用subjectAltName条目。支持来自公用名的身份是为了向后兼容。在这种情况下，应首先使用subjectAltName的dNSName，并且仅当它为空时，才会选中Common Name。

注意：公用名键入不严格，因为公用名可能包含服务的人性友好字符串，而不是格式与完全限定的DNS域名匹配的字符串

最后，当确定了两种身份类型时，TLS客户端需要将其每个参考标识符与提供的标识符进行比较，以便找到匹配。

ESA TLS验证

ESA允许在传输至特定域时启用TLS和证书验证(使用Destination Controls页面或destconfig CLI命令)。如果需要TLS证书验证，自AsyncOS版本8.0.2以来，您可以选择两个验证选项之一。预期的验证结果可能因配置的选项而异。在目标控制下可用的6个不同的TLS设置中，有两个重要设置负责证书验证：

1. 需要TLS -验证
2. 需要TLS -验证托管域。

CLI: destconfig 

Do you want to use TLS support?

1. No

2. Preferred

3. Required

4. Preferred - Verify

5. Required - Verify

6. Required - Verify Hosted Domains 

[6]> 

选项(4) Preferred - Verify的TLS验证过程与(5) Required - Verify相同，但根据结果采取的操作有所不同，如下表所示。选项(6)必需-验证托管域的结果与(5)必需-验证的结果大不相同。 

TLS设置	含义
4. 首选（验证）	TLS从邮件安全设备协商到域的MTA。设备会尝试验证域证书。 有三种可能的结果： 将协商TLS并验证证书。邮件通过加密会话传送。 TLS是协商的，但证书未验证。邮件通过加密会话传送。 未建立TLS连接，因此未验证证书。电邮以纯文本发送。
5. 必填（验证）	TLS从邮件安全设备协商到域的MTA。需要验证域证书。 有三种可能的结果： 将协商TLS连接并验证证书。电邮通过加密会话传送。 将协商TLS连接，但证书未经受信任CA验证。邮件未送达。 TLS连接未协商。邮件未送达。

需要TLS -验证与需要TLS -验证托管域选项之间的区别存在于身份验证过程中。处理呈现标识的方式以及允许使用哪种类型的引用标识符对最终结果有影响。以下描述以及整个文档的用途是使此流程更接近最终用户。由于不正确或不清楚的了解本主题可能会对用户网络造成安全影响。

需要TLS验证

提供的身份首先从subjectAltName - dNSName扩展名派生，如果没有匹配或subjectAltName扩展名不存在，则选中CN-ID - Common Name from subject字段。

参考身份(REF-ID)列表由收件人域或收件人域构建，并且主机名派生自针对客户端所连接的IP地址运行的PTR DNS查询。  注意：在该特定情况下，不同参考标识与提供的不同标识检查进行比较。

~=表示精确匹配或通配符匹配

将提供的身份（dNSName或CN-ID）与接受的参考身份进行比较，直到其匹配且按下列顺序排列。 

• 如果subjectAltName的dNSName扩展存在：
  • 仅针对收件人域执行完全匹配或通配符匹配
    
    在subjectAltName匹配的情况下引用标识仅从收件人域派生。如果收件人域不匹配任何dNSName条目，则不检查进一步的参考标识（例如从DNS解析MX或PTR派生的主机名）

• 如果主题DN的CN存在(CN-ID)：
  • 对收件人域执行完全匹配或通配符匹配
  • 根据从对目标服务器的IP执行的PTR查询派生的主机名执行完全匹配或通配符匹配
    
    其中，PTR记录保留了转发器和解析器之间的DNS一致性。此处需要提及的是，仅当存在PTR记录且为此主机名（参考标识）的已解析A记录（转发器）返回的IP地址与执行PTR查询所依据的目标服务器IP匹配时，才会将CN字段与来自PTR的主机名进行比较。
    
    A(PTR(IP)) == IP
    
    如果CN-ID是从收件人域派生的，并且不存在匹配项，则会对目标IP的PTR记录执行DNS查询以获取主机名。如果PTR存在，则会对从PTR派生的主机名上的A记录执行额外查询，以确认DNS一致性得到保留！不检查其他引用（例如从MX查询派生的主机名）

综上所述，使用“TLS Required - Verify”选项时，与dNSName或CN相比，没有MX主机名，仅检查CN的DNS PTR RR，并且仅在保留DNS一致性时匹配A(PTR(IP)) = IP，对dNSName和CN执行精确和通配符测试。

需要TLS验证-托管域

提供的标识首先从dNSName类型的subjectAltName扩展派生。如果dNSName与接受的一个引用标识(REF-ID)之间没有匹配，则验证失败，无论主题字段中是否存在CN，并且可以通过进一步的标识验证。仅当证书不包含任何dNSName类型的subjectAltName扩展名时，才会验证从subject字段派生的CN。

回想一下，提供的身份（dNSName或CN-ID）会与接受的参考身份进行比较，直到该身份匹配且按下列顺序排列。 

• 如果subjectAltName的dNSName扩展存在：
  
  如果dNSName与下面列出的一个接受的引用标识无匹配，则身份验证失败
   
  • 针对收件人域执行完全匹配或通配符匹配：一个dNSName必须与收件人域匹配
  • 使用SMTPROUTES (*)对明确配置的主机名执行完全匹配或通配符匹配
  • 根据（不安全）的DNS查询得出的MX主机名，对收件人域名执行精确或通配符匹配
    
    如果收件人域没有使用FQDN条目显式配置SMTP路由且收件人域不匹配，则会使用针对收件人域的（不安全）DNS查询中的MX记录返回的FQDN。如果没有匹配项，则不执行进一步测试，不检查任何PTR记录 
• 如果主题DN的CN存在(CN-ID)：

  
  仅当证书中不存在dNSName时，才会验证CN。将CN-ID与以下接受的引用标识列表进行比较。
  
  

  • 对收件人域执行完全匹配或通配符匹配
  • 对SMTPROUTES (*)中明确配置的主机名执行完全匹配或通配符匹配
  • 根据（不安全）的DNS查询得出的MX主机名，对收件人域名执行精确或通配符匹配

显式配置的SMTPROUTES

当配置了SMTP路由且显示的身份与邮件收件人域不匹配时，会比较所有FQDN路由名称，如果不匹配，则不会进行进一步检查。使用显式配置的SMTP路由时，不会将MX主机名与提供的身份进行比较。此处的例外情况是创建设置为IP地址的SMTP路由。

以下规则适用于显式配置的SMTP路由：

• 当收件人域存在SMTP路由且它是完全限定DNS域名(FQDN)时，它被视为参考标识。将此主机名（路由名称）与从证书收到的呈现身份进行比较，该证书是从该主机名指向的目标服务器派生的。

• 允许一个收件人域使用多个路由。如果收件人域有多个SMTP路由，则会处理这些路由，直到来自目标服务器的证书提供的标识符与建立连接的路由的名称相匹配。如果列表上的主机具有不同的优先级，则首先处理优先级最高（0为最高优先级，默认值为默认值）的主机。如果所有路由的优先级相同，则按用户设置路由的顺序处理路由列表。

• 如果主机不响应（不可用）或者响应，但TLS验证失败，则处理列表中的下一个主机。当第一台主机可用并通过验证时，其他主机则不会使用。

• 如果多条路由解析为相同的IP地址，则仅与此IP建立一条连接，且从目标服务器发送的证书派生的呈现身份必须与其中一个路由名称匹配。

• 如果收件人域存在SMTP路由，但已配置为IP地址，则路由仍用于建立连接，但来自证书的提供的身份会与收件人域进行比较，并进一步与DNS/MX资源记录派生的主机名进行比较。

当我们讨论托管域的TLS必需验证选项时，ESA与目标服务器的连接方式对于TLS验证过程非常重要，因为显式配置的SMTP路由提供在此过程中要考虑的额外参考标识。

~=表示精确匹配或通配符匹配

示例

让我们从现实生活中举一个例子，但是对于收件人域：example.com。下面我尝试描述手动验证服务器身份所需的所有步骤。 

example.com -> IN MX mx01.subd.emailhosted.not.
example.com -> IN MX mx02.subd.emailhosted.not.

mx01.subd.emailhosted.not. -> IN A 192.0.2.1
mx02.subd.emailhosted.not. -> IN A 192.0.2.2

192.0.2.1 -> IN PTR mx0a.emailhosted.not.
192.0.2.2 -> IN PTR mx0b.emailhosted.not.

mx0a.emailhosted.not. -> IN A 192.0.2.1
mx0b.emailhosted.not. -> IN A 192.0.2.2

注意：在这种情况下，MX主机名和revDNS名称不匹配

$ echo QUIT |openssl s_client -connect mx0a.emailhosted.not:25 -starttls smtp 2>/dev/null| openssl x509 -text | grep -iEo 'DNS:.*|CN=.*'

CN=thawte SHA256 SSL CA
CN=*.emailhosted.not
DNS:*.emailhosted.not, DNS:emailhosted.not 

echo QUIT |openssl s_client -connect mx0b.emailhosted.not:25 -starttls smtp 2>/dev/null| openssl x509 -text | grep -iEo 'DNS:.*|CN=.*'

CN=thawte SHA256 SSL CA
CN=*.emailhosted.not
DNS:*.emailhosted.not, DNS:emailhosted.not   

•   提供的标识：dNSName exist（继续与允许的参考标识进行比较）
  
  
  • 参考标识=收件人域(example.com)已勾选，并且与dNSName DNS：*.emailhosted.not、DNS：emailhosted.not不匹配
•   呈现的标识：CN存在（继续使用与上一个标识相同的下一个呈现的标识，没有匹配）
  
  
  • 引用标识=收件人域(example.com)已勾选，并且与CN *.emailhosted.not不匹配
    
    
  • 参考身份= PTR(IP)：对TLS客户端(ESA)已建立连接并收到证书的服务器的IP执行PTR查询，并且此查询返回： mx0a.emailhosted.not.
    
    
    • 检查DNS一致性，以将此主机名视为有效的参考标识：
      
      
      存在一致性：A(PTR(IP)) = IP
      
      

      mx01.subd.emailhosted.not. -> IN A 192.0.2.1
      
      PTR(IP):      192.0.2.1  -> IN PTR  mx0a.emailhosted.not.
      A(PTR(IP)):   mx0a.emailhosted.not. -> IN A 192.0.2.1
      

    • mx0a.emailhosted.not.的值将与CN*.emailhosted.not进行比较，两者就匹配。

PTR域名验证身份，由于证书是CA签名的证书，它验证整个证书并建立TLS会话。

• 提供的标识：dNSName存在（在这种情况下，将不处理CN）
  • 已检查参考身份=收件人域(example.com)，并且
    与dNSName DNS：*.emailhosted.not、DNS：emailhosted.not不匹配
  • 参考身份= FQDN(smtp route) -此收件人域没有smtproutes 
    
    由于未额外使用SMTPROUTES：
    
    
  • 参考身份= MX（收件人域） -对收件人域执行DNS MX查询
    and returns：mx01.subd.emailhosted.not -此项不匹配与dNSName DNS：*.emailhosted.not、DNS：emailhosted.not项不匹配
• 提供的标识：CN存在，但由于dNSName也存在，因此会跳过。