本文內容主要講解Https協議，其他網絡知識點作為理解Https協議的輔助。
首先，需要簡單知道網絡協議的四個層次，即：網絡接口層，網絡層，傳輸層，應用層。
Http協議
Http協議是一種超文本傳輸協議，是客戶端瀏覽器與服務器之前的 應用層 通信協議。
Http協議不提供數據加密，以明文的方式發(fā)送內容，容易被攻擊截取信息，不適合用于傳輸一些敏感信息。
Https協議
Https協議是以安全為目標的Http通道，在Http的基礎上加入SSL層，簡單來說就是Http協議的安全版。
Https協議的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數據傳輸的安全；另一種就是確認網站的真實性。
在進行詳細解釋Https之前，我們需要先簡單了解一些Https協議使用到的關鍵技術。
關鍵技術
對稱加密
對稱加密使用加密和解密使用相同密鑰的加密算法進行加密，也叫私鑰加密。常見的對稱加密有：DES, AES 等。
非對稱加密
非對稱加密與對稱加密不同，使用非對稱加密算法進行加密，需要兩個密鑰，即公鑰和私鑰。公鑰和私鑰是成對出現的，在加密和解密的過程中使用不同的密鑰，所以也稱為公鑰加密。
數字摘要
數字摘要采用單項Hash函數將需要加密的明文 摘要 成一串固定長度（128位）的密文，這個密文又稱為數字指紋。不同的明文摘生成的數字指紋總是不同的，而同樣的明文摘要生成的數字指紋必定一致。
數字摘要 是Https能確保數據完整性和防篡改的根本原因。
數字簽名
數字簽名是對 非對稱加密 和 數字摘要 兩項技術的應用。
它將 摘要信息 用發(fā)送者的私鑰加密，與原文一起傳送給接收者。
接收者只有使用發(fā)送者的公鑰才能解密出被加密的 摘要信息；接著對接收到的原文用 數字摘要 生成 摘要信息；然后將兩個 摘要信息 進行對比。若相同，說明收到的原文是完整的，在傳輸過程中沒有被修改。因此，數字簽名能夠驗證數據的完整性。
SSL
SSL是安全套接層，用以保障數據傳輸的安全，利用數據加密技術確保數據在傳輸過程中不會被截取。
SSL又可分為兩層：
- SSL記錄協議建立在可靠的傳輸協議（如TCP）之上，為高層協議提供數據封裝，壓縮，加密等基本功能的支持。
- SSL握手協議建立在SSL記錄協議之上，用于在實際的數據開始傳輸前，通訊雙方進行身份認證，協商加密算法，交換加密密鑰等。
SSL/TLS握手流程
SSL/TLS握手過程流程圖：
-
客戶端發(fā)起請求：在SSL/TLS協議傳輸過程中，客戶端和服務端必須使用同一套加解密算法才能保證數據正常的加解密。由于客戶端對一些加解密算法的支持程度不一樣，所以客戶端需要告知服務端自己支持的加密套件的列表傳給服務端。此外，客戶端還要生成一個隨機數（第一個隨機數），用于傳送給服務端，在后面的步驟中與服務端生成的隨機數結合起來產生 對話密鑰。
那么客戶端需要提供的信息：
- 支持的協議版本
- 支持的加密算法
- 支持的壓縮方法
- 隨機數
-
服務端響應：服務端確定加密協議的版本和加密算法后，也生成一個隨機數（第二個隨機數），并將自己的證書一并發(fā)送給客戶端。
服務端需要提供的信息：
- 確定支持的版本
- 確定加密的算法
- 隨機數
- 服務器證書，包含公鑰
注意：一些場景下，服務器需要確認客戶端的身份，會要求客戶端提供 客戶端證書
-
客戶端驗證證書：客戶端先對服務器下發(fā)的證書進行驗證，驗證通過后客戶端再生成一個隨機數（第三個隨機數，也是最關鍵的隨機數），并使用證書中的公鑰對隨機數進行加密，再加入一個 ChangeCipherSpec 即編碼改變的消息和前面所有消息的Hash值，最后將所有的這些信息發(fā)送到服務器，確保在正式通信前無誤。
此時，客戶端得到全部的三個隨機數，客戶端會用協商的加密方法，生成本次會話所用的同一把 會話密鑰。
ChangeCipherSpec是一個獨立的協議，在數據包中就是一個字節(jié)的數據，用于告知服務端：客戶端已經切換到了協商好的加密套件，準備好加密數據并進行傳輸了。
客戶端提供的信息：
- 使用服務器證書中的公鑰加密后的隨機數（第三個）
- ChangeCipherSpec 編碼改變的通知
- 握手結束的通知
注意：如果服務端需要客戶端證書，客戶端會在這一步發(fā)送證書信息。
-
服務端生成秘鑰：使用私鑰對隨機數（第三個）的加密數據進行解密，此時服務端得到全部的三個隨機數，同樣使用協商的加密方法，生成和客戶端使用的同一把 會話密鑰。準備好后，服務端也會給客戶端一個 ChangeCipherSpec 即編碼改變的消息，告知客戶端已經切換到了協商好的加密套件，準備好加密數據并進行傳輸了。
之后，服務端會使用 會話密鑰 加密一段finish消息發(fā)送給客戶端，以驗證通過握手建立的加密通道是否成功。
客戶端發(fā)送數據：確定 會話密鑰 后，客戶端與服務器之間就會使用對稱加密加密數據后傳輸了。整個握手的過程也就基本完成了。
注意：SSL協議在握手階段使用的是非對稱加密，在傳輸階段使用的是對稱加密。
因為非對稱加密的速度緩慢，比較耗費資源，所以在使用非對稱加密建立連接后，客戶端和服務器之間傳輸數據使用的是協商好的對稱加密算法和對稱加密密鑰（即會話密鑰）。這個數據傳輸過程本身是安全可靠的，也就是說對稱加密密鑰是不可能被竊取盜用的。
如果有人竊聽通訊，他可以知道雙方選擇的加密方法，以及三個隨機數中的兩個，也就是說整個通話的安全，只取決于第三個隨機數（客戶端生成并加密）能不能被破解。
Session的恢復
兩種恢復Session對話的方式：Session ID，Session ticket。
Session ID
客戶端和服務器的每次對話都有一個編號。若對話中斷，重連時只要客戶端給出編號，并且服務器有該編號的記錄，雙方就可以使用已有的 對話密鑰 重新建立連接，而不用重新走握手流程重新連接。
Session ID是目前所有瀏覽器都支持的方法，缺點是Session ID往往只保留在一臺服務器上，如果客戶端重連時請求發(fā)到另一臺服務器上，就無法恢復對話。
Session ticket
客戶端發(fā)送一個服務器在上次對話中發(fā)送過來的Session ticket，其中包括對話的主要信息，如：對話密鑰和加密方法等。這個Session ticket是加密的，只有服務器才能解密，服務器在解密Session ticket后就不用重新生成對話密鑰了。
目前只有部分瀏覽器支持，如：Chrome和Firefox
參考資料：
- 風化成石：Https協議詳解 推薦一看，文章主要精華都吸取自該博客。
- 施小喵：HTTPS原理解析
- K__M：https協議原理
