http和https詳解
https原理詳解
http://liuduo.me/2018/05/14/https-detail/
解析https
https://segmentfault.com/a/1190000012196642
圖解 HTTPS：Charles 捕獲 HTTPS 的原理
https://github.com/youngwind/blog/issues/108
看完還不懂HTTPS我直播吃翔
https://blog.csdn.net/winwill2012/article/details/71774469
SSL/TLS協議運行機制的概述
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
HTTPS是如何防劫持的？
https://www.jianshu.com/p/13a1b955d095
HTTP 的不足之處
（1）通信內容使用明文——第三方可以獲知通信內容
（2）無法驗證報文的完整性——第三方可以修改通信內容
（3）不驗證通信方的身份——第三方可以冒充他人身份參與通信
解決內容爲明文問題——加密
對稱祕鑰加密：通信雙方使用同一個密鑰加密和解密。
問題：怎樣安全的把密鑰從一方發送給另一方，由於網絡本身就是不安全的，因此無法保證密鑰在發送過程中不會被人截獲，任何人只要獲得了密鑰就能隨便解密了。
非對稱祕鑰加密：非對稱祕鑰加密使用一對祕鑰，祕鑰私有，公鑰公開；
發送方使用公鑰對數據進行加密，接收方收到加密數據後，私鑰進行解密。私鑰不需要在網絡上傳輸。
問題：加密和解密的效率較低。
解決報文完整性問題——數字簽名
數字簽名在https中有兩種體現
（1）用私鑰加密數據生成簽名，用公鑰解密簽名得到數據。（用於證書的簽名和驗證簽名）
（2）用私鑰加密數據生成簽名，用私鑰加密數據生氣簽名，進行對比（用於生成會話密鑰之後通信的數據的簽名，以驗證數據的完整性）。
由於簽名用私鑰加密生成，所以數據被篡改後，如果沒有私鑰是沒法爲篡改後的數據生成簽名的。
爲保證效率，一般情況是對數據的摘要進行加密生成簽名。
發送方生成簽名
（1）爲發送報文生成摘要（例如md5）；
（2）私鑰對摘要進行加密生成簽名；
（3）把簽名附在要發送的報文之後，一起發送給接收端。
接收方驗證簽名
（1）取出簽名，用公鑰對簽名進行解密得到摘要1；
（2）對報文部分生成摘要2；
（3）對摘要1和摘要2進行對比，如果一直就是爲篡改過的。
證書
證書實際上就是對公鑰進行數字簽名。（片面）
證書的作用是保證公鑰不會被篡改或替換。（全面）
數字證書是，權威機構使用私鑰對證書進行數字簽名，保證其內容不會被篡改（裏面的公鑰自然也不會被篡改），
客戶端收到證書驗證之後使用權威機構的公鑰進行解密。取得服務端傳傳過來公鑰。
如何保證權威機構的公鑰安全地傳輸給客戶端的呢？
權威機構的公鑰不需要傳輸，他們的公鑰內置在瀏覽器或操作系統環境中，以此來保證證書的公鑰不會被篡改和替換。
https通信流程（簡單版）
客戶端
發起https請求，向服務端索要公鑰；
服務端
給客戶端下發證書，證書中包含公鑰，並用證書保證這個公鑰不會被篡改和替換；
客戶端
1、用本地權威機構的公鑰驗證證書的合法性（本身是驗證簽名的過程，但還包括其他信息驗證，比如日期等）並得到證書中的公鑰
2、生成會話密鑰，用得到的公鑰加密，傳送給服務端。
服務端
用公鑰對應的私鑰解密得到會話密鑰。
至此雙方獲得會話密鑰，
1、之後可用這個會話密鑰進行加密通信，保證了密文傳輸。
2、之後傳輸的每條報文後，附加會話密鑰對報文摘要生成的簽名，接收方收到報文後，同樣使用會話密鑰對這條報文摘要生成簽名，對比簽名，驗證報文完整性。
3、無需再使用證書驗證對方身份，中間人沒有私鑰，無法冒充任何一方，如果強行替換報文，會導致解密失敗和完整性校驗失敗。（因爲中間人沒有會話密鑰，無法對報文進行加密和生成簽名）
https通信流程
1、客戶端發出請求（ClientHello）：
（1） 支持的協議版本，（比如TLS 1.0版。）
（2） 支持的加密方法。
（3） 一個客戶端生成的隨機數，稍後用於生成”會話密鑰"。
2、 服務器迴應（SeverHello）
（1） 確認使用的加密通信協議版本。
（2） 確認使用的加密方法，比如私鑰加密方法。（私鑰、公鑰只有配合加密算法才能對數據進行加密）
（3） 一個服務器生成的隨機數，稍後用於生成"對話密鑰"。
（4） 服務器證書。
客戶端收到服務器迴應以後，首先驗證服務器證書。如果證書不是可信機構頒佈、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信。
如果證書沒有問題，客戶端就會從證書中取出服務器的公鑰。然後，向服務器發送下面三項信息。
3 客戶端迴應
（1） 一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。
（2） 編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
（3） 客戶端握手結束通知。這一項同時附加前面發送的所有內容的摘要的數字簽名，用來供服務器校驗。
4.4 服務器的最後迴應
（1）編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
（2）服務器握手結束通知，這一項同時附加前面發送的所有內容的摘要的數字簽名 ，用來供客戶端校驗。
如果黑客攔截了服務器把證書發送給客戶端，並對證書進行惡意修改，會出現什麼情況？
第一種情況，假如黑客只是單純的修改數字證書中的內容，那麼由於數字簽名的存在，客戶端會很容易的判斷出報文是否被篡改。
第二種情況，黑客不僅修改了數字證書的內容，並且把數字簽名替換掉了，由於黑客不可能知道CA的私鑰，於是在客戶端用CA的公鑰進行解密的時候，解密之後得不到正確的信息，也很容易判斷出報文是否被修改。
第三種情況，黑客惡意的從相同的第三方CA申請了一個數字證書。由於這個CA是真實存在的，所以客戶端是可以用CA的公鑰進行解密，得到了黑客提供的數字證書中的公鑰。但是，由於數字證書在申請的時候，會綁定一個域名，當客戶端比如說瀏覽器，檢測到這個數字證書中的域名和我們現在網頁訪問的域名不一致，便會發出警告，此時我們也能得知數字證書被替換了。發出的警告如下：
[圖片上傳失敗...(image-ab1307-1554208825423)]
中間人攻擊是什麼
[圖片上傳失敗...(image-a7f23e-1554208786025)]
charles 原理是什麼，相當於中間人，需要手動導入charles根證書。
[圖片上傳失敗...(image-864030-1554208786025)]