Transport Layer Security（TLS）和它早期版本Secure Sockets Layer（SSL）為網路加密協議，TLS協議是在SSL協議的基礎上進行改進升級，他們主要用於在計算機網路上提供通訊安全。其早期一些版本被廣泛使用於web瀏覽器、email、即時通訊、VoIP等。web網站通過該協議能夠保證瀏覽器於伺服器之間的安全通訊。

SSL/TLS協議主要提供通訊過程資料的保密性和完整性，在客戶端與服務端通訊過程中，主要包括以下幾點：

• 通訊資料保密性：主要防止資料被第三方截獲檢視。SSL/TLS協議採用對稱加密演算法，實現對傳輸內容的加密，而針對對稱加密所需的金鑰，則通過協議通訊過程中的handshake過程，實現對稱加密金鑰的協商，同時，該過程也包括協商加密的演算法。這個協商過程不同版本的協議，方法也存在一定的差異，需要注意。
• 通訊雙方身份認證：根據不同版本的SSL/TLS協議，其採用的身份認證方式、認證物件也存在不同，關於認證方式包括基於非對稱加密的身份認證和基於證書的身份認證，而認證物件也分為單向認證（只認證服務端）和雙向認證(客戶端和服務端雙向認證)
• 通訊資料的可靠性（即完整性）：協議通過Message Athenticaiton Code（MAC）訊息認證碼，來防止資料的篡改，以保證其真實完整。

SSL/TLS協議支援多種不同的金鑰交換、資料加密和資料完整性認證方法，具體內容後面將會講述。

一、SSL/TLS協議組成

協議由兩層構成：TLS Record Protocol和TLS Handshake Protocol

TLS Record Protocol處於較低的一層，基於可信任的協議之上，如TCP，為高層協議提供資料封裝、壓縮、加密等基本功能的支援。它保證了通訊的兩個基本安全屬性：

• 保密連線。資料傳輸使用對稱加密演算法，如AES，RC4等。該對稱加密演算法的金鑰對於每個連線是唯一的，基於金鑰協商協議生成，比如TLS handshake protocol，Record Protocol也可以不使用加密。

• 可信連線。訊息的傳輸包括了基於金鑰的訊息認證碼（keyed MAC），使用安全Hash函式計算MAC，用於完整性檢查。Record Protocol也可以不使用MAC，但是這種模式只用於安全引數協商時。

Record Protocol用於封裝多種高層的協議，其中一個種就是TLS handshake protocol，這種協議允許客戶與伺服器相互認證，在應用程式通訊前，協商加密演算法和加密金鑰。TLS handshake protocol保證了連線的三個基本安全屬性：

• 兩端的身份可以通過非對稱或者公鑰加密演算法（DSA，RSA等）進行認證。認證過程是可選的，但至少要求一端被認證。
• 共享金鑰的協商是安全的。金鑰協商對於監聽者和任何被認證的連線都是不可見的。
• 協商是可信的。攻擊者無法修改協商資訊。

TLS協議對資料的封裝如下圖所示：

二、SSL/TLS協議發展歷史

Netscape設計了SSL協議原型，SSL1.0由於存在嚴重漏洞，因此沒有釋出；在1995你那SSL2.0釋出，但其仍然存在許多安全問題，對此，在1996年釋出了SSL3.0。其中Taher Elgamal被稱作“SSL之父”。在2014年，SSL3.0被發現漏洞，能夠遭受POODLE攻擊，其影響所有組加密演算法。隨後，在2011年，RFC停止SSL2.0的更新，在2015年7月，停止對SSL3.0的更新。

TLS 1.0   首次於1999年進行定義，作為SSL3.0的升級版，但其餘SSL3.0差別不是很大，但TLS 1.0包含一種方法，通過該方法，TLS實現可以將連線降級到SSL 3.0，從而削弱安全性。

TLS1.1  於2006年4月釋出，他是TLS1.0版本的升級，其餘TLS1.0版本的不同包括：

              1.增強了對CBC模式攻擊的防護

              2.支援IANA引數註冊

TLS1.2  於2008年8月釋出，他是基於TLS1.1版本的升級，其修改內容包括：

             1.偽隨機函式（PRF）中的MD5-SHA-1組合被SHA-256替換，可選擇使用密碼套件指定的PRF

             2.已完成的訊息hash的MD5-SHA-1組合已替換為SHA-256，並且可以選擇使用密碼套件特定的雜湊演算法，另                                    外，在完成訊息hash的大小至少為96bit。

             3.數字簽名元素中的MD5-SHA-1組合被替換為握手期間協商的單個雜湊值，預設為SHA-1。

             4.增強客戶端和伺服器指定接受哪些雜湊值和簽名演算法的能力

             5.擴充套件對經過身份驗證的加密密碼的支援，主要用於Galois / Counter Mode（GCM）和CCM模式的高階加密標                               準 （AES）加密

             6.添加了TLS擴充套件定義和AES密碼套件

在2011年，所有TLS版本重新修訂，移除了與SSL向後相容性，以便TLS會話永遠不會協商使用安全套接字層（SSL）2.0版。

TLS 1.3  於2018年8月釋出，是在TLS1.2版本基礎上升級，做了大量修改：

             1.將金鑰協議和身份驗證演算法與密碼套件分開

             2.刪除對弱和較少使用的命名橢圓曲線的支援

             3.刪除對MD5和SHA-224加密雜湊函式的支援

             4.即使使用先前的配置，也需要數字簽名

             5.整合HKDF和半短暫的DH提案

             6.支援1-RTT握手和0-RTT的初始支援

             7.Replacing resumption with PSK and tickets

            8.通過在（EC）DH金鑰協議期間使用短暫金鑰來強制完美的前向保密

            9.刪除對許多不安全或過時功能的支援，包括壓縮，重新協商，非AEAD密碼，非PFS金鑰交換（其中包括靜態                                RSA和靜態DH金鑰交換），自定義DHE組，EC點格式協商，Change Cipher Spec協議， Hello訊息UNIX時                                  間，以及輸入到AEAD密碼的長度欄位AD

           10.禁止SSL或RC4協商以實現向後相容性

           11.整合使用會話雜湊

           12.棄用記錄層版本號並凍結該數字以提高向後相容性

           13.使用Poly1305訊息驗證程式碼新增ChaCha20流密碼

           14.新增Ed25519和Ed448數字簽名演算法

           15.新增x25519和x448金鑰交換協議

三、SSL/TLS協議具體簡述

SSL/TLS協議RSA模式金鑰互動簡單流程介紹（需說明：下圖非SSL/TLS標準過程圖，也非作者原創，純屬網路參考）

1. 客戶端發起會話，與支援SSL/TLS協議的伺服器通訊，其傳送內容包含問候資料、客戶端random和其所支援的加密套件（金鑰協商演算法、對稱加密演算法和MAC演算法）等
2. 伺服器接收相關資訊後，響應相關請求，傳送選擇的加密套件資訊、server random和公鑰證書，進行身份驗證等。
3. 客戶端收到伺服器相關響應後，對其進行身份驗證，驗證通過後，根據協商的加密套件資訊，計算得到Premaster secret，並用服務端的公鑰進行加密，並傳遞給服務端，其中Premaster secret用於會話金鑰的生成。
4. 客戶端傳送ChangeCipherSpec record，主要用於驗證服務端是否生成的金鑰與自己產生的金鑰相同。客戶端將傳送一個認證和加密的前面握手互動資訊（Finished message）其中主要包括一個雜湊值和MAC，如果伺服器收到並驗證通過，則以同樣的方式驗證客戶端，如果驗證不通過，則會話結束。
5. 當客戶端和服務端驗證所產生的金鑰相同時，握手階段完成，接著為資料內容傳輸。

安全性分析

Client Random 和 Server Random 明文傳輸,中間人可以直接檢視。客戶端生成 Premaster Secret 後,用服務端證書公鑰加密後傳送,如果服務端擁有對應的私鑰,就可以成功解密得到 Premaster Secret。這時,客戶端和服務端擁有相同的 Client Random、Server Random 和 Premaster Secret,可以各自算出相同的後續所需 Key。,這種方式合併了金鑰交換和服務端認證兩個步驟,如果服務端能解密 Premaster Secret,也就意味著服務端擁有正確的私鑰。中間人沒有私鑰,無法得到 Premaster Secret,也就無法解密後續流量。對於 Wireshark 來說,配置某個網站的私鑰後,能解密這個網站「使用 RSA 進行金鑰交換」的加密流量就很容易理解了。 顯然,RSA 金鑰交換有一個很大的問題:沒有前向安全性(Forward Secrecy)。這意味著攻擊者可以把監聽到的加密流量先存起來,後續一旦拿到了私鑰,之前所有流量都可以成功解密。下圖為 ECDHE 金鑰交換模式流程圖

上圖中的 Server DH Parameter 是用證書私鑰簽名的,客戶端使用證書公鑰就可以驗證服務端合法性。相比 RSA 金鑰交換,DH 由傳遞 Premaster Scret 變成了傳遞 DH 演算法所需的 Parameter,然後雙方各自算出 Premaster Secret。 

對於這種情況,由於 Premaster Secret 無需交換,中間人就算有私鑰也無法獲得 Premaster Secret 和 Master Secret。也就是說 Wireshark 無法通過配置 RSA Private Key 的方式解密「使用 ECDHE 進行金鑰交換」的加密流量。當然,使用 ECDHE 後,雖然中間人拿到私鑰也無法解密之前的流量,但他可以實施 MITM 攻擊來解密之後的流量,所以私鑰還是要保管好。

相比 RSA 既可以用於金鑰交換,又可以用於數字簽名;ECC 這邊就分得比較清楚了:ECDHE 用於金鑰交換,ECDSA 用於數字簽名。也就是目前金鑰交換 + 簽名有三種主流選擇: 

• RSA 金鑰交換、RSA 數字簽名; 
• ECDHE 金鑰交換、RSA 數字簽名; 
• ECDHE 金鑰交換、ECDSA 數字簽名;

關於SSL/TLS主要的三個過程：金鑰協商過程、資料加密過程、完整性驗證過程。所涉及加密演算法統計表如下：

• 金鑰協商交換演算法統計表

• 資料加密演算法統計表

• 訊息驗證碼演算法統計表

四、針對SSL/TLS攻擊

1. Renegotiation attack

2. Downgrade attacks: FREAK attack and Logjam attack

3. Cross-protocol attacks: DROWN

4. BEAST attack

5. CRIME and BREACH attacks

6. Timing attacks on padding

7. POODLE attack

8. RC4 attacks

9. Truncation attack

10. Unholy PAC attack

11. Sweet32 attack

12. Implementation errors: Heartbleed bug, BERserk attack, Cloudflare bug

13. 中間人攻擊

注：本文主要用於個人所蒐集資料的整理，並非傳播網路攻擊教程。

參考：