Exchange2013 TLS传输层安全排错

Posted 2020-10-19

2018年新年新气象，首先祝大家新年嗨森，忙碌的2017年总算告一段落了，难得忙里偷闲两天整理整理2017年零零星星的点点滴滴，这一年有笑有泪，好像除了加班就是加班，感谢瘦小的身体竟然撑过了这一年，感谢这一年默默帮助我的大家，感谢人生中的每一段成长历练。新的一年要懂得感恩，多陪陪家人、多读书、多学习、多整理、多自省、多与人交流、多旅游、多投身公益事业等等。。。

概览：

Transport Layer Security——传输层安全协议，简称TLS。用于两个应用程序之间提供保密性和数据完整性。TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。(不管提到TLS还是SSL，都会引出二者相关概念性的介绍和差异对比)

Secure Socket Layer——安全套接字层，简称SSL。为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取。当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。

SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

架构图：

TLS/SSL协议提供的服务主要有：

1. 认证用户和服务器，确保数据发送到正确的客户机和服务器；

2. 加密数据以防止数据中途被窃取；

3. 维护数据的完整性，确保数据在传输过程中不被改变。

TLS与SSL的差异

1. 版本号：TLS记录格式与SSL记录格式相同，但版本号的值不同，TLS的版本1.0使用的版本号为SSLv3.1。

2. 报文鉴别码：SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法，两者差别在于SSLv3.0中，填充字节与密钥之间采用的是连接运算，而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。

3. 伪随机函数：TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块，是更安全的方式。

4. 报警代码：TLS支持几乎所有的SSLv3.0报警代码，而且TLS还补充定义了很多报警代码，如解密失败（decryption_failed）、记录溢出（record_overflow）、未知CA（unknown_ca）、拒绝访问（access_denied）等。

5. 密文族和客户证书：SSLv3.0和TLS存在少量差别，即TLS不支持Fortezza密钥交换、加密算法和客户证书。

6. certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时，计算的输入有少许差别，但安全性相当。

7. 加密计算：TLS与SSLv3.0在计算主密值（master secret）时采用的方式不同。

8. 填充：用户数据加密之前需要增加的填充字节。在SSL中，填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中，填充后的数据长度可以是密文块长度的任意整数倍（但填充的最大长度为255字节），这种方式可以防止基于对报文长度进行分析的攻击。

TLS的主要增强内容

TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：

1. 更安全的MAC算法

2. 更严密的警报

3. "灰色区域"规范的更明确的定义

TLS对于安全性的改进

1. 对于消息认证使用密钥散列法：TLS 使用"消息认证代码的密钥散列法"（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。

2. 增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。

3. 改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。

4. 一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。

5. 特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

接下来我们引入本章有关Exchange TLS的内容一例。

问题描述：

在与某银行来往邮件的时候，发现对方在给我司投递邮件的时候，收件人无法在我司邮件客户端或OWA查看该邮件内容，需要通过邮件链接跳转到对方银行提供的安全界面查看，返回的对应邮件截图如下：

环境（软件/硬件）：

WinSer2012R2+Exchange 2013CU10&17版本

原因分析：

根据对方安全提醒邮件内容并比对原始邮件分析，初步可确定我司邮件网关对外未开放TLS。

默认情况下，SMTP流量是不被加密的，这就导致在公网上进行邮件沟通就像是在广播一样，任何人拦截到该邮件都可以轻而易举的读取其内容。但是现实场景中有许多敏感信息是通过邮件来进行发送的，所以其中一种保护邮件安全的方法就是使用传输层安全协议（Transport Layer Security）来提供SMTP流量在传输中的加密，受TLS保护的SMTP流量可以让拦截/窃听者无法读取到SMTP流量的内容，但是它只提供传输过程中的保护，对于已经到达目标服务器，或者是在发件方本地服务器的邮件则没法提供保护。

有两种方法可以让Exchange使用TLS，第一种也是最简单的一种，叫做机会型TLS，意思是Exchange一有机会（对端服务器主动使用TLS）就会启用TLS，默认情况下机会型TLS功能会一直开着，而且会使用Exchange安装时候生成的自签名证书（如果你没指定证书的话）。Exchange 2013 还对所有远程连接主动尝试实现 TLS。

另一种是相互TLS，尽管TLS是一种传输层的加密，但是如果每台服务器通过验证另一台服务器提供的证书来验证这台服务器的身份的话，TLS也可以作为一种验证方法。Lync就基于相互TLS，当然Exchange也可以配置成这样。

机会型TLS不进行证书的有效性检查，有个自签名的证书它就认为是OK的，甚至是过期的证书也行。而相互TLS的应用要求则比较严格，因为Exchange会进行完整的证书检查，包括证书的时效性，查看发行者的证书吊销列表等等。

值得一提的是，Exchange 2013采用的是TLS V1.2，也是最新的TLS，其他的邮件服务器可能无法支持该版本，所以TLS的协商过程中，双方会声明自己的支持版本。在Microsoft Exchange上提供和接受的TLS版本、TLS会话中使用的加密算法，这些都是受Windows 安全通道子系统控制(即Schannel)，关于如何查看或者修改Windows使用了那种加密算法，可以参考这篇Technet文章：https://technet.microsoft.com/en-us/library/cc784149(v=ws.10).aspx 虽然这篇文章标明for windows 2003，但是在现在的版本里依旧适用。

补充：

相互 TLS ：进行相互身份验证的 TLS 与通常部署的 TLS 不同。通常部署 TLS 只是用于以加密的形式提供机密性。发送方和接收方之间不进行任何身份验证。除了这种部署之外，有时，TLS 部署只对接收服务器进行身份验证。这种 TLS 部署是 TLS 的 HTTP 实现方式的典型部署。此实现方式是 SSL，只对接收服务器进行身份验证。使用相互 TLS 身份验证，每台服务器通过验证另一台服务器提供的证书来验证另一台服务器的身份。

域安全性 ：域安全性是使相互 TLS 成为有用并且容易管理的技术的功能集，例如证书管理、连接器功能和 Outlook 客户端行为。

机会型 TLS ：在早期版本的 Exchange Server 中，必须手动配置 TLS。此外，必须在运行 Exchange Server 的服务器上安装适合 TLS 使用的有效证书。在 Exchange 2013 中，安装程序将创建自签名证书。默认情况下启用 TLS。这样，任何发送系统可以对 Microsoft Exchange 的入站简单邮件传输协议 (SMTP) 会话进行加密。默认情况下，Exchange 2013 还尝试对所有远程连接使用 TLS。

直接信任 ：默认情况下，边缘传输服务器与集线器传输服务器之间的所有通信均进行身份验证并加密。身份验证和加密的基础机制仍是相互 TLS。

解决步骤：

1.通过CheckTLS.com（www.checktls.com）网站查询我司邮件服务器是否支持TLS。

2.查询结果提示"TLS is not an option on this server",根据TLS查询结果初步确定为我司Ironport邮件网关incomming入站策略未启用TLS加密身份验证。

3.根据问题内容查看有关TLS相关端口及邮件接收连接器配置信息等；

通过内外部Telnet等操作发现Exchange服务器在内部TLS正常，而外部无法正常连接。此时可以初步确定问题在ironport邮件网关上。

4.打开Ironport，选择"邮件策略"——"邮件流策略"：

5.选择"默认策略参数"：

6.在"安全功能"模块界面——加密和身份验证——TLS安全选项位置，勾选"可选"：

7.提交更改：

8.确认修改，完成该TLS配置。

9.此时通过CheckTLS.com网站再次查询，发现TLS通过验证。

此时联系对方测试，邮件收发正常。该问题解决。

补充，CheckTLS.com检查中有提示证书问题，ironport更新证书操作如下：

a.依次勾选"网络"——"证书"——"添加证书"：

b.添加证书选项框中勾选"导入证书"：

c.单击浏览导入本地证书：

d.提交导入的新证书操作：

e.选择"网络"——"监听程序"——"Icomingmail"替换证书：

该警告可忽略，ironport默认值跟警告值其实是类似的，默认忽略。

本章内容分享告一段落。

引用文献(本文原理性内容大部分整理自网络，请见文后引用文献)：

https://segmentfault.com/a/1190000002554673