前沿拓展：

版本服務(wù)器關(guān)閉連接

我剛剛解決這個(gè)問(wèn)題。我的原因可能是之前清理了一次以試試。望采納。

HTTP與HTTPS介紹

超文本傳輸協(xié)議HTTP協(xié)議被用于在Web瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息，HTTP協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務(wù)器之間的傳輸報(bào)文，就可以直接讀懂其中的信息，因此，HTTP協(xié)議不適合傳輸一些敏感信息，比如：信用**、密碼等支付信息。

為了解決HTTP協(xié)議的這一缺陷，需要使用另一種協(xié)議：安**接字層超文本傳輸協(xié)議HTTPS，為了數(shù)據(jù)傳輸?shù)陌踩?，HTTPS在HTTP的基礎(chǔ)上加入了SSL/TLS協(xié)議，SSL/TLS依靠證書來(lái)驗(yàn)證服務(wù)器的身份，并為瀏覽器和服務(wù)器之間的通信加密。

HTTPS協(xié)議是由SSL/TLS+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全

HTTPS協(xié)議的主要作用可以分為兩種：一種是建立一個(gè)信息安全通道，來(lái)保證數(shù)據(jù)傳輸?shù)陌踩?；另一種就是確認(rèn)網(wǎng)站的真實(shí)性。

HTTPS和HTTP的主要區(qū)別

1、https協(xié)議需要到CA申請(qǐng)證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用。

2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl/tls加密傳輸協(xié)議。

3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

4、http的連接很簡(jiǎn)單，是無(wú)狀態(tài)的；HTTPS協(xié)議是由SSL/TLS+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

HTTPS的主干層次介紹

這部分內(nèi)容作為前提點(diǎn)綴，如果你是初次了解HTTPS，看不懂這里不要緊，只要把文章后面看完，再回過(guò)頭來(lái)看這里的內(nèi)容，就能恍然大悟了。

第一層：HTTPS本質(zhì)上是為了實(shí)現(xiàn)加密通信，理論上，加密通信就是雙方都持有一個(gè)對(duì)稱加密的秘鑰，第二就可以安全通信了

但是，無(wú)論這個(gè)最初的秘鑰是由客戶端傳給服務(wù)端，還是服務(wù)端傳給客戶端，都是明文傳輸，中間人都可以知道。那就讓這個(gè)過(guò)程變成密文就好了唄，而且還得是中間人解不開的密文。

第二層：使用非對(duì)稱加密 加密客戶端與服務(wù)端協(xié)商生成對(duì)稱秘鑰之前各種鹽值、種子。

但是，在使用非對(duì)稱加密秘鑰之前，比如由服務(wù)端生成非對(duì)稱秘鑰，它需要將生成的公鑰給到客戶端，這個(gè)時(shí)候公鑰就會(huì)在網(wǎng)絡(luò)中明文傳輸，任何人都可以更改，會(huì)有中間人攻擊的問(wèn)題。因此，只能引入公信機(jī)構(gòu)CA，使我們傳輸自己的公鑰時(shí)可以保證不會(huì)被篡改！

第三層：服務(wù)端把自己的公鑰給 CA，讓 CA 用 CA 的私鑰加密，第二返回加密結(jié)果（可以用CA的公鑰解密，如果要篡改結(jié)果，必須再次用 CA 的私鑰加密，由于中間人沒(méi)法獲取私鑰，所以無(wú)法篡改）。

客戶端在使用HTTPS方式與Web服務(wù)器通信時(shí)的步驟

?。?）客戶使用https的URL訪問(wèn)Web服務(wù)器，要求與Web服務(wù)器建立SSL連接。

?。?）Web服務(wù)器收到客戶端請(qǐng)求后，會(huì)將網(wǎng)站的證書信息（證書中包含公鑰）傳送一份給客戶端。

　（3）客戶端的瀏覽器與Web服務(wù)器開始協(xié)商SSL/TLS連接的安全等級(jí)，也就是信息加密的等級(jí)。

?。?）客戶端的瀏覽器根據(jù)雙方同意的安全等級(jí)，建立會(huì)話密鑰，第二利用網(wǎng)站的公鑰將會(huì)話密鑰加密，并傳送給網(wǎng)站。

?。?）Web服務(wù)器利用自己的私鑰解密出會(huì)話密鑰。

?。?）Web服務(wù)器利用會(huì)話密鑰加密與客戶端之間的通信。

盡管HTTPS并非絕對(duì)安全，掌握根證書的機(jī)構(gòu)、掌握加密算法的組織同樣可以進(jìn)行中間人形式的攻擊，但HTTPS仍是現(xiàn)行架構(gòu)下最安全的解決方案，他大幅增加了中間人攻擊的成本

CA證書的申請(qǐng)及其使用過(guò)程

上面客戶端使用HTTPS與服務(wù)器通信中使用到了CA認(rèn)證，這里可能大家會(huì)問(wèn)為什么不直接使用非對(duì)稱加密的形式直接進(jìn)行，第一這里先介紹下非對(duì)稱加密。

非對(duì)稱加密：客戶端和服務(wù)端均擁有一個(gè)公有密匙和一個(gè)私有密匙。公有密匙可以對(duì)外暴露，而私有密匙只有自己可見(jiàn)。

使用公有密匙加密的消息，只有對(duì)應(yīng)的私有密匙才能解開。反過(guò)來(lái)，使用私有密匙加密的消息，只有公有密匙才能解開。這樣客戶端在發(fā)送消息前，先用服務(wù)器的公匙對(duì)消息進(jìn)行加密，服務(wù)器收到后再用自己的私匙進(jìn)行解密。

非對(duì)稱加密的優(yōu)點(diǎn)：

非對(duì)稱加密采用公有密匙和私有密匙的方式，解決了http中消息保密性問(wèn)題，而且使得私有密匙泄露的風(fēng)險(xiǎn)降低。

因?yàn)楣准用艿南⒅挥袑?duì)應(yīng)的私匙才能解開，所以較大程度上保證了消息的來(lái)源性以及消息的準(zhǔn)確性和完整性。

非對(duì)稱加密的缺點(diǎn)：

非對(duì)稱加密時(shí)需要使用到接收方的公匙對(duì)消息進(jìn)行加密，但是公匙不是保密的，任何人都可以拿到，中間人也可以。那么中間人可以做兩件事，第一件是中間人可以在客戶端與服務(wù)器交換公匙的時(shí)候，將客戶端的公匙替換成自己的。這樣服務(wù)器拿到的公匙將不是客戶端的，而是中間人的。服務(wù)器也無(wú)法判斷公匙來(lái)源的正確性。第二件是中間人可以不替換公匙，但是他可以截獲客戶端發(fā)來(lái)的消息，第二篡改，第二用服務(wù)器的公匙加密再發(fā)往服務(wù)器，服務(wù)器將收到錯(cuò)誤的消息。

非對(duì)稱加密的性能相對(duì)對(duì)稱加密來(lái)說(shuō)會(huì)慢上幾倍甚至幾百倍，比較消耗系統(tǒng)資源。正是因?yàn)槿绱?，https將兩種加密結(jié)合了起來(lái)。

為了應(yīng)對(duì)上面非對(duì)稱加密帶來(lái)的問(wèn)題，我們就引入了數(shù)字證書與數(shù)字簽名

CA 簽發(fā)證書的過(guò)程，如上圖左邊部分：

?先 CA 會(huì)把持有者的公鑰、?途、頒發(fā)者、有效時(shí)間等信息打成?個(gè)包，第二對(duì)這些信息進(jìn)? Hash 計(jì)算， 得到?個(gè) Hash 值；

第二 CA 會(huì)使???的私鑰將該 Hash 值加密，?成 Certificate Signature，也就是 CA 對(duì)證書做了簽名；

最后將 Certificate Signature 添加在?件證書上，形成數(shù)字證書；

客戶端校驗(yàn)服務(wù)端的數(shù)字證書的過(guò)程，如上圖右邊部分：

?先客戶端會(huì)使?同樣的 Hash 算法獲取該證書的 Hash 值 H1；

通常瀏覽器和**作系統(tǒng)中集成了 CA 的公鑰信息，瀏覽器收到證書后可以使? CA 的公鑰解密 Certificate Signature 內(nèi)容，得到?個(gè) Hash 值 H2 ；

最后?較 H1 和 H2，如果值相同，則為可信賴的證書，否則則認(rèn)為證書不可信。

故CA認(rèn)證介入我們的HTTPS連接的過(guò)程如下：

1、服務(wù)器擁有自己的私鑰與公鑰

2、服務(wù)器將公鑰交給CA認(rèn)證機(jī)構(gòu)，請(qǐng)求給予一份數(shù)字證書

3、CA認(rèn)證機(jī)構(gòu)生成數(shù)字證書，并頒發(fā)給服務(wù)器

4、服務(wù)器將帶有公鑰信息的數(shù)字證書發(fā)給客戶端

5、進(jìn)入客戶端生成對(duì)稱密鑰再進(jìn)行對(duì)接的過(guò)程……

關(guān)于證書鏈

事實(shí)上，證書的驗(yàn)證過(guò)程中還存在?個(gè)證書信任鏈的問(wèn)題，因?yàn)槲覀兿?CA 申請(qǐng)的證書?般不是根證書簽發(fā)的， ?是由中間證書簽發(fā)的，?如百度的證書，從下圖你可以看到，證書的層級(jí)有**：

對(duì)于這種**層級(jí)關(guān)系的證書的驗(yàn)證過(guò)程如下：

客戶端收到 baidu.com 的證書后，發(fā)現(xiàn)這個(gè)證書的簽發(fā)者不是根證書，就?法根據(jù)本地已有的根證書中的公鑰去驗(yàn)證 baidu.com 證書是否可信。于是，客戶端根據(jù) baidu.com 證書中的簽發(fā)者，找到該證書的頒發(fā)機(jī)構(gòu) 是 “GlobalSign Organization Validation CA – SHA256 – G2”，第二向 CA 請(qǐng)求該中間證書。

請(qǐng)求到證書后發(fā)現(xiàn) “GlobalSign Organization Validation CA – SHA256 – G2” 證書是由 “GlobalSign Root CA” 簽發(fā)的，由于 “GlobalSign Root CA” 沒(méi)有再上級(jí)簽發(fā)機(jī)構(gòu)，說(shuō)明它是根證書，也就是?簽證書。應(yīng)?軟件會(huì) 檢查此證書有否已預(yù)載于根證書清單上，如果有，則可以利?根證書中的公鑰去驗(yàn)證 “GlobalSign Organization Validation CA – SHA256 – G2” 證書，如果發(fā)現(xiàn)驗(yàn)證通過(guò)，就認(rèn)為該中間證書是可信的。

“GlobalSign Organization Validation CA – SHA256 – G2” 證書被信任后，可以使? “GlobalSign Organization Validation CA – SHA256 – G2” 證書中的公鑰去驗(yàn)證 baidu.com 證書的可信性，如果驗(yàn)證通過(guò)，就可以信任 baidu.com 證書。

在這四個(gè)步驟中，最開始客戶端只信任根證書 GlobalSign Root CA 證書的，第二 “GlobalSign Root CA” 證書信任 “GlobalSign Organization Validation CA – SHA256 – G2” 證書，? “GlobalSign Organization Validation CA – SHA256 – G2” 證書?信任 baidu.com 證書，于是客戶端也信任 baidu.com 證書。

總括來(lái)說(shuō)，由于?戶信任 GlobalSign，所以由 GlobalSign 所擔(dān)保的 baidu.com 可以被信任，另外由于?戶信任** 作系統(tǒng)或?yàn)g覽器的軟件商，所以由軟件商預(yù)載了根證書的 GlobalSign 都可被信任。

SSL與TLS

SSL：（Secure Socket Layer，安**接字層），位于可靠的面向連接的網(wǎng)絡(luò)層協(xié)議和應(yīng)用層協(xié)議之間的一種協(xié)議層。SSL通過(guò)互相認(rèn)證、使用數(shù)字簽名確保完整性、使用加密確保私密性，以實(shí)現(xiàn)客戶端和服務(wù)器之間的安全通訊。該協(xié)議由兩層組成：SSL記錄協(xié)議和SSL握手協(xié)議。

TLS：(Transport Layer Security，傳輸層安全協(xié)議)，用于兩個(gè)應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。該協(xié)議由兩層組成：TLS記錄協(xié)議和TLS握手協(xié)議。TLS是HTTP與TCP協(xié)議之間的一層，通常TLS發(fā)生在TCP三次握手之后，此時(shí)進(jìn)行TLS四次握手，第二再進(jìn)行HTTP通信

SSL/TLS歷史

1994年，NetScape公司設(shè)計(jì)了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布。

1995年，NetScape公司發(fā)布SSL 2.0版，很快發(fā)現(xiàn)有嚴(yán)重漏洞。

1996年，SSL 3.0版問(wèn)世，得到大規(guī)模應(yīng)用。

1999年，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司，發(fā)布了SSL的升級(jí)版TLS 1.0版。

2006年和2008年，TLS進(jìn)行了兩次升級(jí)，分別為TLS 1.1版和TLS 1.2版。最新的變動(dòng)是2011年TLS 1.2的修訂版，在2018年也發(fā)布了TLS1.3版本。

TLS 1.0通常被標(biāo)示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。

目前應(yīng)用的最廣泛的 TLS 是 1.2，而之前的協(xié)議（TLS1.1/1.0、SSLv3/v2）都已經(jīng)被認(rèn)為是不安全的了

SSL/TLS協(xié)議的基本過(guò)程（TLS1.2）

客戶端向服務(wù)器端索要并驗(yàn)證公鑰。

雙方協(xié)商生成"對(duì)話密鑰"。

雙方采用"對(duì)話密鑰"進(jìn)行加密通信。

上面過(guò)程的前兩步，又稱為"握手階段"（handshake）

下面是我們本次模擬訪問(wèn)https://www.baidu.com時(shí)抓的包，大家可以看到這里面涉及的流程邏輯

1 客戶端發(fā)出請(qǐng)求（ClientHello）

（1） 支持的協(xié)議版本，比如TLS 1.2版。

（2） 一個(gè)客戶端生成的隨機(jī)數(shù)1，稍后用于生成"對(duì)話密鑰"。

（3） 【支持的密碼套件】支持的加密方法，比如RSA公鑰加密。

（4） 支持的壓縮方法。

（5） 一個(gè)session id，標(biāo)識(shí)是否復(fù)用服務(wù)器之前的tls連接（需要服務(wù)器支持）

2 服務(wù)器回應(yīng)（SeverHello）

（1） 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.2版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信。

（2） 一個(gè)服務(wù)器生成的隨機(jī)數(shù)2，稍后用于生成"對(duì)話密鑰"。

（3） 【確認(rèn)密碼套件】確認(rèn)使用的加密方法，比如RSA公鑰加密，此時(shí)帶有公鑰信息。

（4） 一個(gè)session id（若同意復(fù)用連接）

3 服務(wù)器回應(yīng)（Server Certificate）

（1）服務(wù)器證書（該證書即包含服務(wù)器公鑰）。

4 服務(wù)器回應(yīng)（Server Key Exchange）

（1）服務(wù)器算法變更通知，服務(wù)端給客戶端一個(gè)用于 ECDHE 算法的公鑰

5 服務(wù)器回應(yīng)（Server CertificateRequest）

（1）請(qǐng)求客戶端證書，此案例中沒(méi)有，一般銀行等需要客戶端也加密的才有，比如 U 盾。

6 服務(wù)器回應(yīng)（Server ServerHelloDone）- 標(biāo)識(shí)著 serverHello 這個(gè)握手過(guò)程結(jié)束了。

7 客戶端回應(yīng)（Client Certificate）- 回應(yīng)客戶端證書，本案例不涉及

8 客戶端回應(yīng)（ClientKeyExchange）

（1）客戶端在驗(yàn)證完服務(wù)器的證書后，生成一個(gè)新的隨機(jī)數(shù)（pre_master），通過(guò)服務(wù)器的公鑰加密后發(fā)給服務(wù)器。

到這里，服務(wù)端與客戶端將 生成最終通信的對(duì)稱加密秘鑰：master_secret

計(jì)算過(guò)程根據(jù)上面得到的三個(gè)隨機(jī)數(shù)：

隨機(jī)數(shù) 1（客戶端隨機(jī)數(shù)）：在 ClientHello 消息里，由客戶端生成的隨機(jī)數(shù)1

隨機(jī)數(shù) 2（服務(wù)端隨機(jī)數(shù)）：在 ServerHello 消息里，由服務(wù)端生成的隨機(jī)數(shù)2

隨機(jī)數(shù) 3（pre_master)：通過(guò)秘鑰交換算法 ECDHE 計(jì)算出的，我們叫它 pre_master。

最終的對(duì)稱加密秘鑰 master_secret，就是根據(jù)這三個(gè)隨機(jī)數(shù)共同計(jì)算出來(lái)的。

9 客戶端回應(yīng)（Client CertificateVerif）

（1）驗(yàn)證客戶端證書有效性，本次不涉及

10 客戶端回應(yīng)（Client ChangeCipherSpec）

（1）秘鑰改變通知，此時(shí)客戶端已經(jīng)生成了 master_secret，之后的消息將都通過(guò) master secret 來(lái)加密。

11 客戶端回應(yīng)（Client Finish）

（1） 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來(lái)供服務(wù)器校驗(yàn)。

12 服務(wù)器回應(yīng)（Server ChangeCipherSpec）

（1）秘鑰改變通知，此時(shí)服務(wù)端也已經(jīng)生成了 master_secret 了，后面的通信都用此值加密。

13 服務(wù)器回應(yīng)（Server Finish）

（1）同 Client Finish，服務(wù)器端發(fā)送握手結(jié)束通知，同時(shí)會(huì)帶上前面所發(fā)內(nèi)容的hash簽名到客戶端，保證前面通信數(shù)據(jù)的正確性。

上述流程簡(jiǎn)易版（不包含驗(yàn)證客戶端證書）：

1. client –> server ClientHello

客戶端生成隨機(jī)數(shù)，并發(fā)送一組密碼學(xué)套件供服務(wù)端選

2. server–> client ServerHello

服務(wù)端生成隨機(jī)數(shù)，并從上述密碼學(xué)套件組里選一個(gè)

3. server–> client Certificate

服務(wù)端發(fā)給客戶端證書

4. server–> client ServerKeyExchange

服務(wù)端發(fā)給客戶端秘鑰交換算法所需的值

5. server–> client ServerHelloDone

服務(wù)端 hello 階段結(jié)束

6. client –> server ClientKeyExchange

客戶端發(fā)給服務(wù)端秘鑰交換算法所需的值pre_master

7. client –> server ChangeCipherSpec

客戶端告訴服務(wù)端，我已經(jīng)知道秘鑰了，之后的消息我就都加密發(fā)送了。

8. client –> server Finish

結(jié)束并驗(yàn)證

7. server –> server ChangeCipherSpec

服務(wù)端告訴客戶端，我已經(jīng)知道秘鑰了，之后的消息我就都加密發(fā)送了。

9. server–> client Finish

結(jié)束并驗(yàn)證

圖片流程

為什么一定要用三個(gè)隨機(jī)數(shù)，來(lái)生成"會(huì)話密鑰"呢？

"不管是客戶端還是服務(wù)器，都需要隨機(jī)數(shù)，這樣生成的密鑰才不會(huì)每次都一樣。由于SSL協(xié)議中證書是靜態(tài)的，因此十分有必要引入一種隨機(jī)因素來(lái)保證協(xié)商出來(lái)的密鑰的隨機(jī)性。

對(duì)于RSA密鑰交換算法來(lái)說(shuō)，pre-master-key本身就是一個(gè)隨機(jī)數(shù)，再加上hello消息中的隨機(jī)數(shù)，三個(gè)隨機(jī)數(shù)通過(guò)一個(gè)密鑰導(dǎo)出器最終導(dǎo)出一個(gè)對(duì)稱密鑰。

pre master的存在在于SSL協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)，如果隨機(jī)數(shù)不隨機(jī)，那么pre master secret就有可能被猜出來(lái)，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機(jī)因素，那么客戶端和服務(wù)器加上pre master secret三個(gè)隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了，一個(gè)偽隨機(jī)可能完全不隨機(jī)，可是是三個(gè)偽隨機(jī)就十分接近隨機(jī)了，每增加一個(gè)自由度，隨機(jī)性增加的可不是一。"

此外，如果前一步，服務(wù)器要求客戶端證書，客戶端會(huì)在這一步發(fā)送證書及相關(guān)信息。

以上介紹為TLS1.2的版本，其他TLS如1.0版本的流程會(huì)稍有不同，但大致邏輯是一樣的。

TLS 1.2 轉(zhuǎn)換流程邏輯也可以參考：26 | 信任始于握手：TLS1.2連接過(guò)程解析-極客時(shí)間

更新的 TLS 1.3也可以參考：27 | 更好更快的握手：TLS1.3特性解析-極客時(shí)間

TLS的主要目標(biāo)是使SSL更安全，并使協(xié)議的規(guī)范更精確和完善。TLS 在SSL v3.0 的基礎(chǔ)上，提供了以下增強(qiáng)內(nèi)容：

　　1）更安全的MAC算法

　　2）更嚴(yán)密的警報(bào)

　　3）“灰**域”規(guī)范的更明確的定義

TLS對(duì)于安全性的改進(jìn)點(diǎn)如下（了解即可）：

1）對(duì)于消息認(rèn)證使用密鑰散列法：TLS 使用“消息認(rèn)證代碼的密鑰散列法”（HMAC），當(dāng)記錄在開放的網(wǎng)絡(luò)（如因特網(wǎng)）上傳送時(shí)，該代碼確保記錄不會(huì)被變更。SSLv3.0還提供鍵控消息認(rèn)證，但HMAC比SSLv3.0使用的（消息認(rèn)證代碼）MAC 功能更安全。

2）增強(qiáng)的偽隨機(jī)功能（PRF）：PRF生成密鑰數(shù)據(jù)。在TLS中，HMAC定義PRF。PRF使用兩種散列算法保證其安全性。如果任一算法暴露了，只要第二種算法未暴露，則數(shù)據(jù)仍然是安全的。

3）改進(jìn)的已完成消息驗(yàn)證：TLS和SSLv3.0都對(duì)兩個(gè)端點(diǎn)提供已完成的消息，該消息認(rèn)證交換的消息沒(méi)有被變更。然而，TLS將此已完成消息基于PRF和HMAC值之上，這也比SSLv3.0更安全。

4）一致證書處理：與SSLv3.0不同，TLS試圖指定必須在TLS之間實(shí)現(xiàn)交換的證書類型。

5）特定警報(bào)消息：TLS提供更多的特定和附加警報(bào)，以指示任一會(huì)話端點(diǎn)檢測(cè)到的問(wèn)題。TLS還對(duì)何時(shí)應(yīng)該發(fā)送某些警報(bào)進(jìn)行記錄。

SSL/TLS 密碼套件

瀏覽器和服務(wù)器在使用 TLS 建立連接時(shí)需要選擇一組恰當(dāng)?shù)募用芩惴▉?lái)實(shí)現(xiàn)安全通信，這些算法的組合被稱為“密碼套件”（cipher suite，也叫加密套件）。上述Client/Server Hello過(guò)程中就涉及密碼套件的約定流程。

TLS 的密碼套件命名格式為：密鑰交換算法 + 簽名算法 + 對(duì)稱加密算法 + 摘要算法

如對(duì)于套件：“ECDHE-RSA-AES256-GCM-SHA384”，其解釋為：握手時(shí)使用 ECDHE 算法進(jìn)行密鑰交換，用 RSA 簽名和身份認(rèn)證，握手后的通信使用 AES 對(duì)稱算法，密鑰長(zhǎng)度 256 位，分組模式是 GCM，摘要算法 SHA384 用于消息認(rèn)證和產(chǎn)生隨機(jī)數(shù)。

HTTPS很安全，很古老也很成熟，為什么一直到今天我們還有66%的網(wǎng)站不支持HTTPS呢？

1、慢，HTTPS未經(jīng)任何優(yōu)化的情況下要比HTTP慢幾百毫秒以上，特別在移動(dòng)端可能要慢500毫秒以上，關(guān)于HTTPS慢和如何優(yōu)化已經(jīng)是一個(gè)非常系統(tǒng)和復(fù)雜的話題

2、貴，特別在計(jì)算性能和服務(wù)器成本方面。HTTPS為什么會(huì)增加服務(wù)器的成本？相信大家也都清楚HTTPS要額外計(jì)算，要頻繁地做加密和解密**作，幾乎每一個(gè)字節(jié)都需要做加解密，這就產(chǎn)生了服務(wù)器成本

另外還有:

1、大量的計(jì)算。SSL的每一個(gè)字節(jié)都涉及到較為復(fù)雜的計(jì)算。即使是clientHello，也需要在握手完成時(shí)做校驗(yàn)。

2、TLS協(xié)議的封裝和解析。HTTPS所有數(shù)據(jù)都是按照TLS record格式進(jìn)行封裝和解析的。

3、協(xié)議的網(wǎng)絡(luò)交互。從TLS的握手過(guò)程可以看出，即使不需要進(jìn)行任何計(jì)算，TLS的握手也需要至少1個(gè)RTT（round trip time)以上的網(wǎng)絡(luò)交互。

RTT(Round-Trip Time): 往返時(shí)延。在計(jì)算機(jī)網(wǎng)絡(luò)中它是一個(gè)重要的性能指標(biāo)，表示從發(fā)送端發(fā)送數(shù)據(jù)開始，到發(fā)送端收到來(lái)自接收端的確認(rèn)（接收端收到數(shù)據(jù)后便立即發(fā)送確認(rèn)），總共經(jīng)歷的時(shí)延。

4、HTTPS降低用戶訪問(wèn)速度（需多次握手）

5、網(wǎng)站改用 HTTPS 以后，由 HTTP 跳轉(zhuǎn)到 HTTPS 的方式增加了用戶訪問(wèn)耗時(shí)（多數(shù)網(wǎng)站采用 301、302 跳轉(zhuǎn)）

6、HTTPS 涉及到的安全算**消耗 CPU 資源，需要增加服務(wù)器資源（https 訪問(wèn)過(guò)程需要加解密）

HTTPS涉及的計(jì)算環(huán)節(jié)

1、非對(duì)稱密鑰交換。比如RSA, Diffie-Hellman, ECDHE.這類算法的主要作用就是根據(jù)客戶端和服務(wù)端不對(duì)稱的信息，經(jīng)過(guò)高強(qiáng)度的密鑰生成算法，生成對(duì)稱密鑰，用于加解密后續(xù)應(yīng)用消息。

2、對(duì)稱加解密。服務(wù)端使用密鑰A對(duì)響應(yīng)內(nèi)容進(jìn)行加密，客戶端使用相同的密鑰A對(duì)加密內(nèi)容進(jìn)行解密，反之亦然。

3、消息一致性驗(yàn)證。每一段加密的內(nèi)容都會(huì)附加一個(gè)MAC消息，即消息認(rèn)證碼。簡(jiǎn)單地說(shuō)就是對(duì)內(nèi)容進(jìn)行的安全哈希計(jì)算，接收方需要校驗(yàn)MAC碼。

4、證書簽名校驗(yàn)。這個(gè)階段主要發(fā)生在客戶端校驗(yàn)服務(wù)端證書身份時(shí)，需要對(duì)證書簽名進(jìn)行校驗(yàn)，確保證書的真實(shí)性。

以上圖片文字解釋來(lái)源：HTTP與HTTPS對(duì)訪問(wèn)速度（性能）的影響 – 宋可欣 – 博客園

OCSP(Online Certificate Status Protocol，在線證書狀態(tài)協(xié)議)

HTTPS的缺點(diǎn)

雖然說(shuō)HTTPS有很大的優(yōu)勢(shì)，但其相對(duì)來(lái)說(shuō)，還是存在不足之處的：

（1）HTTPS協(xié)議握手階段比較費(fèi)時(shí)，會(huì)使頁(yè)面的加載時(shí)間延長(zhǎng)近50%，增加10%到20%的耗電；

（2）HTTPS連接緩存不如HTTP高效，會(huì)增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會(huì)因此而受到影響；

（3）SSL證書需要錢，功能越強(qiáng)大的證書費(fèi)用越高，個(gè)人網(wǎng)站、小網(wǎng)站沒(méi)有必要一般不會(huì)用。

（4）SSL證書通常需要綁定IP，不能在同一IP上綁定多個(gè)域名，IPv4資源不可能支撐這個(gè)消耗。

（5）HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。最關(guān)鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國(guó)家可以控制CA根證書的情況下，中間人攻擊一樣可行。

實(shí)踐中建議保留http。所以我們?cè)谇袚Q的時(shí)候可以做http和https的兼容，具體實(shí)現(xiàn)方式是，去掉頁(yè)面鏈接中的http頭部，這樣可以自動(dòng)匹配http頭和https頭。例如：將http://www.baidu.com改為//www.baidu.com。第二當(dāng)用戶從http的入口進(jìn)入訪問(wèn)頁(yè)面時(shí)，頁(yè)面就是http，如果用戶是從https的入口進(jìn)入訪問(wèn)頁(yè)面，頁(yè)面即使https的

如何優(yōu)化HTTPS的速度

HTTPS連接大致可以劃分為兩個(gè)部分：第一個(gè)是建立連接時(shí)的非對(duì)稱加密握手，第二個(gè)是握手后的對(duì)稱加密報(bào)文傳輸。

由于目前流行的 AES、ChaCha20 性能都很好，還有硬件優(yōu)化，報(bào)文傳輸?shù)男阅軗p耗可以說(shuō)是非常地小，小到幾乎可以忽略不計(jì)了。所以，通常所說(shuō)的“HTTPS 連接慢”指的就是剛開始建立連接的那段時(shí)間。

在 TCP 建連之后，正式數(shù)據(jù)傳輸之前，HTTPS 比 HTTP 增加了一個(gè) TLS 握手的步驟，這個(gè)步驟最長(zhǎng)可以花費(fèi)兩個(gè)消息往返，也就是 2-RTT（TLS1.3只需1-RTT）。而且在握手消息的網(wǎng)絡(luò)耗時(shí)之外，還會(huì)有其他的一些“**”消耗，比如：

產(chǎn)生用于密鑰交換的臨時(shí)公私鑰對(duì)（ECDHE）；

驗(yàn)證證書時(shí)訪問(wèn) CA 獲取 CRL 或者 OCSP；

非對(duì)稱加密解密處理“Pre-Master”。

1、HSTS重定向技術(shù)

HSTS（HTTP Strict Transport Security，HTTP 嚴(yán)格傳輸安全）技術(shù)，啟用HSTS后，將保證瀏覽器始終連接到網(wǎng)站的 HTTPS 加密版本。這相當(dāng)于告訴瀏覽器：我這個(gè)網(wǎng)站必須嚴(yán)格使用 HTTPS 協(xié)議，在半年之內(nèi)（182.5 天）都不允許用 HTTP，你以后就自己做轉(zhuǎn)換吧，不要再來(lái)麻煩我了。

1. 用戶在瀏覽器里輸入 HTTP 協(xié)議進(jìn)行訪問(wèn)時(shí)，瀏覽器會(huì)自動(dòng)將 HTTP 轉(zhuǎn)換為 HTTPS 進(jìn)行訪問(wèn)，確保用戶訪問(wèn)安全；

2. 省去301跳轉(zhuǎn)的出現(xiàn)，縮短訪問(wèn)時(shí)間；

3. 能阻止基于 SSL Strip 的中間人攻擊，萬(wàn)一證書有錯(cuò)誤，則顯示錯(cuò)誤，用戶不能回避警告，從而能夠更加有效安全的保障用戶的訪問(wèn)。

2、TLS握手優(yōu)化

在傳輸應(yīng)用數(shù)據(jù)之前，客戶端必須與服務(wù)端協(xié)商密鑰、加密算法等信息，服務(wù)端還要把自己的證書發(fā)給客戶端表明其身份，這些環(huán)節(jié)構(gòu)成 TLS 握手過(guò)程。

使用 ECDHE 橢圓曲線密碼套件，可以節(jié)約帶寬和計(jì)算量，還能實(shí)現(xiàn)“False Start”，采用 False Start （搶先開始）技術(shù)，瀏覽器在與服務(wù)器完成 TLS 握手前，就開始發(fā)送請(qǐng)求數(shù)據(jù)，服務(wù)器在收到這些數(shù)據(jù)后，完成 TLS 握手的同時(shí)，開始發(fā)送響應(yīng)數(shù)據(jù)。

開啟 False Start 功能后，數(shù)據(jù)傳輸時(shí)間將進(jìn)一步縮短。

3、Session Identifier（會(huì)話標(biāo)識(shí)符）復(fù)用

如果用戶的一個(gè)業(yè)務(wù)請(qǐng)求包含了多條的加密流，客戶端與服務(wù)器將會(huì)反復(fù)握手，必定會(huì)導(dǎo)致更多的時(shí)間損耗?；蛘吣承┨厥馇闆r導(dǎo)致了對(duì)話突然中斷，雙方就需要重新握手，增加了用戶訪問(wèn)時(shí)間。

（1）服務(wù)器為每一次的會(huì)話都生成并記錄一個(gè) ID 號(hào)，第二發(fā)送給客戶端；

（2）如果客戶端發(fā)起重新連接，則只要向服務(wù)器發(fā)送該 ID 號(hào)；

（3）服務(wù)器收到客戶端發(fā)來(lái)的 ID 號(hào)，第二查找自己的會(huì)話記錄，匹配 ID 之后，雙方就可以重新使用之前的對(duì)稱加密秘鑰進(jìn)行數(shù)據(jù)加密傳輸，而不必重新生成，減少交互時(shí)間（只用一個(gè)消息往返就可以建立安全連接）。

但它也有缺點(diǎn)，服務(wù)器必須保存每一個(gè)客戶端的會(huì)話數(shù)據(jù)，對(duì)于擁有百萬(wàn)、千萬(wàn)級(jí)別用戶的網(wǎng)站來(lái)說(shuō)存儲(chǔ)量就成了大問(wèn)題，加重了服務(wù)器的負(fù)擔(dān)。于是又出現(xiàn)了第二種“Session Ticket”的方案。

它有點(diǎn)類似 HTTP 的 Cookie，存儲(chǔ)的責(zé)任由服務(wù)器轉(zhuǎn)移到了客戶端，服務(wù)器加密會(huì)話信息，用“New Session Ticket”消息發(fā)給客戶端，讓客戶端保存。重連的時(shí)候，客戶端使用擴(kuò)展“session_ticket”發(fā)送“Ticket”而不是“Session ID”，服務(wù)器解密后驗(yàn)證有效期，就可以恢復(fù)會(huì)話，開始加密通信。不過(guò)“Session Ticket”方案需要使用一個(gè)固定的密鑰文件（ticket_key）來(lái)加密 Ticket，為了防止密鑰被破解，保證“前向安全”，密鑰文件需要定期輪換，比如設(shè)置為一小時(shí)或者一天。

4、開啟OSCP Stapling（OSCP裝訂），提高TLS握手效率

客戶端的證書驗(yàn)證其實(shí)是個(gè)很復(fù)雜的**作，除了要公鑰解密驗(yàn)證多個(gè)證書簽名外，因?yàn)樽C書還有可能會(huì)被撤銷失效，客戶端有時(shí)還會(huì)再去訪問(wèn) CA，下載 CRL （Certificate revocation list，證書吊銷列表，用于確認(rèn)證書是否有效，體積較大，現(xiàn)基本不用）或者 OCSP 數(shù)據(jù)，這又會(huì)產(chǎn)生 DNS 查詢、建立連接、收發(fā)數(shù)據(jù)等一系列網(wǎng)絡(luò)通信，增加好幾個(gè) RTT。

采用OCSP Stapling ，提升 HTTPS 性能。服務(wù)端主動(dòng)獲取 OCSP 查詢結(jié)果并隨著證書一起發(fā)送給客戶端，從而客戶端可直接通過(guò) Web Server 驗(yàn)證證書，提高 TLS 握手效率。

服務(wù)器模擬瀏覽器向 CA 發(fā)起請(qǐng)求，并將帶有 CA 機(jī)構(gòu)簽名的 OCSP 響應(yīng)保存到本地，第二在與客戶端握手階段，將 OCSP 響應(yīng)下發(fā)給瀏覽器，省去瀏覽器的在線驗(yàn)證過(guò)程。由于瀏覽器不需要直接向 CA 站點(diǎn)查詢證書狀態(tài)，這個(gè)功能對(duì)訪問(wèn)速度的提升非常明顯。

5、完全前向加密PFS，保護(hù)用戶數(shù)據(jù)，預(yù)防私鑰泄漏

非對(duì)稱加密算法 RSA，包含了公鑰、私鑰，其中私鑰是保密不對(duì)外公開的，由于此算法既可以用于加密也可以用于簽名，所以用途甚廣，但是還是會(huì)遇到一些問(wèn)題：

（1） 假如我是一名黑客，雖然現(xiàn)在我不知道私鑰，但是我可以先把客戶端與服務(wù)器之前的傳輸數(shù)據(jù)（已加密）全部保存下來(lái)

（2）如果某一天，服務(wù)器維護(hù)人員不小心把私鑰泄露了，或者服務(wù)器被我攻破獲取到了私鑰

（3）那我就可以利用這個(gè)私鑰，破解掉之前已被我保存的數(shù)據(jù)，從中獲取有用的信息，即所謂的“今日截獲，明日破解”。

所以為了防止上述現(xiàn)象發(fā)生，我們必須保護(hù)好自己的私鑰。

如果私鑰確實(shí)被泄漏了，那我們改如何補(bǔ)救呢？那就需要PFS（perfect forward secrecy）完全前向保密功能，此功能用于客戶端與服務(wù)器交換對(duì)稱密鑰，起到前向保密的作用，也即就算私鑰被泄漏，黑客也無(wú)法破解先前已加密的數(shù)據(jù)。維基解釋是：長(zhǎng)期使用的主密鑰泄漏不會(huì)導(dǎo)致過(guò)去的會(huì)話密鑰泄漏

實(shí)現(xiàn)此功能需要服務(wù)器支持以下算法和簽名組合：

（1）ECDHE 密鑰交換、RSA 簽名；

（2）ECDHE 密鑰交換、ECDSA 簽名；

ECDHE 算法在每次握手時(shí)都會(huì)生成一對(duì)臨時(shí)的公鑰和私鑰，每次通信的密鑰對(duì)都是不同的，也就是“一次一密”，即使黑客花大力氣破解了這一次的會(huì)話密鑰，也只是這次通信被攻擊，之前的歷史消息不會(huì)受到影響，仍然是安全的。

使用ECDHE算法的TLS交換過(guò)程具有如下優(yōu)點(diǎn)：運(yùn)算速度快，安全性高，還支持“False Start”，能夠把握手的消息往返由 2-RTT 減少到 1-RTT

所以現(xiàn)在主流的服務(wù)器和瀏覽器在握手階段都已經(jīng)不再使用 RSA，改用 ECDHE，而 TLS1.3 在協(xié)議里明確廢除 RSA 和 DH 則在標(biāo)準(zhǔn)層面保證了“前向安全”。

拓展知識(shí)：

版本服務(wù)器關(guān)閉連接

加我QQ 給你搞定

版本服務(wù)器關(guān)閉連接

查看下引擎上面的人物** 看看上面的注冊(cè)角色打勾了沒(méi)有