1，摘要

本文配圖介紹HTTPS協(xié)議的層級(jí)結(jié)構(gòu)呀打，訪問(wèn)原理榜贴，交互過(guò)程豌研，說(shuō)明如何解決存在的中間人問(wèn)題。

2唬党，內(nèi)容

2.1 HTTPS的協(xié)議棧層級(jí)

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure鹃共，超文本傳輸安全協(xié)議），是以安全為目標(biāo)的HTTP通道驶拱，簡(jiǎn)單講是HTTP的安全版霜浴。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL蓝纲，因此加密的詳細(xì)內(nèi)容就需要SSL阴孟。 它是一個(gè)URI scheme（抽象標(biāo)識(shí)符體系），句法類同http:體系税迷。用于安全的HTTP數(shù)據(jù)傳輸永丝。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默認(rèn)端口及一個(gè)加密/身份驗(yàn)證層（在HTTP與TCP之間）箭养。

為鼓勵(lì)全球網(wǎng)站的 HTTPS 實(shí)現(xiàn)光绕，一些互聯(lián)網(wǎng)公司都提出了自己的要求：
1）Google 已調(diào)整搜索引擎算法，讓采用 HTTPS 的網(wǎng)站在搜索中排名更靠前闲礼；
2）從 2017 年開(kāi)始读宙，Chrome 瀏覽器已把采用 HTTP 協(xié)議的網(wǎng)站標(biāo)記為不安全網(wǎng)站；
3）蘋果要求 2017 年 App Store 中的所有應(yīng)用都必須使用 HTTPS 加密連接懈词；
4）當(dāng)前國(guó)內(nèi)炒的很火熱的微信小程序也要求必須使用 HTTPS 協(xié)議蛇耀；
5）新一代的 HTTP/2 協(xié)議的支持需以 HTTPS 為基礎(chǔ)。

因此坎弯，作為程序員來(lái)說(shuō)纺涤，HTTPS知識(shí)必須掌握译暂。

如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS

SSL（Secure Socket Layer，安全套接字層）：1994年為 Netscape 所研發(fā)撩炊，SSL 協(xié)議位于 TCP/IP 協(xié)議與各種應(yīng)用層協(xié)議之間外永，為數(shù)據(jù)通訊提供安全支持。

TLS（Transport Layer Security拧咳，傳輸層安全）：其前身是 SSL伯顶，它最初的幾個(gè)版本（SSL 1.0、SSL 2.0骆膝、SSL 3.0）由網(wǎng)景公司開(kāi)發(fā)祭衩，1999年從 3.1 開(kāi)始被 IETF 標(biāo)準(zhǔn)化并改名，發(fā)展至今已經(jīng)有 TLS 1.0阅签、TLS 1.1掐暮、TLS 1.2 三個(gè)版本。SSL3.0和TLS1.0由于存在安全漏洞政钟，已經(jīng)很少被使用到路克。TLS 1.3 改動(dòng)會(huì)比較大，目前還在草案階段养交，目前使用最廣泛的是TLS 1.1精算、TLS 1.2。

2.2 TCP的3次握手和HTTP 訪問(wèn)過(guò)程

2.2.1 TCP的3次握手

客戶端輸入U(xiǎn)RL回車碎连，DNS解析域名得到服務(wù)器的IP地址殖妇，服務(wù)器在80端口監(jiān)聽(tīng)客戶端請(qǐng)求，端口通過(guò)TCP/IP協(xié)議（可以通過(guò)Socket實(shí)現(xiàn)）建立連接破花。HTTP屬于TCP/IP模型中的運(yùn)用層協(xié)議谦趣，所以通信的過(guò)程其實(shí)是對(duì)應(yīng)數(shù)據(jù)的入棧和出棧。

報(bào)文從運(yùn)用層傳送到運(yùn)輸層座每，運(yùn)輸層通過(guò)TCP三次握手和服務(wù)器建立連接前鹅，四次揮手釋放連接。

分析下這個(gè)三次握手的過(guò)程：
第一次握手：主機(jī)A發(fā)送位碼為syn＝1,隨機(jī)產(chǎn)生seq number= X的數(shù)據(jù)包到服務(wù)器峭梳，主機(jī)B由SYN=1知道舰绘，A要求建立聯(lián)機(jī)；
第二次握手：主機(jī)B收到請(qǐng)求后要確認(rèn)聯(lián)機(jī)信息葱椭，向A發(fā)送syn=1捂寿，ack number= X+1 ，隨機(jī)產(chǎn)生seq=Y的包
第三次握手：主機(jī)A收到后檢查ack number是否正確孵运，即第一次發(fā)送的X+1,以及位碼SYN是否為1秦陋；若正確，主機(jī)A會(huì)再發(fā)送ack number=(Y+1), Seq = z治笨，主機(jī)B收到后確認(rèn)seq值與ack=1則連接建立成功驳概。
完成三次握手赤嚼，主機(jī)A與主機(jī)B開(kāi)始傳送數(shù)據(jù)。

2.2.2 HTTP 訪問(wèn)過(guò)程

抓包如下：

如上圖所示顺又，HTTP請(qǐng)求過(guò)程中更卒，客戶端與服務(wù)器之間沒(méi)有任何身份確認(rèn)的過(guò)程，數(shù)據(jù)全部明文傳輸稚照，“裸奔”在互聯(lián)網(wǎng)上蹂空，所以很容易遭到黑客的攻擊，如下：

image

可以看到果录，客戶端發(fā)出的請(qǐng)求很容易被黑客截獲腌闯，如果此時(shí)黑客冒充服務(wù)器，則其可返回任意信息給客戶端雕憔，而不被客戶端察覺(jué)，所以我們經(jīng)常會(huì)聽(tīng)到一詞“劫持”糖声。所以 HTTP 傳輸面臨的風(fēng)險(xiǎn)有：
（1） 竊聽(tīng)風(fēng)險(xiǎn)：黑客可以獲知通信內(nèi)容斤彼。
（2） 篡改風(fēng)險(xiǎn)：黑客可以修改通信內(nèi)容。
（3） 冒充風(fēng)險(xiǎn)：黑客可以冒充他人身份參與通信蘸泻。

2.3 安全通信三原則和https的設(shè)計(jì)思路

2.3.1 確保安全通信的三個(gè)原則

A.數(shù)據(jù)內(nèi)容的加密
這個(gè)很好理解是吧琉苇，敏感信息肯定要加密的，明文傳輸?shù)扔谧詺⒃檬２贿^(guò)多解釋了并扇。
B.通訊雙方的身份校驗(yàn)
這個(gè)很多人不理解，這是啥意思抡诞，按道理說(shuō)我們用非對(duì)稱加密應(yīng)該就完美了啊穷蛹。但是謹(jǐn)記我們的數(shù)據(jù)包不是從A直接到B的。
中間要經(jīng)過(guò)無(wú)數(shù)次的路由器轉(zhuǎn)發(fā)等等昼汗，這個(gè)中間一旦有人截獲了我們的數(shù)據(jù)包肴熏，換成自己的數(shù)據(jù)包，就很危險(xiǎn)了顷窒。
所以我們還需要一種機(jī)制能校驗(yàn)通訊雙方的身份蛙吏。確保我是在和我老婆說(shuō)話 而不是在我和丈母娘說(shuō)話。
C.數(shù)據(jù)內(nèi)容的完整性
這個(gè)也不是很容易理解鞋吉，按道理說(shuō)TCP是能保證數(shù)據(jù)有序完整的到達(dá)對(duì)方的鸦做。但是不要忘記中間我們經(jīng)過(guò)的無(wú)數(shù)次路由器轉(zhuǎn)發(fā)，
可能被劫持谓着，被劫持以后可能會(huì)對(duì)數(shù)據(jù)包進(jìn)行篡改泼诱，這個(gè)時(shí)候我們需要一種機(jī)制保護(hù)我們的數(shù)據(jù)不被篡改，即使被篡改也能被我們察覺(jué)赊锚，確保我對(duì)我老婆寫的信能完整的讓我老婆看到坷檩，而不是只看到一半却音。

2.3.2 https的設(shè)計(jì)思路

根據(jù)前面我們闡述的加密算法和安全通信三原則，為了保證我們的通信能夠安全進(jìn)行矢炼，可以試想出一種流程來(lái)保證通信安全：

• 服務(wù)器為每個(gè)客戶端生成一個(gè)公鑰系瓢，將公鑰發(fā)送給客戶端；
• 客戶端選擇一個(gè)加密算法句灌，然后用公鑰加密以后發(fā)送給服務(wù)器夷陋；
• 服務(wù)器收到這個(gè)公鑰加密后的算法以后拿自己的私鑰解密，然后就知道這個(gè)加密算法是哪個(gè)了胰锌。今后就一直用這個(gè)算法通信骗绕；

目前來(lái)看，這個(gè)思路是不是很完美资昧。公鑰即使被中間人截獲以后也沒(méi)用酬土，因?yàn)槟玫焦€也解密不出來(lái)到底雙方是用哪種算法加密的。
但有個(gè)重大缺陷：
中間人可以將服務(wù)器發(fā)送的公鑰包進(jìn)行掉包格带，客戶端怎么知道這個(gè)公鑰是真的服務(wù)器發(fā)送的還是假的中間人給的非法公鑰呢撤缴？
可以看這張圖，基本上中間人攻擊就是這個(gè)圖所示的意思叽唱。

那有沒(méi)有一種方式既可以安全的獲取公鑰屈呕，又能防止黑客冒充呢？ 那就需要用到終極武器了：SSL 證書申購(gòu)了棺亭。

具體步驟說(shuō)明：
如上圖所示虎眨，在第 ② 步時(shí)服務(wù)器發(fā)送了一個(gè)SSL證書給客戶端，SSL 證書中包含的具體內(nèi)容有：
（1）證書的發(fā)布機(jī)構(gòu)CA
（2）證書的有效期
（3）公鑰
（4）證書所有者
（5）簽名
………
客戶端在接受到服務(wù)端發(fā)來(lái)的SSL證書時(shí)镶摘，會(huì)對(duì)證書的真?zhèn)芜M(jìn)行校驗(yàn)嗽桩，以瀏覽器為例說(shuō)明如下：
（1）首先瀏覽器讀取證書中的證書所有者、有效期等信息進(jìn)行一一校驗(yàn)凄敢；
（2）瀏覽器開(kāi)始查找操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu)CA涤躲，與服務(wù)器發(fā)來(lái)的證書中的頒發(fā)者CA比對(duì)，用于校驗(yàn)證書是否為合法機(jī)構(gòu)頒發(fā)贡未；
（3）如果找不到种樱，瀏覽器就會(huì)報(bào)錯(cuò)，說(shuō)明服務(wù)器發(fā)來(lái)的證書是不可信任的俊卤；
（4）如果找到嫩挤，那么瀏覽器就會(huì)從操作系統(tǒng)中取出 頒發(fā)者CA 的公鑰，然后對(duì)服務(wù)器發(fā)來(lái)的證書里面的簽名進(jìn)行解密消恍；
（5）瀏覽器使用相同的hash算法計(jì)算出服務(wù)器發(fā)來(lái)的證書的hash值岂昭，將這個(gè)計(jì)算的hash值與證書中簽名做對(duì)比；
（6）對(duì)比結(jié)果一致狠怨，則證明服務(wù)器發(fā)來(lái)的證書合法约啊，沒(méi)有被冒充邑遏；
（7）此時(shí)瀏覽器就可以讀取證書中的公鑰，用于后續(xù)加密了恰矩；

所以通過(guò)發(fā)送SSL證書的形式记盒，既解決了公鑰獲取問(wèn)題，又解決了黑客冒充問(wèn)題外傅，一箭雙雕纪吮，HTTPS加密過(guò)程也就此形成。

所以相比HTTP萎胰，HTTPS 傳輸更加安全：
（1） 所有信息都是加密傳播碾盟，黑客無(wú)法竊聽(tīng)。
（2） 具有校驗(yàn)機(jī)制技竟，一旦被篡改冰肴，通信雙方會(huì)立刻發(fā)現(xiàn)。
（3） 配備身份證書榔组，防止身份被冒充熙尉。

2.3.3 加密知識(shí)普及

1、對(duì)稱加密
有流式瓷患、分組兩種，加密和解密都是使用的同一個(gè)密鑰遣妥。
例如：DES擅编、AES-GCM、ChaCha20-Poly1305等箫踩。

【戲說(shuō)】
對(duì)稱加密的一方（比如小紅）用秘鑰 K 給文本 M 加密爱态；另一方（比如小明）用 同一個(gè)秘鑰解密：

小紅 : C = E(M, K)
小明 : M = D(C, K)

這有一個(gè)問(wèn)題：當(dāng)一方生成了秘鑰 K 之后得把 K 分享給另一方。但是穿越 Sin City 的道路危險(xiǎn)中途很可能有人竊聽(tīng)到 K境钟，竊聽(tīng)者就可以假扮雙方中的任何一 方與另一方通信锦担。這叫中間人攻擊。

2慨削、非對(duì)稱加密
加密使用的密鑰和解密使用的密鑰是不相同的洞渔，分別稱為：公鑰、私鑰缚态，公鑰和算法都是公開(kāi)的磁椒，私鑰是保密的。非對(duì)稱加密算法性能較低玫芦，但是安全性超強(qiáng)浆熔，由于其加密特性，非對(duì)稱加密算法能加密的數(shù)據(jù)長(zhǎng)度也是有限的桥帆。
例如：RSA医增、DSA慎皱、ECDSA、 DH叶骨、ECDHE茫多。

【戲說(shuō)】
非對(duì)稱加密利用成對(duì)的兩個(gè)秘鑰：K1 和 K2。小紅用其中一個(gè)加密文本邓萨，小明可 以用另一個(gè)解密文本地梨。比如，小紅用 K1 加密缔恳，小明用 K2 解密：

小紅 : C = E(M, K1)
小明 : M = D(C, K2)

這樣一來(lái)宝剖，雙方中的一方（比如小紅）可以生成 K1和K2，然后把其中一個(gè)秘鑰 （比如K1）私藏歉甚，稱為私鑰万细；另一個(gè)（比如K2）公開(kāi)，稱為公鑰纸泄。另一 方（比如小明）得到公鑰之后赖钞，雙方就可以通信。

然而聘裁，中間人可能在小明獲取公鑰時(shí)截獲消息雪营，然后自己弄一對(duì)秘鑰（κ1, κ2），然后 告訴小明說(shuō) κ2 是小紅的公鑰衡便。這樣中間人每次可以用截獲的 K2 解密小紅發(fā)給 小明的文本（甚至可能修改文本）献起，再用 κ1 加密了發(fā)出去；小明用 κ2 解密接收镣陕。

3谴餐、哈希算法
將任意長(zhǎng)度的信息轉(zhuǎn)換為較短的固定長(zhǎng)度的值，通常其長(zhǎng)度要比信息小得多呆抑，且算法不可逆岂嗓。
例如：MD5、SHA-1鹊碍、SHA-2厌殉、SHA-256 等。

4侈咕、數(shù)字簽名
數(shù)字簽名技術(shù)是將摘要信息用發(fā)送者的私鑰加密年枕，與原文一起傳送給接收者。接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息乎完，然后用HASH函數(shù)對(duì)收到的原文產(chǎn)生一個(gè)摘要信息熏兄，與解密的摘要信息對(duì)比。如果相同，則說(shuō)明收到的信息是完整的摩桶，在傳輸過(guò)程中沒(méi)有被修改桥状，否則說(shuō)明信息被修改過(guò)，因此數(shù)字簽名能夠驗(yàn)證信息的完整性硝清。
數(shù)字簽名是個(gè)加密的過(guò)程辅斟，數(shù)字簽名驗(yàn)證是個(gè)解密的過(guò)程。
普通數(shù)字簽名算法有RSA芦拿、ElGamal士飒、Fiat-Shamir、Guillou- Quisquarter蔗崎、Schnorr酵幕、Ong-Schnorr-Shamir數(shù)字簽名算法、Des/DSA,橢圓曲線數(shù)字簽名算法和有限自動(dòng)機(jī)數(shù)字簽名算法等缓苛。

HTTPS使用CA證書的傳輸方式就是使用了數(shù)字簽名芳撒，非對(duì)稱加密，對(duì)稱加密等混合加密技術(shù)未桥。

數(shù)字簽名的做法是：

• 小紅把自己的公鑰和ID（身份證號(hào)碼笔刹，或者域名）合為身份證申請(qǐng)（certificate signing request，CSR）冬耿，小紅把CSR發(fā)給一個(gè)德高望重的人（被稱為 certificate authority舌菜，CA），比如小亮亦镶。
• 小亮用自己的私鑰加密小紅的 CSR日月，得到的密文被稱為數(shù)字簽名（digital signature）。
• 小亮把 signature 和 CSR 的明文合在一起稱為 CA簽署的身份證（CA signed certificate染乌，CRT）山孔，發(fā)給小紅懂讯。

小紅：CSR = 小紅公鑰+小紅域名
     signature = E(CSR, 小亮的私鑰)
     CRT = CSR + signature

每當(dāng)其他人（比如小明）找小紅聊天（建立HTTPS連接）的時(shí)候荷憋，小紅出示自己的小亮簽署的身份證。 拿到這個(gè)身份證的人褐望，只要他是相信小亮的——在自己機(jī)器上安裝了小亮的身份證勒庄，就可以從小亮的身份證中的小亮的CSR里提取小亮的公鑰；
然后用小亮的公鑰解密小紅的身份證中小亮的signature瘫里，得到一個(gè)小紅的CSR实蔽；
如果這個(gè)CSR'和小紅身份證中的CSR明文一致，則說(shuō)明“這個(gè)小紅的身份證是小亮確認(rèn)過(guò)并且簽名的”谨读。

小明：小亮的公鑰 = 小亮的CRT.CSR.小亮的公鑰
     CSR' = D(CRT.signature, 小亮的公鑰)
     if CSR' == CRT.CSR then OK

2.4 HTTPS真實(shí)交互消息過(guò)程

2.4.1 HTTPS交互消息

說(shuō)明：
（1）看藍(lán)色的部分是tcp鏈接局装。所以https的加密層也是在tcp之上的。

（2）客戶端首先發(fā)起clientHello消息。包含一個(gè)客戶端隨機(jī)生成的random1 數(shù)字铐尚，客戶端支持的加密算法拨脉，以及SSL信息。

（3）服務(wù)器收到客戶端的clientHello消息以后宣增，取出客戶端法發(fā)來(lái)的random1數(shù)字玫膀，并且取出客戶端發(fā)來(lái)的支持的加密算法，
然后選出一個(gè)加密算法爹脾，并生成一個(gè)隨機(jī)數(shù)random2帖旨，發(fā)送給客戶端serverhello讓客戶端對(duì)服務(wù)器進(jìn)行身份校驗(yàn),服務(wù)端通過(guò)將自己的公鑰通過(guò)數(shù)字證書的方式發(fā)送給客戶端。

（4）客戶端收到服務(wù)端傳來(lái)的證書后灵妨，先從 CA 驗(yàn)證該證書的合法性解阅，驗(yàn)證通過(guò)后取出證書中的服務(wù)端公鑰，再生成一個(gè)隨機(jī)數(shù) Random3闷串，再用服務(wù)端公鑰非對(duì)稱加密 Random3 生成 PreMaster Key瓮钥。并將PreMaster Key發(fā)送到服務(wù)端。

（5）服務(wù)端通過(guò)私鑰將PreMaster Key解密獲取到Random3,此時(shí)客戶端和服務(wù)器都持有三個(gè)隨機(jī)數(shù)Random1 Random2 Random3,雙方在通過(guò)這三個(gè)隨即書生成一個(gè)對(duì)稱加密的密鑰.雙方根據(jù)這三個(gè)隨即數(shù)經(jīng)過(guò)相同的算法生成一個(gè)密鑰,而以后應(yīng)用層傳輸?shù)臄?shù)據(jù)都使用這套密鑰進(jìn)行加密碉熄。
Change Cipher Spec Finished:告訴客戶端以后的通訊都使用這一套密鑰來(lái)進(jìn)行。

（6）最后ApplicationData 全部使用對(duì)稱加密的原因就是非對(duì)稱加密太卡肋拔，對(duì)稱加密不影響性能锈津。所以實(shí)際上也看的出來(lái)，HTTPS的真正目的就是保證對(duì)稱加密的 密鑰不被破解凉蜂，不被替換琼梆，不被中間人攻擊，如果發(fā)生了上述情況窿吩，那么HTTPS的加密層也能獲知茎杂，避免發(fā)生事故。

2.4.2 用WireShark還原一次HTTPS的交互過(guò)程

目標(biāo)訪問(wèn)地址就用github吧纫雁。 抓出來(lái)是這樣的煌往。

注意看tlsv1的就可以了這個(gè)就是加密層。下面就來(lái)逐步分析：
(1) ClientHello (line-2330)

（2）severHello (line-2380)

注意到這里服務(wù)器和客戶端就有2個(gè)隨機(jī)數(shù)了轧邪。并且加密算法也確定了刽脖。

（3）Certificate / severHelloDone(line 2435)

這部分主要是發(fā)送證書信息的 點(diǎn)開(kāi)以后 證書的詳細(xì)信息都能看到。另外serverhellodone的意思就是服務(wù)器的工作都完畢了忌愚。

（4）Client key exchange / ChangeCipherSpec (line-2449)

可以看出來(lái)這里一共有三個(gè)步驟曲管，我們來(lái)依次分析 這三次動(dòng)作都做了什么:

• Client Key Exchange

服務(wù)器收到這個(gè)random3的加密信息以后，用自己的私鑰解密硕糊，這樣服務(wù)器和客戶端就共同擁有了random 1院水，2腊徙，3這3組隨機(jī)數(shù)，然后用這三組數(shù)據(jù)生成一個(gè)密鑰檬某，這個(gè)密鑰就是后面我們applicationdata交互時(shí)使用的對(duì)稱加密的密鑰了昧穿。

• ChangeCipherSpec

（5）Change Cipher Spec Finished /new session ticket(line 2926)

解釋參考圖片描述。

這個(gè)session ticket就是服務(wù)器最后一步的時(shí)候傳給客戶端的一個(gè)數(shù)據(jù)橙喘。
這個(gè)加密數(shù)據(jù)客戶端收到以后就可以保存下來(lái)时鸵，這樣下一次再請(qǐng)求https的時(shí)候，就可以把這個(gè)session ticket發(fā)過(guò)去厅瞎，這樣可以省很多握手的時(shí)間和資源消耗饰潜。（前面我們分析的其實(shí)已經(jīng)相當(dāng)復(fù)雜了，尤其是非對(duì)稱加密對(duì)服務(wù)端的資源消耗相當(dāng)之大）,實(shí)際上對(duì)于多數(shù)瀏覽器來(lái)說(shuō)和簸，指向同一個(gè)域名的https連接彭雾，我們都會(huì)有意識(shí)的讓第一個(gè)https連接完成握手之后再連接第n個(gè) https。因?yàn)檫@樣后續(xù)的https 就可以攜帶相關(guān)信息锁保，可以省很多資源這個(gè)ticket實(shí)際上就有點(diǎn)類似cookie薯酝。
在筆者的這次訪問(wèn)chrome-gitub的過(guò)程中，瀏覽器并沒(méi)有使用ticket技術(shù)而是使用的seession id技術(shù)：

sessionid 實(shí)際上作用和ticket差不多爽柒，但是sessionid 無(wú)法做到服務(wù)器之間同步吴菠，畢竟id 存在服務(wù)器內(nèi)存中，負(fù)載均衡帶來(lái)的狀態(tài)機(jī)同步是一個(gè)大問(wèn)題浩村。

（6）Application Data (line-2964)

2.5 CA證書是收費(fèi)的啊做葵，我不想交錢咋辦呢?

可以自己制作證書，然后把這個(gè)證書的公鑰放在客戶端（例如app的安裝目錄下）心墅，這樣app只要使用自己的證書公鑰即可解密了酿矢，不需要使用系統(tǒng)的。但是這樣帶來(lái)的問(wèn)題是怎燥，如果有人獲取到了你這個(gè)公鑰證書咋辦瘫筐？
數(shù)字簽名認(rèn)證算法即可保證此類問(wèn)題，其實(shí)簡(jiǎn)單來(lái)說(shuō)就是服務(wù)器和客戶端事先約定好一種加密規(guī)則即可铐姚，就可以得知是否被篡改策肝。
這部分由于不是重點(diǎn)，暫時(shí)不講的太細(xì)谦屑，只要知道有這么個(gè)事即可驳糯。實(shí)際上你弄懂整個(gè)https以后這個(gè)地方就自然而然也能想明白了篇梭。

參考《螞蟻區(qū)塊鏈第9課 SSL/TLS工作原理及在螞蟻BAAS中的應(yīng)用》可了解SSL/TLS的原理和在螞蟻區(qū)塊鏈的應(yīng)用氢橙。

3，參考

（1）HTTP和HTTPS協(xié)議恬偷，看一篇就夠了
https://blog.csdn.net/xiaoming100001/article/details/81109617

（2）深入理解HTTPS協(xié)議【優(yōu)質(zhì)】
https://juejin.im/post/5a2fbe1b51882507ae25f991

（3）HTTPS系列干貨（一）：HTTPS 原理詳解
https://zhuanlan.zhihu.com/p/27395037

（4）HTTP協(xié)議入門教程悍手，一文就夠了！
http://www.reibang.com/p/083f992d0ee3