HTTP與https介紹
超文本傳輸協議HTTP協議被用於在Web瀏覽器和網站伺服器之間傳遞信息，HTTP協議以明文方式發送內容，不提供任何方式的數據加密，如果攻擊者截取了Web瀏覽器和網站伺服器之間的傳輸報文，就可以直接讀懂其中的信息，因此，HTTP協議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。
為了解決HTTP協議的這一缺陷，需要使用另一種協議：安全套接字層超文本傳輸協議HTTPS，為了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL/TLS協議，SSL/tls依靠證書來驗證伺服器的身份，並為瀏覽器和伺服器之間的通信加密。
HTTPS協議是由SSL/TLS+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全
HTTPS協議的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數據傳輸的安全；另一種就是確認網站的真實性。
HTTPS和HTTP的主要區別
1、https協議需要到CA申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl/tls加密傳輸協議。
3、http和https使用的是完全不同的連接方式，用的埠也不一樣，前者是80，後者是443。
4、http的連接很簡單，是無狀態的；HTTPS協議是由SSL/TLS+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
HTTPS的主幹層次介紹
這部分內容作為前提點綴，如果你是初次了解HTTPS，看不懂這裡不要緊，只要把文章後面看完，再回過頭來看這裡的內容，就能恍然大悟了。
第一層：HTTPS本質上是為了實現加密通信，理論上，加密通信就是雙方都持有一個對稱加密的秘鑰，然後就可以安全通信了
但是，無論這個最初的秘鑰是由客戶端傳給服務端，還是服務端傳給客戶端，都是明文傳輸，中間人都可以知道。那就讓這個過程變成密文就好了唄，而且還得是中間人解不開的密文。
第二層：使用非對稱加密 加密客戶端與服務端協商生成對稱秘鑰之前各種鹽值、種子。
但是，在使用非對稱加密秘鑰之前，比如由服務端生成非對稱秘鑰，它需要將生成的公鑰給到客戶端，這個時候公鑰就會在網絡中明文傳輸，任何人都可以更改，會有中間人攻擊的問題。因此，只能引入公信機構CA，使我們傳輸自己的公鑰時可以保證不會被篡改！
第三層：服務端把自己的公鑰給 CA，讓 CA 用 CA 的私鑰加密，然後返回加密結果（可以用CA的公鑰解密，如果要篡改結果，必須再次用 CA 的私鑰加密，由於中間人沒法獲取私鑰，所以無法篡改）。
客戶端在使用HTTPS方式與Web伺服器通信時的步驟
（1）客戶使用https的URL訪問Web伺服器，要求與Web伺服器建立SSL連接。
（2）Web伺服器收到客戶端請求後，會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。
（3）客戶端的瀏覽器與Web伺服器開始協商SSL/TLS連接的安全等級，也就是信息加密的等級。
（4）客戶端的瀏覽器根據雙方同意的安全等級，建立會話密鑰，然後利用網站的公鑰將會話密鑰加密，並傳送給網站。
（5）Web伺服器利用自己的私鑰解密出會話密鑰。
（6）Web伺服器利用會話密鑰加密與客戶端之間的通信。
儘管HTTPS並非絕對安全，掌握根證書的機構、掌握加密算法的組織同樣可以進行中間人形式的攻擊，但HTTPS仍是現行架構下最安全的解決方案，他大幅增加了中間人攻擊的成本
CA證書的申請及其使用過程
上面客戶端使用HTTPS與伺服器通信中使用到了CA認證，這裡可能大家會問為什麼不直接使用非對稱加密的形式直接進行，首先這裡先介紹下非對稱加密。
非對稱加密：客戶端和服務端均擁有一個公有密匙和一個私有密匙。公有密匙可以對外暴露，而私有密匙只有自己可見。
使用公有密匙加密的消息，只有對應的私有密匙才能解開。反過來，使用私有密匙加密的消息，只有公有密匙才能解開。這樣客戶端在發送消息前，先用伺服器的公匙對消息進行加密，伺服器收到後再用自己的私匙進行解密。
非對稱加密的優點：
非對稱加密採用公有密匙和私有密匙的方式，解決了http中消息保密性問題，而且使得私有密匙泄露的風險降低。
因為公匙加密的消息只有對應的私匙才能解開，所以較大程度上保證了消息的來源性以及消息的準確性和完整性。
非對稱加密的缺點：
非對稱加密時需要使用到接收方的公匙對消息進行加密，但是公匙不是保密的，任何人都可以拿到，中間人也可以。那麼中間人可以做兩件事，第一件是中間人可以在客戶端與伺服器交換公匙的時候，將客戶端的公匙替換成自己的。這樣伺服器拿到的公匙將不是客戶端的，而是中間人的。伺服器也無法判斷公匙來源的正確性。第二件是中間人可以不替換公匙，但是他可以截獲客戶端發來的消息，然後篡改，然後用伺服器的公匙加密再發往伺服器，伺服器將收到錯誤的消息。
非對稱加密的性能相對對稱加密來說會慢上幾倍甚至幾百倍，比較消耗系統資源。正是因為如此，https將兩種加密結合了起來。
為了應對上面非對稱加密帶來的問題，我們就引入了數字證書與數字簽名
CA 簽發證書的過程，如上圖左邊部分：
⾸先 CA 會把持有者的公鑰、⽤途、頒發者、有效時間等信息打成⼀個包，然後對這些信息進⾏ Hash 計算， 得到⼀個 Hash 值；
然後 CA 會使⽤⾃⼰的私鑰將該 Hash 值加密，⽣成 Certificate Signature，也就是 CA 對證書做了簽名；
最後將 Certificate Signature 添加在⽂件證書上，形成數字證書；
客戶端校驗服務端的數字證書的過程，如上圖右邊部分：
⾸先客戶端會使⽤同樣的 Hash 算法獲取該證書的 Hash 值 H1；
通常瀏覽器和作業系統中集成了 CA 的公鑰信息，瀏覽器收到證書後可以使⽤ CA 的公鑰解密 Certificate Signature 內容，得到⼀個 Hash 值 H2 ；
最後⽐較 H1 和 H2，如果值相同，則為可信賴的證書，否則則認為證書不可信。
故CA認證介入我們的HTTPS連接的過程如下：
1、伺服器擁有自己的私鑰與公鑰
2、伺服器將公鑰交給CA認證機構，請求給予一份數字證書
3、CA認證機構生成數字證書，並頒發給伺服器
4、伺服器將帶有公鑰信息的數字證書發給客戶端
5、進入客戶端生成對稱密鑰再進行對接的過程......
關於證書鏈
事實上，證書的驗證過程中還存在⼀個證書信任鏈的問題，因為我們向 CA 申請的證書⼀般不是根證書籤發的， ⽽是由中間證書籤發的，⽐如百度的證書，從下圖你可以看到，證書的層級有三級：
對於這種三級層級關係的證書的驗證過程如下：
客戶端收到 baidu.com 的證書後，發現這個證書的簽發者不是根證書，就⽆法根據本地已有的根證書中的公鑰去驗證 baidu.com 證書是否可信。於是，客戶端根據 baidu.com 證書中的簽發者，找到該證書的頒發機構 是 「GlobalSign Organization Validation CA - SHA256 - G2」，然後向 CA 請求該中間證書。
請求到證書後發現 「GlobalSign Organization Validation CA - SHA256 - G2」 證書是由 「GlobalSign Root CA」 簽發的，由於 「GlobalSign Root CA」 沒有再上級簽發機構，說明它是根證書，也就是⾃簽證書。應⽤軟體會 檢查此證書有否已預載於根證書清單上，如果有，則可以利⽤根證書中的公鑰去驗證 「GlobalSign Organization Validation CA - SHA256 - G2」 證書，如果發現驗證通過，就認為該中間證書是可信的。
「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 可以被信任，另外由於⽤戶信任操 作系統或瀏覽器的軟體商，所以由軟體商預載了根證書的 GlobalSign 都可被信任。
SSL與TLS
SSL：（Secure Socket Layer，安全套接字層），位於可靠的面向連接的網絡層協議和應用層協議之間的一種協議層。SSL通過互相認證、使用數字簽名確保完整性、使用加密確保私密性，以實現客戶端和伺服器之間的安全通訊。該協議由兩層組成：SSL記錄協議和SSL握手協議。
TLS：(Transport Layer Security，傳輸層安全協議)，用於兩個應用程式之間提供保密性和數據完整性。該協議由兩層組成：TLS記錄協議和TLS握手協議。TLS是HTTP與TCP協議之間的一層，通常TLS發生在TCP三次握手之後，此時進行TLS四次握手，然後再進行HTTP通信
SSL/TLS歷史
1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，但是未發布。
1995年，NetScape公司發布SSL 2.0版，很快發現有嚴重漏洞。
1996年，SSL 3.0版問世，得到大規模應用。
1999年，網際網路標準化組織ISOC接替NetScape公司，發布了SSL的升級版TLS 1.0版。
2006年和2008年，TLS進行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版，在2018年也發布了TLS1.3版本。
TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。
目前應用的最廣泛的 TLS 是 1.2，而之前的協議（TLS1.1/1.0、SSLv3/v2）都已經被認為是不安全的了
SSL/TLS協議的基本過程（TLS1.2）
客戶端向伺服器端索要並驗證公鑰。
雙方協商生成"對話密鑰"。
雙方採用"對話密鑰"進行加密通信。
上面過程的前兩步，又稱為"握手階段"（handshake）
下面是我們本次模擬訪問https://www.baidu.com時抓的包，大家可以看到這裡面涉及的流程邏輯
1 客戶端發出請求（ClientHello）
（1） 支持的協議版本，比如TLS 1.2版。
（2） 一個客戶端生成的隨機數1，稍後用於生成"對話密鑰"。
（3） 【支持的密碼套件】支持的加密方法，比如RSA公鑰加密。
（4） 支持的壓縮方法。
（5） 一個session id，標識是否復用伺服器之前的tls連接（需要伺服器支持）
2 伺服器回應（SeverHello）
（1） 確認使用的加密通信協議版本，比如TLS 1.2版本。如果瀏覽器與伺服器支持的版本不一致，伺服器關閉加密通信。
（2） 一個伺服器生成的隨機數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）客戶端在驗證完伺服器的證書後，生成一個新的隨機數（pre_master），通過伺服器的公鑰加密後發給伺服器。
到這裡，服務端與客戶端將 生成最終通信的對稱加密秘鑰：master_secret
計算過程根據上面得到的三個隨機數：
隨機數 1（客戶端隨機數）：在 ClientHello 消息里，由客戶端生成的隨機數1
隨機數 2（服務端隨機數）：在 ServerHello 消息里，由服務端生成的隨機數2
隨機數 3（pre_master)：通過秘鑰交換算法 ECDHE 計算出的，我們叫它 pre_master。
最終的對稱加密秘鑰 master_secret，就是根據這三個隨機數共同計算出來的。
9 客戶端回應（Client CertificateVerif）
（1）驗證客戶端證書有效性，本次不涉及
10 客戶端回應（Client ChangeCipherSpec）
（1）秘鑰改變通知，此時客戶端已經生成了 master_secret，之後的消息將都通過 master secret 來加密。
11 客戶端回應（Client Finish）
（1） 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供伺服器校驗。
12 伺服器回應（Server ChangeCipherSpec）
（1）秘鑰改變通知，此時服務端也已經生成了 master_secret 了，後面的通信都用此值加密。
13 伺服器回應（Server Finish）
（1）同 Client Finish，伺服器端發送握手結束通知，同時會帶上前面所發內容的hash簽名到客戶端，保證前面通信數據的正確性。
上述流程簡易版（不包含驗證客戶端證書）：
1. client --> server clientHello
客戶端生成隨機數，並發送一組密碼學套件供服務端選
2. server--> client ServerHello
服務端生成隨機數，並從上述密碼學套件組裡選一個
3. server--> client Certificate
服務端發給客戶端證書
4. server--> client ServerKeyExchange
服務端發給客戶端秘鑰交換算法所需的值
5. server--> client ServerHelloDone
服務端 hello 階段結束
6. client --> server ClientKeyExchange
客戶端發給服務端秘鑰交換算法所需的值pre_master
7. client --> server ChangeCipherSpec
客戶端告訴服務端，我已經知道秘鑰了，之後的消息我就都加密發送了。
8. client --> server Finish
結束並驗證
7. server --> server ChangeCipherSpec
服務端告訴客戶端，我已經知道秘鑰了，之後的消息我就都加密發送了。
9. server--> client Finish
結束並驗證
圖片流程
為什麼一定要用三個隨機數，來生成"會話密鑰"呢？
"不管是客戶端還是伺服器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由於SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
對於RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數，再加上hello消息中的隨機數，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在於SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那麼pre master secret就有可能被猜出來，那麼僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素，那麼客戶端和伺服器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。"
此外，如果前一步，伺服器要求客戶端證書，客戶端會在這一步發送證書及相關信息。
以上介紹為TLS1.2的版本，其他TLS如1.0版本的流程會稍有不同，但大致邏輯是一樣的。
TLS 1.2 轉換流程邏輯也可以參考：26 | 信任始於握手：TLS1.2連接過程解析-極客時間
更新的 TLS 1.3也可以參考：27 | 更好更快的握手：TLS1.3特性解析-極客時間
TLS的主要目標是使SSL更安全，並使協議的規範更精確和完善。TLS 在SSL v3.0 的基礎上，提供了以下增強內容：
1）更安全的MAC算法
2）更嚴密的警報
3）「灰色區域」規範的更明確的定義
TLS對於安全性的改進點如下（了解即可）：
1）對於消息認證使用密鑰散列法：TLS 使用「消息認證代碼的密鑰散列法」（HMAC），當記錄在開放的網絡（如網際網路）上傳送時，該代碼確保記錄不會被變更。SSLv3.0還提供鍵控消息認證，但HMAC比SSLv3.0使用的（消息認證代碼）MAC 功能更安全。
2）增強的偽隨機功能（PRF）：PRF生成密鑰數據。在TLS中，HMAC定義PRF。PRF使用兩種散列算法保證其安全性。如果任一算法暴露了，只要第二種算法未暴露，則數據仍然是安全的。
3）改進的已完成消息驗證：TLS和SSLv3.0都對兩個端點提供已完成的消息，該消息認證交換的消息沒有被變更。然而，TLS將此已完成消息基於PRF和HMAC值之上，這也比SSLv3.0更安全。
4）一致證書處理：與SSLv3.0不同，TLS試圖指定必須在TLS之間實現交換的證書類型。
5）特定警報消息：TLS提供更多的特定和附加警報，以指示任一會話端點檢測到的問題。TLS還對何時應該發送某些警報進行記錄。
SSL/TLS 密碼套件
瀏覽器和伺服器在使用 TLS 建立連接時需要選擇一組恰當的加密算法來實現安全通信，這些算法的組合被稱為「密碼套件」（cipher suite，也叫加密套件）。上述Client/Server Hello過程中就涉及密碼套件的約定流程。
TLS 的密碼套件命名格式為：密鑰交換算法 + 簽名算法 + 對稱加密算法 + 摘要算法
如對於套件：「ECDHE-RSA-AES256-GCM-SHA384」，其解釋為：握手時使用 ECDHE 算法進行密鑰交換，用 RSA 簽名和身份認證，握手後的通信使用 AES 對稱算法，密鑰長度 256 位，分組模式是 GCM，摘要算法 SHA384 用於消息認證和產生隨機數。
HTTPS很安全，很古老也很成熟，為什麼一直到今天我們還有66%的網站不支持HTTPS呢？
1、慢，HTTPS未經任何優化的情況下要比HTTP慢幾百毫秒以上，特別在移動端可能要慢500毫秒以上，關於HTTPS慢和如何優化已經是一個非常系統和複雜的話題
2、貴，特別在計算性能和伺服器成本方面。HTTPS為什麼會增加伺服器的成本？相信大家也都清楚HTTPS要額外計算，要頻繁地做加密和解密操作，幾乎每一個字節都需要做加解密，這就產生了伺服器成本
另外還有:
1、大量的計算。SSL的每一個字節都涉及到較為複雜的計算。即使是clientHello，也需要在握手完成時做校驗。
2、TLS協議的封裝和解析。HTTPS所有數據都是按照TLS record格式進行封裝和解析的。
3、協議的網絡交互。從TLS的握手過程可以看出，即使不需要進行任何計算，TLS的握手也需要至少1個RTT（round trip time)以上的網絡交互。
RTT(Round-Trip Time): 往返時延。在計算機網絡中它是一個重要的性能指標，表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據後便立即發送確認），總共經歷的時延。
4、HTTPS降低用戶訪問速度（需多次握手）
5、網站改用 HTTPS 以後，由 HTTP 跳轉到 HTTPS 的方式增加了用戶訪問耗時（多數網站採用 301、302 跳轉）
6、HTTPS 涉及到的安全算法會消耗 CPU 資源，需要增加伺服器資源（https 訪問過程需要加解密）
HTTPS涉及的計算環節
1、非對稱密鑰交換。比如RSA, Diffie-Hellman, ECDHE.這類算法的主要作用就是根據客戶端和服務端不對稱的信息，經過高強度的密鑰生成算法，生成對稱密鑰，用於加解密後續應用消息。
2、對稱加解密。服務端使用密鑰A對響應內容進行加密，客戶端使用相同的密鑰A對加密內容進行解密，反之亦然。
3、消息一致性驗證。每一段加密的內容都會附加一個MAC消息，即消息認證碼。簡單地說就是對內容進行的安全哈希計算，接收方需要校驗MAC碼。
4、證書籤名校驗。這個階段主要發生在客戶端校驗服務端證書身份時，需要對證書籤名進行校驗，確保證書的真實性。
以上圖片文字解釋來源：HTTP與HTTPS對訪問速度（性能）的影響 - 宋可欣 - 博客園
OCSP(Online Certificate Status Protocol，在線證書狀態協議)
HTTPS的缺點
雖然說HTTPS有很大的優勢，但其相對來說，還是存在不足之處的：
（1）HTTPS協議握手階段比較費時，會使頁面的加載時間延長近50%，增加10%到20%的耗電；
（2）HTTPS連接緩存不如HTTP高效，會增加數據開銷和功耗，甚至已有的安全措施也會因此而受到影響；
（3）SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用。
（4）SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。
（5）HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、伺服器劫持等方面幾乎起不到什麼作用。最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。
實踐中建議保留http。所以我們在切換的時候可以做http和https的兼容，具體實現方式是，去掉頁面連結中的http頭部，這樣可以自動匹配http頭和https頭。例如：將http://www.baidu.com改為//www.baidu.com。然後當用戶從http的入口進入訪問頁面時，頁面就是http，如果用戶是從https的入口進入訪問頁面，頁面即使https的
如何優化HTTPS的速度
HTTPS連接大致可以劃分為兩個部分：第一個是建立連接時的非對稱加密握手，第二個是握手後的對稱加密報文傳輸。
由於目前流行的 AES、ChaCha20 性能都很好，還有硬體優化，報文傳輸的性能損耗可以說是非常地小，小到幾乎可以忽略不計了。所以，通常所說的「HTTPS 連接慢」指的就是剛開始建立連接的那段時間。
在 TCP 建連之後，正式數據傳輸之前，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 協議，在半年之內（182.5 天）都不允許用 HTTP，你以後就自己做轉換吧，不要再來麻煩我了。
1. 用戶在瀏覽器里輸入 HTTP 協議進行訪問時，瀏覽器會自動將 HTTP 轉換為 HTTPS 進行訪問，確保用戶訪問安全；
2. 省去301跳轉的出現，縮短訪問時間；
3. 能阻止基於 SSL Strip 的中間人攻擊，萬一證書有錯誤，則顯示錯誤，用戶不能迴避警告，從而能夠更加有效安全的保障用戶的訪問。
2、TLS握手優化
在傳輸應用數據之前，客戶端必須與服務端協商密鑰、加密算法等信息，服務端還要把自己的證書發給客戶端表明其身份，這些環節構成 TLS 握手過程。
使用 ECDHE 橢圓曲線密碼套件，可以節約帶寬和計算量，還能實現「False Start」，採用 False Start （搶先開始）技術，瀏覽器在與伺服器完成 TLS 握手前，就開始發送請求數據，伺服器在收到這些數據後，完成 TLS 握手的同時，開始發送響應數據。
開啟 False Start 功能後，數據傳輸時間將進一步縮短。
3、Session Identifier（會話標識符）復用
如果用戶的一個業務請求包含了多條的加密流，客戶端與伺服器將會反覆握手，必定會導致更多的時間損耗。或者某些特殊情況導致了對話突然中斷，雙方就需要重新握手，增加了用戶訪問時間。
（1）伺服器為每一次的會話都生成並記錄一個 ID 號，然後發送給客戶端；
（2）如果客戶端發起重新連接，則只要向伺服器發送該 ID 號；
（3）伺服器收到客戶端發來的 ID 號，然後查找自己的會話記錄，匹配 ID 之後，雙方就可以重新使用之前的對稱加密秘鑰進行數據加密傳輸，而不必重新生成，減少交互時間（只用一個消息往返就可以建立安全連接）。
但它也有缺點，伺服器必須保存每一個客戶端的會話數據，對於擁有百萬、千萬級別用戶的網站來說存儲量就成了大問題，加重了伺服器的負擔。於是又出現了第二種「Session Ticket」的方案。
它有點類似 HTTP 的 Cookie，存儲的責任由伺服器轉移到了客戶端，伺服器加密會話信息，用「New Session Ticket」消息發給客戶端，讓客戶端保存。重連的時候，客戶端使用擴展「session_ticket」發送「Ticket」而不是「Session ID」，伺服器解密後驗證有效期，就可以恢復會話，開始加密通信。不過「Session Ticket」方案需要使用一個固定的密鑰文件（ticket_key）來加密 Ticket，為了防止密鑰被破解，保證「前向安全」，密鑰文件需要定期輪換，比如設置為一小時或者一天。
4、開啟OSCP Stapling（OSCP裝訂），提高TLS握手效率
客戶端的證書驗證其實是個很複雜的操作，除了要公鑰解密驗證多個證書籤名外，因為證書還有可能會被撤銷失效，客戶端有時還會再去訪問 CA，下載 CRL （Certificate revocation list，證書吊銷列表，用於確認證書是否有效，體積較大，現基本不用）或者 OCSP 數據，這又會產生 DNS 查詢、建立連接、收發數據等一系列網絡通信，增加好幾個 RTT。
採用OCSP Stapling ，提升 HTTPS 性能。服務端主動獲取 OCSP 查詢結果並隨著證書一起發送給客戶端，從而客戶端可直接通過 Web Server 驗證證書，提高 TLS 握手效率。
伺服器模擬瀏覽器向 CA 發起請求，並將帶有 CA 機構簽名的 OCSP 響應保存到本地，然後在與客戶端握手階段，將 OCSP 響應下發給瀏覽器，省去瀏覽器的在線驗證過程。由於瀏覽器不需要直接向 CA 站點查詢證書狀態，這個功能對訪問速度的提升非常明顯。
5、完全前向加密PFS，保護用戶數據，預防私鑰泄漏
非對稱加密算法 RSA，包含了公鑰、私鑰，其中私鑰是保密不對外公開的，由於此算法既可以用於加密也可以用於簽名，所以用途甚廣，但是還是會遇到一些問題：
（1） 假如我是一名黑客，雖然現在我不知道私鑰，但是我可以先把客戶端與伺服器之前的傳輸數據（已加密）全部保存下來
（2）如果某一天，伺服器維護人員不小心把私鑰泄露了，或者伺服器被我攻破獲取到了私鑰
（3）那我就可以利用這個私鑰，破解掉之前已被我保存的數據，從中獲取有用的信息，即所謂的「今日截獲，明日破解」。
所以為了防止上述現象發生，我們必須保護好自己的私鑰。
如果私鑰確實被泄漏了，那我們改如何補救呢？那就需要PFS（perfect forward secrecy）完全前向保密功能，此功能用於客戶端與伺服器交換對稱密鑰，起到前向保密的作用，也即就算私鑰被泄漏，黑客也無法破解先前已加密的數據。維基解釋是：長期使用的主密鑰泄漏不會導致過去的會話密鑰泄漏
實現此功能需要伺服器支持以下算法和簽名組合：
（1）ECDHE 密鑰交換、RSA 簽名；
（2）ECDHE 密鑰交換、ECDSA 簽名；
ECDHE 算法在每次握手時都會生成一對臨時的公鑰和私鑰，每次通信的密鑰對都是不同的，也就是「一次一密」，即使黑客花大力氣破解了這一次的會話密鑰，也只是這次通信被攻擊，之前的歷史消息不會受到影響，仍然是安全的。
使用ECDHE算法的TLS交換過程具有如下優點：運算速度快，安全性高，還支持「False Start」，能夠把握手的消息往返由 2-RTT 減少到 1-RTT
所以現在主流的伺服器和瀏覽器在握手階段都已經不再使用 RSA，改用 ECDHE，而 TLS1.3 在協議里明確廢除 RSA 和 DH 則在標準層面保證了「前向安全」。