前言

什么是HTTPS

HTTPS，Hyper Text Transfer Protocol over SecureSocket Layer，超文本傳輸安全協(xié)議。

在 TCP 和 HTTP 之間加入了 SSL/TLS 安全協(xié)議，使得報(bào)文能夠加密傳輸。在 TCP 三次握手之后，還需進(jìn)行 SSL/TLS 的握手過程，才可進(jìn)入加密報(bào)文傳輸。

SSL代表安全套接字層。它是一種用于加密和驗(yàn)證應(yīng)用程序（如瀏覽器）和Web服務(wù)器之間發(fā)送的數(shù)據(jù)的協(xié)議。 身份驗(yàn)證 ， 加密Https的加密機(jī)制是一種共享密鑰加密和公開密鑰加密并用的混合加密機(jī)制。

SSL/TLS協(xié)議作用：認(rèn)證用戶和服務(wù)，加密數(shù)據(jù)，維護(hù)數(shù)據(jù)的完整性的應(yīng)用層協(xié)議加密和解密需要兩個(gè)不同的密鑰，故被稱為非對(duì)稱加密；加密和解密都使用同一個(gè)密鑰的 對(duì)稱加密。 優(yōu)點(diǎn)在于加密、解密效率
通常比較高HTTPS 是基于非對(duì)稱加密的， 公鑰是公開的，
（1）客戶端向服務(wù)器端發(fā)起SSL連接請(qǐng)求；
（2） 服務(wù)器把公鑰發(fā)送給客戶端，并且服務(wù)器端保存著唯一的私鑰
（3）客戶端用公鑰對(duì)雙方通信的對(duì)稱秘鑰進(jìn)行加密，并發(fā)送給服務(wù)器端
（4）服務(wù)器利用自己唯一的私鑰對(duì)客戶端發(fā)來的對(duì)稱秘鑰進(jìn)行解密，
（5）進(jìn)行數(shù)據(jù)傳輸，服務(wù)器和客戶端雙方用公有的相同的對(duì)稱秘鑰對(duì)數(shù)據(jù)進(jìn)行加密解密，可以保證在數(shù)據(jù)收發(fā)過程中的安全，即是第三方獲得數(shù)據(jù)包，也無法對(duì)其進(jìn)行加密，解密和篡改。

因?yàn)閿?shù)字簽名、摘要是證書防偽非常關(guān)鍵的武器。 “摘要”就是對(duì)傳輸?shù)膬?nèi)容，通過hash算法計(jì)算出一段固定長(zhǎng)度的串。然后，在通過CA的私鑰對(duì)這段摘要進(jìn)行加密，加密后得到的結(jié)果就是“數(shù)字簽名”。

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密

HTTPS的作用

因?yàn)?HTTP 是明文傳輸，所以會(huì)存在以下三個(gè)風(fēng)險(xiǎn)，使用起來極其不安全，所以就誕生了 HTTPS，也就是在 HTTP 之上加入了 SSL/TLS 安全協(xié)議，來解決 HTTP 的安全問題。

• 通過信息加密，解決HTTP的竊聽風(fēng)險(xiǎn)（由于是明文傳輸，只要監(jiān)聽通信鏈路即可獲得包內(nèi)的數(shù)據(jù)）。
• 通過校驗(yàn)機(jī)制，解決HTTP的篡改風(fēng)險(xiǎn)（對(duì)服務(wù)器發(fā)來的數(shù)據(jù)沒有校驗(yàn)，被篡改了也無法驗(yàn)證）。
• 通過身份證書，解決HTTP的冒充風(fēng)險(xiǎn)（可以冒充服務(wù)器發(fā)送數(shù)據(jù)）。 具體是通過以下三種方式來解決 HTTP 的安全問題的。

混合加密

HTTPS 采用的是對(duì)稱加密和非對(duì)稱加密結(jié)合的「混合加密」方式：

• 在通信建立前采用非對(duì)稱加密的方式交換「會(huì)話秘鑰」，后續(xù)就不再使用非對(duì)稱加密。
• 在通信過程中全部使用對(duì)稱加密的「會(huì)話秘鑰」的方式加密明文數(shù)據(jù)。

采用「混合加密」的方式的原因：

對(duì)稱加密只使用一個(gè)密鑰，運(yùn)算速度快，但密鑰必須保密，無法做到安全的密鑰交換。
非對(duì)稱加密使用兩個(gè)密鑰：公鑰和私鑰，公鑰可以任意分發(fā)而私鑰保密，解決了密鑰交換問題但速度慢。

校驗(yàn)機(jī)制：摘要算法+數(shù)字簽名

在發(fā)送內(nèi)容前，對(duì)傳輸?shù)膬?nèi)容進(jìn)行摘要算法（哈希函數(shù)）計(jì)算，得到一個(gè)唯一且無法推導(dǎo)的哈希值，即內(nèi)容的指紋，將哈希值與內(nèi)容一同發(fā)送出去，在接收后再次進(jìn)行哈希計(jì)算，校驗(yàn)哈希值，從而保證內(nèi)容是完整且未被篡改的。

但是仍然無法保證內(nèi)容和哈希值都被中間替換過，所以需要再使用私鑰加密，公鑰解密的非對(duì)稱加密來解決。

我們常說的數(shù)字簽名算法，就是用的是這種方式，不過私鑰加密內(nèi)容不是內(nèi)容本身，而是對(duì)內(nèi)容的哈希值加密。

公鑰加密，私鑰解密。這個(gè)目的是為了保證內(nèi)容傳輸?shù)陌踩?，因?yàn)楸还€加密的內(nèi)容，其他人是無法解密的，只有持有私鑰的人，才能解密出實(shí)際的內(nèi)容；
私鑰加密，公鑰解密。這個(gè)目的是為了保證消息不會(huì)被冒充，因?yàn)樗借€是不可泄露的，如果公鑰能正常解密出私鑰加密的內(nèi)容，就能證明這個(gè)消息是來源于持有私鑰身份的人發(fā)送的。

數(shù)字證書
通過摘要算法，我們能保證數(shù)據(jù)的完整性；通過數(shù)字簽名，我們能保證數(shù)據(jù)的來源一定是私鑰持有者。

但是還缺少了身份驗(yàn)證環(huán)節(jié)，萬一公私鑰被替換過，校驗(yàn)仍然可以通過。所以需要對(duì)公私鑰進(jìn)行身份驗(yàn)證，HTTPS 規(guī)定只有權(quán)威機(jī)構(gòu)能夠頒發(fā)證書，而且拿到證書后也需要進(jìn)行權(quán)威機(jī)構(gòu)的認(rèn)證。

CA，Certification Authority，數(shù)字證書認(rèn)證機(jī)構(gòu)。數(shù)字證書的工作流程如下圖所示。

TLS建立連接過程

TLS 建立連接的過程，就是客戶端向服務(wù)器索要并驗(yàn)證 CA公鑰，隨后雙方協(xié)商產(chǎn)生會(huì)話密鑰的過程。

整個(gè)過程可以分為七個(gè)部分，其中 TLS 的握手過程涉及四次通信。接下來將根據(jù) Wireshark 的抓包結(jié)果進(jìn)行過程的拆分和分析。

1、TCP三次握手

TLS 層是在 TCP 層之上的，所以在建立 TLS 連接之前，需要先建立 TCP 連接。

第一次握手: 客戶端發(fā)送syn標(biāo)志位和seq num，向服務(wù)器申請(qǐng)建立連接，客戶端狀態(tài)由closed變?yōu)閟yn_send

第二次握手: 服務(wù)端返回 syn和ack標(biāo)志位，ack num以及seq num，確認(rèn)第一次握手的報(bào)文段，返回ack num=seq num(第一次握手發(fā)送的)+1，同意建立連接，服務(wù)器狀態(tài)由listen變?yōu)閟yn_received

第三次握手: 發(fā)送確認(rèn)報(bào)文段，返回ack以及ack num=seq num(第二次握手發(fā)送的)+1，客戶端狀態(tài)變?yōu)椋篹stablished(完成連接)

最后: 服務(wù)器收到確認(rèn)報(bào)文段，服務(wù)器狀態(tài)由syn_received變?yōu)閑stablished(完成連接)

三次握手原因
(1) TCP連接的特性決定，一次RT(往返)完成一次TCP的動(dòng)作。
即客戶端一次請(qǐng)求攜帶的seq num必須得到服務(wù)端的ack num才會(huì)完成。如果沒有返回確認(rèn)報(bào)文段，由于重發(fā)機(jī)制，定時(shí)器經(jīng)過了一次RTO，客戶端就會(huì)重發(fā)報(bào)文。那為什么客戶端最后一次發(fā)送之后，沒有等待服務(wù)端發(fā)回ack報(bào)文段？ 這是因?yàn)榉?wù)端第二次發(fā)送的報(bào)文段里 包含ack以及請(qǐng)求syc報(bào)文，相當(dāng)于把確認(rèn)報(bào)文和請(qǐng)求報(bào)文合并了，所以最后客戶端回復(fù)一個(gè)ack報(bào)文即可。

(2) 防止失效的報(bào)文創(chuàng)建連接。
因?yàn)榛ヂ?lián)網(wǎng)鏈路是非常復(fù)雜的，發(fā)送的報(bào)文可能會(huì)被互聯(lián)中的網(wǎng)絡(luò)設(shè)備阻塞，經(jīng)過了一段時(shí)間才到達(dá)服務(wù)器，時(shí)間大于了RTO(Retransmission TimeOut)時(shí)間，導(dǎo)致客戶端重發(fā)syc報(bào)文(重新創(chuàng)建新的連接，并丟失超時(shí)的連接)。如果只有兩次握手，那么服務(wù)器每接收到syc報(bào)文(包括重發(fā)的syc報(bào)文)，就會(huì)創(chuàng)建多余的連接，造成服務(wù)器的資源浪費(fèi)。如果有第三次握手，那么客戶端就能夠識(shí)別出服務(wù)端發(fā)出的syc和ack報(bào)文對(duì)應(yīng)的請(qǐng)求連接在客戶端是否存活，如果存活則發(fā)送第三次握手ack報(bào)文，確認(rèn)建立連接。

注：通常，第一次超時(shí)重傳是在 1 秒后，第二次超時(shí)重傳是在 2 秒，第三次超時(shí)重傳是在 4 秒后，第四次超時(shí)重傳是在 8 秒后，第五次是在超時(shí)重傳 16 秒后。沒錯(cuò)，每次超時(shí)的時(shí)間是上一次的 2 倍。

當(dāng)?shù)谖宕纬瑫r(shí)重傳后，會(huì)繼續(xù)等待 32 秒，如果服務(wù)端仍然沒有回應(yīng) ACK，客戶端就會(huì)終止三次握手。

所以，總耗時(shí)是 1+2+4+8+16+32=63 秒，大約 1 分鐘左右。

2、Client Hello

由客戶端向服務(wù)器發(fā)起建立 TLS 請(qǐng)求，請(qǐng)求的內(nèi)容包括以下等信息：

• 客戶端支持的 SSL/TLS 協(xié)議版本。
• 客戶端生產(chǎn)的隨機(jī)數(shù)（Client Random），后面用于生成會(huì)話秘鑰的條件之一。
• 客戶端支持的加密套件列表，如 RSA 等加密算法。
  

3、Sever Hello

服務(wù)器收到客戶端的建立請(qǐng)求后，向客戶端發(fā)出響應(yīng)，回應(yīng)的內(nèi)容包括以下等信息：

• 確認(rèn) SSL/ TLS 協(xié)議版本（如果瀏覽器不支持，則關(guān)閉加密通信）。
• 服務(wù)器生產(chǎn)的隨機(jī)數(shù)（Server Random），也是后面用于生產(chǎn)會(huì)話秘鑰的條件之一。
• 確認(rèn)的加密套件。
• 服務(wù)器的數(shù)字證書。
  

4、校驗(yàn)數(shù)字證書

5、客戶端回應(yīng)

客戶端會(huì)從數(shù)字證書中取出服務(wù)器的公鑰，然后使用它加密報(bào)文，向服務(wù)器發(fā)送以下信息：

5.1 Client Key Exchange：基于前面提到的兩個(gè)隨機(jī)數(shù)（client random+server random），再生成第 3 個(gè)隨機(jī)數(shù) pre-master，然后通過CA證書中的公鑰，對(duì) pre-master 加密，得到 pre-master key，發(fā)送給服務(wù)器。

5.2 Change Cipher Spec：加密通信算法改變通知，表示客戶端隨后的信息都將用會(huì)話秘鑰加密通信。

5.3 Encrypted handshake message：這一步對(duì)應(yīng)的是 Cleint 的 Finish 消息，client 將前面握手的消息生成摘要，再用協(xié)商好的會(huì)話秘鑰進(jìn)行加密，這是客戶端發(fā)出的第一條加密消息， 服務(wù)端接收后會(huì)用會(huì)話秘鑰解密，能解出來說明前面協(xié)商的秘鑰是一致的，至此客戶端的握手完成。

會(huì)話密鑰是用雙方協(xié)商的加密算法和三個(gè)隨機(jī)數(shù)：client random、server random、pre-master key 生成的。

6、服務(wù)器回應(yīng)

服務(wù)器使用自己的 CA證書私鑰對(duì) pre-master key 解密得到 pre-master，再計(jì)算出會(huì)話密鑰，隨后向客戶端發(fā)送以下信息：

6.1 Change Cipher Spec：加密通信算法改變通知，表示服務(wù)端隨后的信息都將用會(huì)話秘鑰加密通信。

6.2 Encrypted handshake message：這一步對(duì)應(yīng)的是 Server 的 Finish 消息，服務(wù)端會(huì)將握手過程消息生成摘要，然后再用會(huì)話密鑰加密，這是服務(wù)器發(fā)出的第一條加密消息，客戶端接收后會(huì)用會(huì)話密鑰解密，能解出來就說明協(xié)商成功。

7、TCP四次揮手

四次揮手過程描述
第一次揮手: 客戶端的應(yīng)用說要關(guān)閉連接，給服務(wù)端發(fā)送一個(gè)含fin標(biāo)志位的報(bào)文，客戶端狀態(tài)由established變?yōu)閒in-wait-1

第二次揮手: 服務(wù)端收到客戶端發(fā)來的fin報(bào)文，回復(fù)ack報(bào)文，告知服務(wù)端的應(yīng)用要關(guān)閉連接，服務(wù)端狀態(tài)由established變?yōu)閏lose-wait，而客戶端收到ack報(bào)文后，狀態(tài)由fin-wait-1變?yōu)閒in-wait-2

第三次揮手: 服務(wù)端應(yīng)用說可以關(guān)閉連接了，給客戶端發(fā)送fin報(bào)文，服務(wù)端狀態(tài)由close-wait變?yōu)閘ast-ack

第四次揮手: 客戶端收到服務(wù)端發(fā)來的fin報(bào)文，回復(fù)ack報(bào)文，客戶端狀態(tài)由fin-wait-2變?yōu)閠ime-wait，服務(wù)端收到ack報(bào)文后，直接關(guān)閉連接，狀態(tài)由last-ack變?yōu)閏losed

客戶端經(jīng)過兩次最大的報(bào)文存活時(shí)間后，關(guān)閉連接，狀態(tài)由time-wait變?yōu)閏losed

四次揮手原因
(1) 假設(shè)只有二次揮手
客戶端發(fā)送fin報(bào)文，服務(wù)端接收fin后，返回ack報(bào)文?？蛻舳私邮盏絘ck報(bào)文后，斷開連接。然而服務(wù)器還有沒有發(fā)送完成的報(bào)文，當(dāng)發(fā)送數(shù)據(jù)報(bào)文給客戶端，發(fā)現(xiàn)客戶端已經(jīng)斷開連接。比如說你在瀏覽器輸入一個(gè)地址后會(huì)跟服務(wù)端建立連接，服務(wù)端會(huì)根據(jù)TCP把數(shù)據(jù)分成很多的報(bào)文段一一地發(fā)送給客戶端，在沒有全部發(fā)送完成之前，客戶端在完成二次揮手就斷開連接，服務(wù)端還沒發(fā)送完的報(bào)文段就會(huì)拋客戶端失去連接的異常。

(2) 假設(shè)只有三次揮手， 服務(wù)端就不能及時(shí)地關(guān)閉連接，導(dǎo)致連接空閑一段時(shí)間，浪費(fèi)資源。

至此，整個(gè) SSL/TLS 的握手階段全部結(jié)束，TCP 四次揮手?jǐn)嚅_連接。

接下來，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的 HTTP 協(xié)議，只不過用會(huì)話秘鑰加密內(nèi)容文章來源地址http://www.zghlxwxcb.cn/news/detail-677282.html

到了這里，關(guān)于HTTPS連接建立過程的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！