名詞解釋
對稱加解密
常用算法是AES，過程如下
A和B通信，雙方都使用同一個密鑰（比如123456）對數據進行加解密。
A先使用123456對數據“ Hello B”進行加密，然後傳送給B，B再利用123456對收到的數據進行解密就可以得到原文“ Hello B ”
對稱加解密的目的是爲了保證消息的保密性。
非對稱加解密
常用算法是RSA，過程如下
生成一對公鑰和私鑰，私鑰自己持有藏到褲襠裏藏好，公鑰可以像小廣告一樣發給任何人
A持有B的公鑰，B持有私鑰，A首先利用B的公鑰對消息“ Hello B ”進行加密然後發送給B，
B收到消息後利用藏在褲襠裏的私鑰進行解密得到“ Hello B ”
那B如果想給A發送消息咋辦呢？
利用藏在褲襠裏的私鑰對“ Hello A ”進行加密然後發送給A，A收到消息後利用B的公鑰進行解密得到“ Hello A ”，好像沒問題是吧？
仔細琢磨下，公鑰任何一個人都可以從B那裏獲取到，這樣B用私鑰加密的消息豈不是大家都能解密
所以非對稱加解密的正確使用方法是「公鑰加密私鑰解密實現加解密」、「私鑰加密公鑰解密實現數字簽名和數字驗籤」
非對稱加解密的目的
- 一是爲了保證消息的保密性，
- 二是爲了保證消息來源身份三方確認（數字簽名的作用）
密鑰協商
一種乍一聽起來比較神奇的算法，就是A和B可以在交換部分公開數據的情況下，分別在自己這裏算出一個相同的數字。
舉個一個很簡單的例子
A和B先溝通下都選擇好一個相同的數字100（可以公開），然後A自己再選定一個數字比如3（藏到褲襠裏），
B也自己心裏默默選好一個數字比如9（藏到褲襠裏），
A將3乘以100得到300（可以公開），B將9乘以100得到900（可以公開），
然後AB之間互相交換300和900，截止到目前爲止A擁有100，3，900三個數字，
而B擁有100，9，300三個數字
看好了！A將3乘以900得到2700，B將9乘以300得到2700，2700可以作爲一個密鑰進行加解密通信了，
而且整個過程中2700沒有在網絡上進行傳播。
單向散列
這個應該好理解，其實就是哈希，常見猶如MD5或者SHA1、SHA2、SHA3等。單向散列是爲了保證消息的完整性，粗暴說就是保證消息沒有被篡改。
數字簽名
非對稱加解密中的RSA就可以實現，一般是爲了保證消息來源身份三方確認。
就是說這個數字簽名就是用來確認發送方身份的。
這種技術非常厲害，TA對如下問題作出保證
B用私鑰進行加密生成數字簽名，A用公鑰(B的)對數字簽名逆向解密，如果成功就一定表示該數據來源於B；
B要發送 “你好，吧啦巴巴 ....” 給 A 內容下面用msg代指
B先用hash函數作用要傳輸的內容msg,生成一個摘要(digest)
然後B用自己的私鑰 作用在摘要(digest)上，生成數字簽名signature
B把signature附在信件下面發給A 即發送的內容大致爲msg+signature
A收取B發送的內容 msg+signature
取出signature,用B的公鑰解密signature,得到digest,解密成功說明確實是B發來的
A取出msg,用同樣的hash函數作用在msg得到digest1,如果digest1==disgest 說明信息沒被修改過
--------------------------------------------------------------------------------------
C用了A的電腦，把B已經有的A的公鑰換成了自己(C的)公鑰
然後C就可以冒充B給A寫信了
A發現不對，這是證書機構CA就會介入了
如果有第三個人C利用自己私鑰生成數字簽名，然後C劫持了B和A中間的網絡，C冒充B將自己的數字簽名發送給A，那麼A利用B的公鑰對數字簽名進行解密時候，會報錯！
數字證書
CA們頒發給申請者的，粗暴理解數字證書目的就是「向所有人保證來自於A的公鑰真的是來自A的公鑰」。數字證書中包含內容有：公鑰內容，公鑰內容的單向散列值，計算單向散列所用的方法，對鑰內容的單向散列值的數字簽名，數字證書的頒發日期以及過期時間等等衆多內容...其實就是你訪問HTTPS網站瀏覽器裏那個玩意
證書.png
CA機構
頒發數字證書的機構
非對稱加密
非對稱加解密大概就是服務器有一對公鑰和私鑰，其中公鑰是對任何人都開放的，而私鑰必須是藏到褲襠裏絕不能泄漏的。
而其使用方法也非常簡單：
- 私鑰加密的數據，公鑰可以解密
- 公鑰加密的數據，私鑰可以解密
- 公鑰和私鑰是成雙成對的，不可以亂配對亂戴帽
一般說來，正規用法都是：公鑰加密私鑰解密。
因爲業務場景都是公鑰都是像電線杆子上的小廣告那樣滿天飛的，就是任何人都可以獲取到的。所以你感受下
「私鑰加密公鑰解密」這個流程是不是有點兒沙雕？結合一個具體的交互過程你們感受一下：
瀏覽器從服務器獲取到公鑰
瀏覽器先使用公鑰加密數據「一支穿雲箭」，然後發送給服務器
服務器收到數據「一支穿雲箭」，然後使用藏在褲襠裏的私鑰解密
在這個過程裏，由於偷窺的人沒有私鑰，所以TA毛都看不到，嗯，截止到目前爲止，似乎還沒有遇到問題，然後我們接着交互：
服務器準備應答瀏覽器，他用藏在褲襠裏的私鑰加密好「千軍萬馬來相見」，然後返回給了瀏覽器
瀏覽器使用公鑰進行解密
這個過程就比較逗逼了，公鑰是公開的，誰都能解開「千軍萬馬來相見」，這太扯了...實際上在文章開頭也提過了，非對稱加解密的用法是
「公鑰加密私鑰解密實現加解密」、「私鑰加密公鑰解密實現數字簽名和數字驗籤」
如果我們完全不在意服務器返回給客戶端數據？假設說服務器返回給客戶端的都是OK，加密沒有任何意義。
這樣就沒問題了嗎？然而並沒有，因爲還有個王炸。在衆多的偷窺癖裏有一類偷窺癖可以順利成爲「夾在客戶端和服務器之間的中間人」（此處不要陷入到如何成爲中間人的細節中），此時客戶端和服務器的交流變成了這樣
這種攻擊就是傳說中的「中間人劫持」攻擊，大家可以看到此時非對稱加密後的數據此時對於中間來說就是純透明的。
在客戶端面前，中間人就是服務器；在服務器面前，中間人就是客戶端。客戶端和服務器那些個破事兒全被扒光了。
這有點兒扯，所以也GG了
CA機構和證書
所以我們看到非對稱加解密的方案裏，問題根源就直接出在了第一步
：獲取的公鑰本身就是假的。現在問題集中在如何保證第一步溝通裏的「公鑰」不是僞造這個問題上來了，此時一個恰飯的機構就應運而生了：CA，他們會給你的公鑰頒發一個證書，用證書告訴世界上所有人這公鑰沒問題，俗稱證書機構。
這個機構啥意思呢，就是說：我們是全球人類都承認的客觀、獨立、第三方的機構，管理證書沒有人比我們更專業、沒有人比我們更懂證書管理、我們比任何人都更加懂保證證書真假。
所以，之前的客戶端們、中間人們、服務器們三個主角中，又多來了一位：CA們。現在變成了四方大戰、滿身大漢！場面一度十分混亂，變成如下這樣了，我整理好你們感受下：
- 客戶端們
- 中間人們：假公鑰假私鑰
- 服務器們：真公鑰真私鑰
- CA們：CA公鑰和CA私鑰
這裏流程就變成這樣了
-
服務器A生成一對自己的公鑰私鑰，然後將公鑰和自己的基本信息發送給CA們。這裏的基本信息就是我叫啥、住哪兒、電話號碼、域名信息等。
-
然後這裏有一步至關重要的流程，那就是CA們是如何證實公鑰就是來自於服務器A的呢？這裏一般涉及到的認證方式有很多，
比如我們用letsencrypt時候有一種認證方式就是通過DNS來證明，甚至有些通過電話認證，更甚至通過當面+身份ID認證，這裏有一個專門的CPS認證業務準則，你們有興趣可以瞭解下。總之不必限於細節，我們無條件信任這個流程是100%沒問題的即可。這個步驟就杜絕了CA們收到的不是中間人們的公鑰，確保一定收到的是服務器們的公鑰！ -
CA們自己也生成了一對CA公鑰和CA私鑰，CA們第一步對你的公鑰先進行一次單向散列（其實就是哈希）
第二步再利用自己的CA私鑰對第一步裏生成的單向散列值進行數字簽名（這個過程請記住順序，但是此處不必陷於單向散列和數字簽名細節）形成數字證書，給服務器A（PS：這個流程CA們會收費恰飯）。
數字證書中包含的內容有：服務器A的公鑰明文，服務器A的公鑰明文進行單向散列後的值，單向散列的具體算法，單項散列值的數字簽名（此處再保留一個問題：如果服務器A得到的數字證書是僞造的呢？） -
客戶端A所在操作系統中會內置世界上所有CA們的公鑰，是的這個不用你操心，反正你操作系統生產商替你包辦了這個流程，此處不必陷於細節。這一步確保客戶端們得到CA公鑰們不是中間人僞造的公鑰！
-
客戶端A向服務器A發起請求，服務器A將CA們頒發給TA的數字證書發送給客戶端A，此時我們已經知道客戶端A已經擁有了：CA們的公鑰，CA們頒發給服務器A的數字證書。這一步就算是中間人們發送的假數字證書也無所謂，先往下看第6步。
-
此處開始高能，請慢慢看流程：
首先客戶端A再從數字證書中獲取到單向散列的具體算法和服務器A的公鑰和數字簽名，
其次客戶端A再利用CA們的公鑰對數字簽名進行「逆向」解密，此處如果解密失敗表示有問題。
如果沒有問題解密成功，將會得到服務器A的公鑰的散列值，而散列算法也是已知的，所以客戶端A會利用相同算法對服務器A的公鑰進行單向散列，然後和數字證書中的服務器A的公鑰的單向散列值進行對比，如果不一樣，就說明這個公鑰不是服務器A的公鑰表示有問題。如果客戶端計算出來的散列值和數字證書裏的散列值一樣，就說明完全沒問題了。
當然還會包括有效期的驗證等等，你們應該都見過HTTPS證書過期後是啥樣的吧？
我們再回到第3個步驟裏保留的那個問題：如果服務器A得到的數字證書是僞造的呢？這個問題實際上已經不存在了，因爲第6步裏客戶端A利用CA公鑰對數字簽名進行逆向解密的時候，就是驗證數字證書真僞的過程。
再經歷了上述六個流程後，終於解決了開頭的問題：HTTPS向客戶端保證了公鑰就是來自於服務器的公鑰，而不是偷窺者們仿造的公鑰，此處就是HTTPS解決中間人劫持的關鍵。
好了，現在既然已經可以保證公鑰沒問題，那麼就是說客戶端和服務器已經可以進行通信了，但是我們依然還有一個問題尚未解決：那就是客戶端利用服務器公鑰加密數據發送給服務器，這個方向上是沒問題的；但是服務器返回給客戶端的方向上加密是有問題的，因爲服務器私鑰加密，但是公鑰任何一個人都有！怎麼辦？
所以在這裏，HTTPS又用到了「密鑰協商」和「對稱加解密」技術（此處不必陷於「密鑰協商」細節），流程上講大概就是先通過「密鑰協商」技術協商出一個對稱加解密的密鑰，然後客戶端和服務器再利用這個密鑰使用「對稱加解密」技術對數據進行加解密工作。
HTTPS解決了三個問題
- 消息的保密性：消息本身是加密的
- 消息的完整性：消息本身沒有被中間人修改過
- 消息的發送方確認性：消息一定是從來往於服務器和客戶端之間，不存在任何第三方中間人中轉