開門見山地說，衆所周知，HTTPS=HTTP+SSL/TLS，使用非對稱加密算法+對稱加密算法的混合加密算法。
最近在面試過程中被問到幾次這個問題，看過幾篇博客，說的都不是很清楚，理解也有偏差，毫無意外的面試都掛了，今天看到了阮一峯老師的博客——圖解SSL/TLS
協議，終於有一種醍醐灌頂的感覺。
關鍵點
- 對稱加密算法的祕密密鑰用於加密正文數據（即建立SSL連接後客戶端與服務器之間傳輸的用戶數據）
- 非對稱加密算法用來保證對稱加密算法的祕密密鑰的傳遞（客戶端生成祕密密鑰，傳遞給服務器）
整體流程
- 五次握手建立SSL連接：該部分主要爲了產生後續傳輸數據的祕密密鑰
- 建立連接後，後續就與非對稱加密算法沒有關係了，後續使用對稱加密的祕密密鑰進行數據交互。
SSL五次握手
先上圖（圖片出自阮一峯老師的博客，地址在文章開頭）
下面流程中的公鑰和私鑰均指非對稱加密算法的公鑰和私鑰）
- 客戶端發送
client random——隨機數1和cipher suites supported——客戶端支持的加密算法給服務器 - 服務器把
server random——隨機數2、對稱加密算法（在客戶端支持的加密算法範圍中確認一個）以及包含公鑰證書發送給客戶端 - 客戶端接收到第二步的信息之後，需要確認公鑰證書（記住這個證書只包含公鑰）是來自服務器的，這我們後面再說，確認之後，生成一個
Premaster secret——隨機數3（預主密鑰），並使用公鑰證書中的公鑰加密Premaster secret，得到Encrypted premaster secret並將其發送給服務器 - 服務器收到
Encrypted premaster secret並使用私鑰解密得到Premaster secret。（OK，到此爲止，客服端和服務器均有了隨機數1、隨機數2和隨機數3） - 客服端和服務器使用三個隨機數和第二步約定的加密算法生成祕密密鑰，用於後面傳輸數據時明文數據的加密
現在，SSL連接已經建立了，從上面的流程可以看出來：非對稱加密算法只用過一次，非對稱加密算法本身的性能消耗很大，使用頻繁很消耗性能。
CA證書機構
剛剛我們上面遺留了一個問題，五次握手第二步服務器發送給客戶端的公鑰證書有可能被中間人截取並篡改，那麼客戶端如何確認公鑰證書是來自服務器而不是中間人呢？
這裏CA證書機構就要上場了，在介紹這個過程前需要先介紹幾個概念：摘要、數字簽名
摘要：通過單向hash函數對原文進行哈希，將需加密的明文“摘要”成一串固定長度(如128bit)的密文，不同的明文摘要成的密文其結果總是不相同，同樣的明文其摘要必定一致，並且即使知道了摘要也不能反推出明文。
數字簽名：建立在公鑰加密體制基礎上，是公鑰加密技術的另一類應用。它把公鑰加密技術和數字摘要結合起來，形成了實用的數字簽名技術。
（以上摘自https://blog.csdn.net/xiaoming100001/article/details/81109617）
CA證書申請流程
下面陳述中，單獨的公鑰私鑰依然指服務器的公鑰和私鑰，CA私鑰、公鑰會特別說明
- 服務器S向CA機構提交公鑰、組織信息、個人信息(域名)等信息並申請認證
- CA 通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的所有權等
- 如果審覈通過則向S頒發證書，證書信息包含申請者公鑰、申請者的組織信息和個人信息、簽發機構 CA 的信息、有效時間、證書序列號等信息的
明文，同時包含一個簽名，該簽名生成方法：證書信息明文經過hash散列函數生成摘要，然後通過CA私鑰對摘要進行加密生成的密文就是數字簽名。
客戶端驗證公鑰證書
OK，介紹了這麼多，終於要介紹前面遺留的問題了。
- 現在的情況是，服務器擁有了CA機構頒發的證書和CA公鑰，客戶端擁有CA公鑰（瀏覽器內置CA根證書）。
- 服務器將包含公鑰的證書發送給客戶端（這裏指瀏覽器），證書中包含公鑰、組織信息、有效期等信息，還有一個CA私鑰加密過的數字簽名。
- 客戶端使用CA公鑰對數字簽名解密得到摘要1；客戶端讀取證書中的相關的明文信息，採用相同的散列函數計算得到摘要2，對比摘要1和摘要2，相等則說明證書有效。