一、誕生原因

傳統(tǒng)的 HTTP 是明文傳輸數(shù)據(jù)，容易被黑客截獲，甚至產(chǎn)生中間人攻擊。

二、大致過程

client 和 server 確定通信使用的加密算法、數(shù)據(jù)壓縮算法、對稱密鑰。

雙方使用對稱密鑰進行數(shù)據(jù)加密傳輸。

由上述描述可知，https 最終使用的依然是對稱密鑰加密，因為對稱加密算法較非對稱計算速度快并且本身也足夠安全。唯一麻煩的事是雙方如何安全地確定對稱密鑰，在這個過程中需要使用非對稱密鑰進行過度。

三、流程圖

不考慮 server 校驗 client 證書、限制?client 連接 server 的目的是開啟一個全新的連接。

四、過程說明

1、Client Hello：通知 Server 開啟一個新的 Session 并傳入以下數(shù)據(jù)：

（1）SSL/TLS 版本號。version 2 表示的是 SSL 2.0，version 3 表示的是 SSL 3.0，version 3.1 表示的是 TLS 1.0。

（2）隨機數(shù) Random C1。一共 32 個字節(jié)。前面 4 個字節(jié)是當(dāng)前時間戳，后面 28 個字節(jié)是一個隨機數(shù)。后面協(xié)商對稱加密的 Session Key 會用到。

（3）Cipher Suite。支持的加密組件列表。例如 TLS_RSA_WITH_DES_CBC_SHA，TLS? 是 TLS 協(xié)議版本，TLS 表示 TLS1.0，RSA 是密鑰交換算法，DES_CBC 是加密算法，SHA 是摘要算法。

（4）壓縮算法。表示建議選用的是哪種壓縮算法。

栗子：

ClientVersion 3,1 ClientRandom[32] SessionID: None (new session) Suggested Cipher Suites:TLS_RSA_WITH_3DES_EDE_CBC_SHATLS_RSA_WITH_DES_CBC_SHA Suggested Compression Algorithm: NONE

2、Server Hello：服務(wù)器收到客戶端的 Client Hello 消息會響應(yīng)一個 Server Hello 消息，包括以下字段：

（1）SSL / TLS 版本，客戶端和服務(wù)器都支持的 SSL / TLS 最高版本。

（2）隨機數(shù) Random S，一共 32 個字節(jié)，前面 4 個字節(jié)是當(dāng)前時間戳，后面 28 個字節(jié)是一個隨機數(shù)。后面協(xié)商對稱加密的 Session Key 會用到。

（3）Cipher Suite，服務(wù)器從剛才 Client Hello 消息的 Cipher Suite 加密列表中選中的加密組件。

（4）壓縮算法，表示選中的是哪種壓縮算法。

Version 3,1 ServerRandom[32] SessionID: bd608869f0c629767ea7e3ebf7a63bdcffb0ef58b1b941e6b0c044acb6820a77 Use Cipher Suite:TLS_RSA_WITH_3DES_EDE_CBC_SHA Compression Algorithm: NONE

3、Server Certificate：Server?發(fā)給 Client 的證書，包含公鑰。Client 校驗證書的合法性，比如證書包含的域名是否就是客戶端正在訪問的域名。

4、Server Hello Done：表示 Server 已經(jīng)發(fā)送消息完畢并且在等待 Client 回復(fù)。Client 收到上述數(shù)據(jù)之后，進行如下操作：

（1）生成 Random C2，用 Server 的公鑰對其進行非對稱加密生成 PreMaster Secret；

（2）運用算法，通過 Random C1、PreMaster Secret 和 Random S 生成 Session Key。Session Key 就是之后 HTTPS 正常通信時使用的對稱加密的 key 。

5、Client Key Exchange：該消息包含?PreMaster Secret?以及 TLS 版本。

再次帶上版本號是因為之前的版本號是明文傳輸?shù)?#xff0c;攻擊者可能會惡意修改為較低的版本號，從而降低連接的安全系數(shù)方便發(fā)起攻擊。該消息字段會用公鑰加密。

現(xiàn)在 Server 一共有 Random C1、PreMaster Secret 和 Random S 三個隨機數(shù)，Server 會運用和 Client 相同的算法，將這三個隨機數(shù)作為參數(shù)，計算得到另外的一個隨機數(shù)，即后面對稱加密的密鑰 Session Key。

6、Change Cipher Spec：該消息通知 Server 接下來的 Client Finished 消息將會用剛才協(xié)商的密鑰 Session Key 來加密。

7、Encrypted Handshake Message（Client Finished）：該消息會列舉 Client 上面用到的所有加密字段，并且算出他們的 HASH 值，然后用 Session Key 加密。

8、Change Cipher Spec：該消息通知客戶端接下來的消息會用Session Key來加密。

9、Encrypted Handshake Message（Server Finished）：對整個協(xié)商階段用到的字段算一個 HASH，然后用 Session Key 加密。

10、Application Data：雙方使用 Session Key 進行對稱加密進行數(shù)據(jù)的傳輸。

五、拓展

1、生成 Session Key 為什么需要三個隨機數(shù)？

理論上 Server 無法信任 Client 產(chǎn)生的隨機數(shù)，該隨機數(shù)可能是固定值，有可能是通過隨機函數(shù)生成，都是由規(guī)律的，所以需要加入 Server 自己的隨機值。這樣隨機數(shù)變成了 2 個，2 個也是不夠的，因為上述過程中，隨機數(shù)是明文傳輸?shù)?#xff0c;需要加入一個密文傳輸?shù)碾S機數(shù)，故計算 Session Key 理論上需要的隨機數(shù)的數(shù)量至少為 3 個。

2、校驗 CA 證書的過程是什么？

要明白校驗過程，需要先明白證書中包含的內(nèi)容是否什么，如下所示：

上述圖片是 CSDN 的授權(quán)證書。 指明了證書的頒發(fā)機構(gòu)、證書的使用機構(gòu)、有效期以及匹配的域名。總的來說，CA 機構(gòu)會將證書使用者的信息放入證書中，生成 hash 值放入后面，并用 CA 自己的私鑰對 hash 值進行非對稱加密，這樣就產(chǎn)生了 CA 機構(gòu)的數(shù)字簽名。

所以根據(jù)上述內(nèi)容，Client 校驗 CA 證書的內(nèi)容大致如下：

• SSL證書是否由受信任的CA機構(gòu)頒發(fā)的。
• 證書是否過期。
• 訪問的網(wǎng)站域名與證書綁定的域名是否一致。
• 用 CA 的公鑰解密數(shù)字簽名生成 hash 1，并通過證書中的 hash 算法生成 hash 2，比對 hash 1 和 hash 2，則該證書內(nèi)容沒有改動。

通過上述 4 條的校驗，若均通過，則認(rèn)為該證書合法。

（SAW：Game Over！）

總結(jié)

以上是生活随笔為你收集整理的通信 / HTTPS 过程详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。