前沿拓展：

版本服務器關閉連接

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

HTTP與HTTPS介紹

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

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

HTTPS協(xié)議是由SSL/TLS+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網絡協(xié)議，要比http協(xié)議安全

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

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

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

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

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

4、http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL/TLS+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網絡協(xié)議，比http協(xié)議安全。

HTTPS的主干層次介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

非對稱加密的缺點：

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

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

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

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

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

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

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

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

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

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

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

故CA認證介入我們的HTTPS連接的過程如下：

1、服務器擁有自己的私鑰與公鑰

2、服務器將公鑰交給CA認證機構，請求給予一份數(shù)字證書

3、CA認證機構生成數(shù)字證書，并頒發(fā)給服務器

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

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

關于證書鏈

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

對于這種**層級關系的證書的驗證過程如下：

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

請求到證書后發(fā)現(xiàn) “GlobalSign Organization Validation CA – SHA256 – G2” 證書是由 “GlobalSign Root CA” 簽發(fā)的，由于 “GlobalSign Root CA” 沒有再上級簽發(fā)機構，說明它是根證書，也就是?簽證書。應?軟件會 檢查此證書有否已預載于根證書清單上，如果有，則可以利?根證書中的公鑰去驗證 “GlobalSign Organization Validation CA – SHA256 – G2” 證書，如果發(fā)現(xià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 所擔保的 baidu.com 可以被信任，另外由于?戶信任** 作系統(tǒng)或瀏覽器的軟件商，所以由軟件商預載了根證書的 GlobalSign 都可被信任。

SSL與TLS

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

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

SSL/TLS歷史

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

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

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

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

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

TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。

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

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

客戶端向服務器端索要并驗證公鑰。

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

雙方采用"對話密鑰"進行加密通信。

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

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

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

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

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

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

（4） 支持的壓縮方法。

（5） 一個session id，標識是否復用服務器之前的tls連接（需要服務器支持）

2 服務器回應（SeverHello）

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

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

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

（4） 一個session id（若同意復用連接）

3 服務器回應（Server Certificate）

（1）服務器證書（該證書即包含服務器公鑰）。

4 服務器回應（Server Key Exchange）

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

5 服務器回應（Server CertificateRequest）

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

6 服務器回應（Server ServerHelloDone）- 標識著 serverHello 這個握手過程結束了。

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

8 客戶端回應（ClientKeyExchange）

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

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

計算過程根據(jù)上面得到的三個隨機數(shù)：

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

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

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

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

9 客戶端回應（Client CertificateVerif）

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

10 客戶端回應（Client ChangeCipherSpec）

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

11 客戶端回應（Client Finish）

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

12 服務器回應（Server ChangeCipherSpec）

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

13 服務器回應（Server Finish）

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

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

1. client –> server ClientHello

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

2. server–> client ServerHello

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

3. server–> client Certificate

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

4. server–> client ServerKeyExchange

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

5. server–> client ServerHelloDone

服務端 hello 階段結束

6. client –> server ClientKeyExchange

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

7. client –> server ChangeCipherSpec

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

8. client –> server Finish

結束并驗證

7. server –> server ChangeCipherSpec

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

9. server–> client Finish

結束并驗證

圖片流程

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

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

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

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

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

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

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

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

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

　　1）更安全的MAC算法

　　2）更嚴密的警報

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

TLS對于安全性的改進點如下（了解即可）：

1）對于消息認證使用密鑰散列法：TLS 使用“消息認證代碼的密鑰散列法”（HMAC），當記錄在開放的網絡（如因特網）上傳送時，該代碼確保記錄不會被變更。SSLv3.0還提供鍵控消息認證，但HMAC比SSLv3.0使用的（消息認證代碼）MAC 功能更安全。

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

3）改進的已完成消息驗證：TLS和SSLv3.0都對兩個端點提供已完成的消息，該消息認證交換的消息沒有被變更。然而，TLS將此已完成消息基于PRF和HMAC值之上，這也比SSLv3.0更安全。

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

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

SSL/TLS 密碼套件

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

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

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

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

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

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

另外還有:

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

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

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

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

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

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

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

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

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

2、對稱加解密。服務端使用密鑰A對響應內容進行加密，客戶端使用相同的密鑰A對加密內容進行解密，反之亦然。

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

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

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

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

HTTPS的缺點

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

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

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

（3）SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用。

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

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

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

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

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

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

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

產生用于密鑰交換的臨時公私鑰對（ECDHE）；

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

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

1、HSTS重定向技術

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

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

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

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

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

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

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

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

3、Session Identifier（會話標識符）復用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

拓展知識：

版本服務器關閉連接

加我QQ 給你搞定

版本服務器關閉連接

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