HTTPS加密流程
由於HTTP的內容在網絡上實際是明文傳輸，並且也沒有身份驗證之類的安全措施，所以容易遭到挾持與攻擊
HTTPS是通過SSL(安全套接層)和TLS(安全傳輸協議)的組合使用，加密TCP載荷即HTTP報文內容，同時通過不對稱密鑰方式認證身份，保證傳輸的安全可靠
即：HTTP+加密+認證+完整性保護=HTTPS
對稱加密與非對稱加密
對稱加密:編/解碼使用相同密鑰的算法,一般是共享密鑰
非對稱加密:非對稱加密算法需要兩個密鑰，公開密鑰（publickey:簡稱公鑰）和私有密鑰（privatekey:簡稱私鑰）。 公鑰與私鑰是一對，如果用公鑰對數據進行加密，只有用對應的私鑰才能解密。 因為加密和解密使用的是兩個不同的密鑰，所以這種算法叫作非對稱加密算法
在HTTPS中，這兩種加密方式混合使用
數字證書認證
由於公鑰在下發的時候也容易被替換劫持，所以需要個第三方認證機構確認公鑰的正確性
CA：數字證書認證機構，是客戶端服務端都認可的第三方機構，負責數字簽名服務端公鑰
數字簽名：簽名就是一種證明身份的機制，是一種校驗機制（簡單說是用私鑰加密內容的hash,公鑰解密對比hash判斷內容是否完整）
數字證書：由一個可信的組織驗證和簽發的識別信息
HTTPS中數字認證流程如下
HTTPS握手過程
HTTPS在進行傳輸HTTP報文數據前，需要經過TLS握手，完成加密，大致流程如下：
- Client Hello:握手第一步是客戶端向服務端發送 Client Hello 消息，這個消息里包含了一個客戶端生成的隨機數 Random1、客戶端支持的加密套件（Support Ciphers）和 SSL Version 等信息
- Server Hello:第二步是服務端向客戶端發送 Server Hello 消息，這個消息會從 Client Hello 傳過來的 Support Ciphers 里確定一份加密套件，這個套件決定了后續加密和生成摘要時具體使用哪些算法，另外還會生成一份隨機數 Random2。注意，至此客戶端和服務端都擁有了兩個隨機數（Random1+ Random2），這兩個隨機數會在后續生成對稱秘鑰時用到。
- Certificate:這一步是服務端將自己的證書下發給客戶端，讓客戶端驗證自己的身份，客戶端驗證通過后取出證書中的公鑰
- Server Hello Done:通知客戶端 Server Hello 過程結束。
- Certificate Verify:客戶端收到服務端傳來的證書后，先從 CA 驗證該證書的合法性，驗證通過后取出證書中的服務端公鑰，再生成一個隨機數 Random3，再用服務端公鑰非對稱加密 Random3生成 PreMaster Key
- Client Key Exchange:上面客戶端根據服務器傳來的公鑰生成了 PreMaster Key，Client Key Exchange 就是將這個 key 傳給服務端，服務端再用自己的私鑰解出這個 PreMaster Key 得到客戶端生成的 Random3。至此，客戶端和服務端都擁有 Random1 + Random2 + Random3，兩邊再根據同樣的算法就可以生成一份秘鑰，握手結束后的應用層數據都是使用這個秘鑰進行對稱加密。為什么要使用三個隨機數呢？這是因為 SSL/TLS 握手過程的數據都是明文傳輸的，並且多個隨機數種子來生成秘鑰不容易被暴力破解出來。
- Change Cipher Spec(Client):這一步是客戶端通知服務端后面再發送的消息都會使用前面協商出來的秘鑰加密了，是一條事件消息
- Encrypted Handshake Message(Client):這一步對應的是 Client Finish 消息，客戶端將前面的握手消息生成摘要再用協商好的秘鑰加密，這是客戶端發出的第一條加密消息。服務端接收后會用秘鑰解密，能解出來說明前面協商出來的秘鑰是一致的
- Change Cipher Spec(Server):這一步是服務端通知客戶端后面再發送的消息都會使用加密，也是一條事件消息
- Encrypted Handshake Message(Server):這一步對應的是 Server Finish 消息，服務端也會將握手過程的消息生成摘要再用秘鑰加密，這是服務端發出的第一條加密消息。客戶端接收后會用秘鑰解密，能解出來說明協商的秘鑰是一致的。
- Application Data:到這里，雙方已安全地協商出了同一份秘鑰，所有的應用層數據都會用這個秘鑰加密后再通過 TCP 進行可靠傳輸
其它
還有一種雙向認證的模式,即在Server Hello Done前發送Certificate Request ，它是服務端要求客戶端上報證書，這一步是可選的，對於安全性要求高的場景會用到，這里不做詳解
如果每次重連都要重新握手還是比較耗時的，所以可以對握手過程進行優化，可以在 Client Hello 消息里還附帶了上一次的 Session ID，服務端接收到這個 Session ID 后如果能復用就不再進行后續的握手過程。
參考
1.《圖解HTTP》
2.《HTTP權威指南》