目錄

前言

TLS/SSL 基礎概念

密鑰協商過程中存在的問題及解決辦法

TLS/SSL 握手過程

---

前言

本文是對?HTTPS 安全基礎、TLS/SSL 工作原理及握手過程的總結。第一部分介紹為 HTTPS 提供安全基礎的 TLS/SSL 的基礎概念，及數據傳輸過程中密鑰協商的原因。第二部分介紹密鑰協商過程中存在的問題，及解決辦法，其中會涉及?PKI、CA 等概念。最后介紹 TLS/SSL 的握手過程。

HTTP 和 HTTPS 的區別：https://blog.csdn.net/qq_38289815/article/details/80969419

?

TLS/SSL 基礎概念

概念源自百度百科：傳輸層安全性協議 TLS（Transport Layer Security），及其前身安全套接層 SSL（Secure Sockets Layer）是一種安全協議，目的是為互聯網通信提供安全及數據完整性保障。網景公司（Netscape）在 1994 年推出首版網頁瀏覽器，網景導航者時，推出 HTTPS?協議，以 SSL 進行加密，這是 SSL 的起源。IETF?將 SSL 進行標準化，1999 年公布第一版 TLS 標準文件。隨后又公布RFC 5246（2008年8月）與RFC 6176（2011年3月）。在瀏覽器、郵箱、即時通信、VoIP、網絡傳真等應用程序中，廣泛支持這個協議。主要的網站，如?Google、Facebook?等也以這個協議來創建安全連線，發送數據。目前已成為互聯網上保密通信的工業標準。

TLS/SSL 的功能實現主要依賴于三類基本算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法采用協商的密鑰對數據加密，基于散列函數驗證信息的完整性。??

散列函數 Hash

常見的有 MD5、SHA1、SHA256，該類函數特點是函數單向不可逆、對輸入非常敏感、輸出長度固定，針對數據的任何修改都會改變散列函數的結果，用于防止信息篡改并驗證數據的完整性。在信息傳輸過程中，散列函數不能單獨實現信息防篡改，因為明文傳輸，中間人可以修改信息之后重新計算信息摘要，因此需要對傳輸的信息以及信息摘要進行加密。

對稱加密

常見的有 AES-CBC、DES、3DES、AES-GCM 等，信息的加密和解密用相同的密鑰，掌握密鑰才能獲取信息。在對稱加密中，信息安全的基礎是保證密鑰的安全。

非對稱加密

即常見的 RSA 算法，還包括 ECC、DH 等算法，算法特點是，密鑰成對出現，一般稱為公鑰(公開)和私鑰(保密)。因此掌握公鑰的不同客戶端之間不能互相解密信息，只能和掌握私鑰的服務器進行加密通信。服務器持有私鑰可以實現一對多的通信，而客戶端可以用公鑰來驗證服務器發送的數字簽名。服務器只需要維持一個私鑰就能夠和多個客戶端進行加密通信，但該算法的計算復雜，加密速度慢。

結合三類算法的特點，TLS/SSL 的基本工作方式是，客戶端使用非對稱加密與服務器進行通信，實現身份驗證并協商對稱加密使用的密鑰，然后對稱加密算法采用協商密鑰對信息以及信息摘要進行加密通信，不同的節點之間采用的對稱密鑰不同，從而可以保證信息只能通信雙方獲取。

?

?

密鑰協商過程中存在的問題及解決辦法

存在的問題

上面介紹了?TLS/SSL 在 HTTPS 信息傳遞中扮演的角色，我們知道了要用非對稱加密與服務器進行通信，實現身份驗證并協商對稱加密使用的密鑰。可是這個公鑰是怎么傳遞給客戶端的？

?

上面圖中的過程是不安全的，接下來對該問題進行說明。與公鑰密碼加密系統相伴的一個重要挑戰就是正確地決定某個主體或身份的公鑰。如果 A 向 B 發送自已的公鑰，M 能夠在傳輸過程中將其修改為自己的公鑰。B (也被稱為依賴方)可能察覺不到自已使用的是 M 的公鑰，而認為這是 A 的公鑰。這樣就使得 M 能夠輕易地扮演 A 的角色，即如下圖所示：

?

解決辦法

一種常見的方法是依靠中心化的機構，其中包括對公鑰基礎設施 PKI?(Public?Key?Infrastructure)?的使用。這一方法在特定的理論假設下容易被證明是安全的。?PKI 負責提供創建、吊銷、分發以及更新密鑰對與證書的服務。它需要一些證書頒發機構 CA? (Certificate?Authority)?才能運行。證書頒發機構是用于管理與認證一些個體與它們的公鑰間的綁定關系的實體。目前有數百家商業證書頒發機構。一個證書頒發機構通常采用層次的簽名構架。這意味著一個公鑰可能會被一個父密鑰簽名，而這個父密鑰可能會被一個祖父密鑰簽名，依次類推。最終，一個證書頒發機構會擁有一個或多個根證書，許多下屬的證書都會依賴根證書來建立信任。

在實踐中，系統往往要求公鑰操作應當擁有知名 CA 的根證書。這些根證書是在配置時安裝的 (例如，微軟公司的 Intemet ExpIorer 瀏覽器、 Mozilia 公司的 Firefox 瀏覽器以及 Google 公司的 Chrome 瀏覽器都能夠訪問一個預先配置的根證書數據庫)。

?

?

TLS/SSL 握手過程

1. client_hello

客戶端發起請求，以明文傳輸請求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數，擴展字段等信息，相關信息如下：

(1) 支持的最高TSL協議版本version，從低到高依次 SSLv2，SSLv3，TLSv1，TLSv1.1，TLSv1.2，TLSv1.3。

(2) 客戶端支持的加密套件 cipher suites 列表， 每個加密套件對應前面 TLS 原理中的四個功能的組合：認證算法 Au (身份驗證)、密鑰交換算法 Key?Exchange(密鑰協商)、對稱加密算法 Enc (信息加密)和信息摘要 Mac(完整性校驗)。

(3) 支持的壓縮算法 compression methods 列表，用于后續的信息壓縮傳輸。

(4)?隨機數 random_C，用于后續的密鑰的生成。

(5) 擴展字段 extensions，支持協議與算法的相關參數以及其它輔助信息等，常見的 SNI 就屬于擴展字段，后續單獨討論該字段作用。

?

2. server_hello + server_certificate + sever_hello_done

(1) server_hello， 服務端返回協商的信息結果，包括選擇使用的協議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method、隨機數 random_S?等，其中隨機數用于后續的密鑰協商。

(2) server_certificates，服務器端配置對應的證書鏈，用于身份驗證與密鑰交換。

(3) server_hello_done，通知客戶端 server_hello 信息發送結束。

?

3. 證書校驗

客戶端驗證證書的合法性，如果驗證通過才會進行后續通信，否則根據錯誤情況不同做出提示和操作，合法性驗證包括如下：

(1) 證書鏈的可信性 trusted certificate path。

(2) 證書是否吊銷 revocation，有兩類方式離線 CRL 與在線 OCSP，不同的客戶端行為會不同。

(3) 有效期 expiry date，證書是否在有效時間范圍。

(4) 域名 domain，核查證書域名是否與當前的訪問域名匹配，匹配規則后續分析。

?

4. client_key_exchange + change_cipher_spec + encrypted_handshake_message

(1) client_key_exchange，合法性驗證通過之后，客戶端計算產生隨機數字 Pre-master，并用證書公鑰加密，發送給服務器。

(2) 此時客戶端已經獲取全部的計算協商密鑰需要的信息：兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master，計算得到協商密鑰：?enc_key = Function(random_C,?random_S,?Pre-Master); 。

(3) change_cipher_spec，客戶端通知服務器后續的通信都采用協商的通信密鑰和加密算法進行加密通信。

(4) encrypted_handshake_message，結合之前所有通信參數的 hash 值與其它相關信息生成一段數據，采用協商密鑰 session secret 與算法進行加密，然后發送給服務器用于數據與握手驗證。

?

5. change_cipher_spec + encrypted_handshake_message

(1) 服務器用私鑰解密加密的 Pre-master 數據，基于之前交換的兩個明文隨機數 random_C 和 random_S，計算得到協商密鑰：enc_key = Function(random_C,?random_S,?Pre-Master); 。

(2) 計算之前所有接收信息的 hash 值，然后解密客戶端發送的 encrypted_handshake_message，驗證數據和密鑰正確性。

(3) change_cipher_spec， 驗證通過之后，服務器同樣發送 change_cipher_spec 以告知客戶端后續的通信都采用協商的密鑰與算法進行加密通信。

(4) encrypted_handshake_message， 服務器也結合所有當前的通信參數信息生成一段數據并采用協商密鑰 session secret 與算法加密并發送到客戶端。(將隨機密碼加密的數據響應給客戶端)

?

6. 握手結束

客戶端計算所有接收信息的 hash 值，并采用協商密鑰解密 encrypted_handshake_message，驗證服務器發送的數據和密鑰，驗證通過則握手完成。

?

7. 加密通信

開始使用協商密鑰與算法進行加密通信。注意：

(1) 服務器也可以要求驗證客戶端，即雙向認證，可以在過程 2 要發送 client_certificate_request 信息，客戶端在過程 4 中先發送? client_certificate 與 certificate_verify_message 信息，證書的驗證方式基本相同，certificate_verify_message 是采用 client 的私鑰加密的一段基于已經協商的通信信息得到數據，服務器可以采用對應的公鑰解密并驗證。

(2) 根據使用的密鑰交換算法的不同，如 ECC 等，協商細節略有不同，總體相似。

(3) sever key exchange 的作用是 server certificate 沒有攜帶足夠的信息時，發送給客戶端以計算 pre-master，如基于 DH 的證書，公鑰不被證書中包含，需要單獨發送。

(4) change cipher spec 實際可用于通知對端改版當前使用的加密通信方式，當前沒有深入解析。

(5) alter message 用于指明在握手或通信過程中的狀態改變或錯誤信息，一般告警信息觸發條件是連接關閉，收到不合法的信息，信息解密失敗，用戶取消操作等，收到告警信息之后，通信會被斷開或者由接收方決定是否斷開連接。

?

簽名過程

發送報文時，發送方用一個哈希函數從報文文本中生成報文摘要，然后用發送方的私鑰對這個摘要進行加密，這個加密后的摘要將作為報文的數字簽名和報文一起發送給接收方。接收方首先用與發送方一樣的哈希函數從接收到的原始報文中計算出報文摘要，接著再用公鑰來對報文附加的數字簽名進行解密，如果這兩個摘要相同、那么接收方就能確認該報文是發送方的。

數字簽名有兩種功效：一是能確定消息確實是由發送方簽名并發出來的，因為別人假冒不了發送方的簽名。二是數字簽名能確定消息的完整性。因為數字簽名的特點是它代表了文件的特征，文件如果發生改變，數字摘要的值也將發生變化。不同的文件將得到不同的數字摘要。 一次數字簽名涉及到一個哈希函數、接收者的公鑰、發送方的私鑰。

?

參考：百度百科、《TCP/IP詳解卷1：協議》

https://blog.csdn.net/freekiteyu/article/details/76423436

https://blog.csdn.net/hherima/article/details/52469674

總結

以上是生活随笔為你收集整理的TLS/SSL 工作原理及握手过程详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。