一、帶着問題走進HTTPS
1.看到https首先想到什麼：
SSL/TLS、數字證書、安全、加密、密文傳輸
2.https總共經過幾次加密:
2~3次
3.都用了哪幾種加密算法:
對稱加密、非對稱加密、數字簽名
4.這幾種加密算法都用在了哪裏:
驗證證書、業務數據傳輸、傳輸預主密鑰
二、假如沒有Https該如何進行安全傳輸
2.1.這種場景在應用中非常常見，它存在哪些安全隱患？
消息泄漏、消息篡改
2.2.有什麼辦法可以對以上問題進行防護？
消息加密->對稱加密
注：對稱加密小知識
對稱加密算法：加密和解密用到的密鑰是相同的，這種加密方式加密速度非常快，適合經常發送數據的場合，特點：密文長度隨明文長度增長而增長。
常見對稱加密算法：
DES：
密鑰總長64位，56位參與加密運算，其他位充當校驗位存在。
原理：將加密原文按64位進行分組，將分組後原文和56位密鑰按位替代或交換生成密文
3DES:
三次DES加密算法，由於計算機運算能力的增強，原版DES密碼的密鑰長度變得容易被暴力破解；3DES即是設計用來提供一種相對簡單的方法，即通過增加DES的加密次數避免類似的攻擊，而不是設計一種全新的塊密碼算法
AES:
美國聯邦政府採用的一種區塊加密標準，首先把明文分成一組一組的，每組長度相等，每次加密一組數據，每一組數據都會經過10+輪以上加密，每一輪都會經歷字節代換、行位移、列混合和輪密鑰加操作，最終疊加得到完整個密文
2.3.消息經過對稱加密後密文傳輸圖如下所示：
疑問一：Client和Server怎麼來確定並交換對稱密鑰？
只能由Server生成密鑰推送給Client或Client生成密鑰發送給Server，密鑰明文傳輸，適用於服務之間進行消息加密傳輸。
分析：
不泄露對稱密鑰？
對Client和Server進行對稱密鑰協商過程再進行一次對稱加密 ，這就會出現加密循環現象，詳細情況以下情況：
結論：
繼續使用對稱算法對對稱密鑰進行加密肯定會陷入加密死循環，依舊無法解決目前對稱密鑰安全傳輸的問題
思考：
有沒有加密算法，密鑰是公開的，可以讓所有人知道？
注：非對稱加密小知識
常見非對稱RSA加密算法原理：公鑰 = 超級大質數p * 超級大質數p (私鑰)
詳見：http://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html
消息再經過非對稱加密後密文傳輸圖如下所示：
小疑問大解惑：
既然有非對稱加密，直接使用非對稱加密後傳輸就OK了，爲何僅使用非對稱加密來傳輸對稱密鑰？
非對稱加密耗性能、慢
公鑰對所有Client公開，Server私鑰加密後相當於所有Client都能獲取使用公鑰進行解密，無法解決消息泄漏問題
疑問二：小C和小小C使用同一個對稱密鑰安全嗎？
多個Client使用同一個密鑰與Server進行通話，依舊存在消息泄漏的問題。
可以讓不同的Client使用不同對稱密鑰，消息再經過多個客戶端使用不同對稱密鑰改造後傳輸圖如下所示：
問題延伸：怎麼做到不同Client使用不同對稱密鑰？
可以讓每個Client在請求時隨機生成一個對稱密鑰，使用Server公鑰對密鑰加密後，將密文同步給Server服務端，服務端使用私鑰解密獲得Client生成的對稱密鑰。
三、真實Https實現方式
3.1.使用非對稱加密傳輸對稱密鑰流程圖(老版本瀏覽器)
由於Https協議建立在Http協議之上，而Https協議建立在TCP三次握手協議之上，所以真實使用非對稱加密算法（RSA）生成隨機對稱密鑰過程如下圖所示：
1)客戶端生成隨機數、加密算法發送發送給服務端
2)服務端接收客戶端隨機數，並生成服務端隨機數和服務器公鑰證書返回給客戶端
3)客戶端接收到服務端隨機數和服務器公鑰後，會根據客戶端、服務端隨機數使用PRF函數生成預主密鑰，再通過預主密鑰+雙隨機數生成主密鑰，再通過主密鑰+雙隨機數生成正式會話密鑰
4)客戶端使用服務器公鑰證書加密預主密鑰，將密文傳輸給服務端
5)服務端接收到預主密鑰密文，是有私鑰解密，獲得預主密鑰，再使用預主密鑰+雙隨機數生成主密鑰，再通過主密鑰+雙隨機數生成正式會話密鑰
6)服務端反饋密鑰交換完成，正式使用會話密鑰通話
3.2.使用ECDHE函數傳輸對稱密鑰流程(新版本瀏覽器)
ECDHE(DHE)算法比RSA更強大，私鑰不參與密鑰的協商，故即使私鑰泄漏，客戶端和服務器之間加密的報文都無法被解密，並且ECDHE每條會話都重新計算一個密鑰，故一條會話被解密後，其他會話仍舊安全，使用的是前向保密
1)客戶端生成隨機數、加密算法發送發送給服務端
2)服務端接收客戶端隨機數，並生成服務端隨機數和服務器公鑰證書返回給客戶端
3)服務端生成DH參數，使用服務端私鑰進行簽名，併發給客戶端
4)客戶端使用服務器公鑰證書對服務端DH參數進行驗證簽名，並在客戶端生成DH參數傳輸給服務端，並在客戶端通過服務端DH參數、客戶端DH參數算出預主密鑰，再通過預主密鑰+雙隨機數生成主密鑰，再通過主密鑰+雙隨機數生成會話密鑰
5)服務端接收到客戶端DH參數，使用服務端DH參數和客戶端DH參數計算出預主密鑰，再使用預主密鑰+雙隨機數生成主密鑰，再通過主密鑰+雙隨機數生成正式會話密鑰
注：DH 密鑰協商算法小知識
Diffie-Hellman：DH 密鑰協商算法，主要用於在不安全的通道生成共享密鑰
舉例說明：
原理：
與非對稱加密算法有所相同，區別在於本次加密是將被除數的冪進行隱藏，其他數字對外暴漏，最終計算出預主密鑰
詳見：https://www.cnblogs.com/qcblog/p/9016704.html
ECDH ->elliptic curve Diffie-Hellman：基於橢圓曲線函數加密，就是上面的 p 和 g 的值不再固定，在多條曲線中找一條，在曲線上選一個動態的點
四、真實HTTPS實現驗證
4.1對應訪問 https://yao.jd.com 返回抓包結果如下所示（ECDHE）：
4.1.1.對應Client Hellow 請求參數如下所示：
4.1.2.對應Server Hellow 返回參數如下所示：
4.1.3.對應Certificate返回參數如下所示：
4.1.4.對應Client Key Exchange請求參數如下所示：
4.1.5.對應正常數據交互如下所示：
五、其他知識點
5.1.CA證書在Https中充當什麼作用？
即使已經存在上面的全部步驟，依舊無法完全保證安全，因爲可能會存在客戶端與服務端之間安插中間者情況，因此需要借用CA證書機制，防止中間者情況，用於驗證服務端公鑰證書安全可靠，具體步驟如下所示：
1)服務端向CA機構申請頒發安全證書
2)CA機構使用CA機構私鑰對服務端公鑰證書文件進行簽名，結合有效期、公司信息等參數生成服務端證書
3)CA機構的頒發的證書必須被本地瀏覽器信任，也就是說本地瀏覽器中存有CA機構的公鑰信息
4)當本地瀏覽器接收到服務端的證書信息，會使用瀏覽器中存的CA結構公鑰信息對證書文件進行驗證簽名，並對證書有效期進行校驗
5)校驗通過後，標識證書合法
5.2.Session Id 和 Session ticket 用來做什麼的？
兩種都是session複用的優化手段，目的用於會話密鑰協商次數，提供通話性能
Session Id：
將會話和會話密鑰信息緩存到服務端，在客戶端發起請求時校驗是否已有會話緩存，存在緩存中直接返回，不再次進行協商，緩存有時間限制。
Session ticket：
將會話核心參數加密成 Session ticket 信息，隨客戶端請求、服務端響應信息一同傳遞，哪裏也不進行存儲。
