概覽：

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

Exchange2013 TLS傳輸層安全排錯