前沿拓展：

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

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

HTTP與HTTPS介紹

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

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

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

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

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

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

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

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

4、http的連接很簡單，是無狀態(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，看不懂這里不要緊，只要把文章后面看完，再回過頭來看這里的內(nèi)容，就能恍然大悟了。

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

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

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

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

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

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

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

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

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

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

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

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

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

CA證書的申請及其使用過程

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

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

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

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

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

因為公匙加密的消息只有對應(yīng)的私匙才能解開，所以較大程度上保證了消息的來源性以及消息的準(zhǔn)確性和完整性。

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

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

非對稱加密的性能相對對稱加密來說會慢上幾倍甚至幾百倍，比較消耗系統(tǒng)資源。正是因為如此，https將兩種加密結(jié)合了起來。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

關(guān)于證書鏈

事實上，證書的驗證過程中還存在?個證書信任鏈的問題，因為我們向 CA 申請的證書?般不是根證書簽發(fā)的， ?是由中間證書簽發(fā)的，?如百度的證書，從下圖你可以看到，證書的層級有**：

對于這種**層級關(guān)系的證書的驗證過程如下：

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

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

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

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

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

SSL與TLS

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

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

SSL/TLS歷史

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

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

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

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

2006年和2008年，TLS進(jìn)行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是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é)議的基本過程（TLS1.2）

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

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

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

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

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

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

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

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

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

（4） 支持的壓縮方法。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

計算過程根據(jù)上面得到的三個隨機(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)：通過秘鑰交換算法 ECDHE 計算出的，我們叫它 pre_master。

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

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

（1）驗證客戶端證書有效性，本次不涉及

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

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

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

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

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

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

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

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

上述流程簡易版（不包含驗證客戶端證書）：

1. client –> server ClientHello

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

2. server–> client ServerHello

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

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é)束并驗證

7. server –> server ChangeCipherSpec

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

9. server–> client Finish

結(jié)束并驗證

圖片流程

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

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

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

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

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

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

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

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

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

　　1）更安全的MAC算法

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

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

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

1）對于消息認(rèn)證使用密鑰散列法：TLS 使用“消息認(rèn)證代碼的密鑰散列法”（HMAC），當(dāng)記錄在開放的網(wǎng)絡(luò)（如因特網(wǎng)）上傳送時，該代碼確保記錄不會被變更。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)的已完成消息驗證：TLS和SSLv3.0都對兩個端點(diǎn)提供已完成的消息，該消息認(rèn)證交換的消息沒有被變更。然而，TLS將此已完成消息基于PRF和HMAC值之上，這也比SSLv3.0更安全。

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

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

SSL/TLS 密碼套件

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

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

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

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

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

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

另外還有:

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

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

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

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

4、HTTPS降低用戶訪問速度（需多次握手）

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

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

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

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

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

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

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

以上圖片文字解釋來源：HTTP與HTTPS對訪問速度（性能）的影響 – 宋可欣 – 博客園

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

HTTPS的缺點(diǎn)

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

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

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

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

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

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

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

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

HTTPS連接大致可以劃分為兩個部分：第一個是建立連接時的非對稱加密握手，第二個是握手后的對稱加密報文傳輸。

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

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

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

驗證證書時訪問 CA 獲取 CRL 或者 OCSP；

非對稱加密解密處理“Pre-Master”。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使用ECDHE算法的TLS交換過程具有如下優(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)層面保證了“前向安全”。

拓展知識：

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

加我QQ 給你搞定

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

查看下引擎上面的人物** 看看上面的注冊角色打勾了沒有