HTTPS加密原理,搞懂什麼是對稱加密、非對稱加密、證書、數字簽名
眾所周知，http協議是一種未加密的協議，我們未加密的資料，在傳輸的過程中會經過一個又一個的物理節點，如果被人通過抓包的方式拿到了我們的資料，將會給我們造成無法估量的損失。
為了解決解決這個問題，https應運而生。https通過加密的手段，保障的資料的安全性。那https的怎麼加密的呢？這就是我們接下來需要討論的內容。
1、對稱加密
什麼是對稱加密？
簡單說就是有一個金鑰，它可以加密一段資訊，也可以對加密後的資訊進行解密，和我們日常生活中用的鑰匙作用差不多。
比如說小明需要給小紅髮送一條：Hello World,為了保證資料安全，小明把所有字母往後移動了一位，傳送時的訊息就變成了：Ifmmp Xpsm。
小紅收到訊息後，再把字母順序往前移動一位，就得到了Hello World。
這樣，即使攻擊人拿到密文，他不知道怎麼解密的金鑰，也無法得到密文內容。
- 小明需要給小紅髮送一條：Hello World
- 小明使用對稱加密得到密文Ifmmp Xpsm
- 傳輸密文
- 小紅收到密文，進行解密，得到Hello World
使用對稱加密，即使資料被截獲，但是他沒有金鑰，他無法得到密文內容，也無法修改。
但是對稱加密有一個問題，如何讓雙方都用同一個金鑰進行資料加密，同時不被別人知道
如果瀏覽器內部就預存了網站A的金鑰，且可以確保除了瀏覽器和網站A，不會有任何外人知道該金鑰，那理論上用對稱加密是可以的，這樣瀏覽器只要預存好世界上所有HTTPS網站的金鑰就行了！這麼做顯然不現實。
2、非對稱加密
什麼是非對稱加密？
簡單說就是有兩把金鑰，通常一把叫做公鑰、一把叫私鑰，用公鑰加密的內容必須用私鑰才能解開，同樣，私鑰加密的內容只有公鑰能解開。
如何使用非對稱加密呢？
假如，客戶端需要向伺服器傳送一條資料，瀏覽器需要保障資料的安全性，加密流程如下：
- 某網站伺服器擁有公鑰A與對應的私鑰A’；客戶端擁有公鑰B與對應的私鑰B’。
- 客戶端請求伺服器的公鑰A，公鑰A是公開的，可以明文傳輸
- 客戶端使用公鑰A進行加密，將加密的資料傳送給伺服器
- 伺服器收到資料，使用私鑰A`進行解密，拿到資料
反之，伺服器向客戶端傳送資料也是同樣的流程。
非對稱加密演算法在解決了雙方交換金鑰的問題，但非對稱加密演算法非常耗時，而對稱加密快很多。那我們能不能運用非對稱加密的特性解決前面提到的對稱加密的漏洞？
3、非對稱加密+對稱加密
非對稱加密能讓雙方進行資料交換，但效能不行，對稱加密效能不錯，但是無法確認雙方的加密金鑰，那用非對稱加密完成對稱加密的金鑰交換，之後再用對稱加密進行加密不就可以了嗎？
流程如下：
- 某網站擁有用於非對稱加密的公鑰A、私鑰A’。
- 瀏覽器向網站伺服器請求，伺服器把公鑰A明文給傳輸瀏覽器。
- 瀏覽器隨機生成一個用於對稱加密的金鑰X，用公鑰A加密後傳給伺服器。
- 伺服器拿到後用私鑰A’解密得到金鑰X。
- 這樣雙方就都擁有金鑰X了，且別人無法知道它。之後雙方所有資料都通過金鑰X加密解密即可。
完美！這樣非對稱加密的效能問題也解決了。
但是，這裡面還是有漏洞。
如果在資料傳輸過程中，中間人劫持到了資料，此時他的確無法得到瀏覽器生成的金鑰X，這個金鑰本身被公鑰A加密了，只有伺服器才有私鑰A’解開它，然而中間人卻完全不需要拿到私鑰A’就能幹壞事了。請看：
- 某網站有用於非對稱加密的公鑰A、私鑰A’。
- 瀏覽器向網站伺服器請求，伺服器把公鑰A明文給傳輸瀏覽器。
- 中間人劫持到公鑰A，儲存下來，把資料包中的公鑰A替換成自己偽造的公鑰B（它當然也擁有公鑰B對應的私鑰B’）。
- 瀏覽器生成一個用於對稱加密的金鑰X，用公鑰B（瀏覽器無法得知公鑰被替換了）加密後傳給伺服器。
- 中間人劫持後用私鑰B’解密得到金鑰X，再用公鑰A加密後傳給伺服器。
- 伺服器拿到後用私鑰A’解密得到金鑰X。
通過這一通操作，攻擊者就知道伺服器和瀏覽器之間的公鑰了，這樣，對稱加密就形同虛設了。
為什麼會發生這樣的事？因為瀏覽器拿到公鑰的時候，他無法確定這個公鑰是伺服器的。在傳輸過程中，公鑰被篡改，一方用篡改後的公鑰加密，非對稱加密形同虛設。
4、數字證書
如何證明瀏覽器收到的公鑰一定是該網站的公鑰？這個時候，就要引入第三方機構了，也被稱作CA機構。
CA機構怎麼解決瀏覽器無法確認收到的公鑰是不是網站自己的問題呢？
網站只需要向CA機構申領一份數字證書，這份證書裡面，包括了網站的公鑰，網站的域名和其他一些網站基本資訊。
然後CA機構用自己的私鑰對證書進行加密，同時生成一段密文，這段密碼就叫做數字簽名
數字證書的生成過程如下：
- CA機構擁有非對稱加密的私鑰和公鑰。
- 網站需要申請數字證書，只需將自己網站的資料給CA機構(網站公鑰，網站域名等)
- CA機構對證書明文資料進行hash。
- 對hash後的值用私鑰加密，得到數字簽名
證書的內容大概長這樣
之後的瀏覽器驗證流程如下：
- 拿到證書，從證書中得到公鑰，數字簽名等資料。
- 用CA機構的公鑰對數字簽名解密（瀏覽器內建CA機構的公鑰），得到S。
- 用hash演算法對明文進行hash得到T。
- 顯然通過以上步驟，T’應當等於S‘，除非明文或簽名被篡改。所以此時比較S’是否等於T’，等於則表明證書可信。如果證書的資料沒有被改動過,S和T應該是相同的，則證書可信任，瀏覽器就用證書中的公鑰加密資料。
- 如果S和T，則說明證書已被篡改，證書不可信，從而終止向伺服器傳輸資訊，防止資訊洩露給中間人。
** 為什麼S和T不一樣，說明證書就被篡改了呢？**
這裡是理解證書認證的關鍵，仔細思考，數字簽名是用CA機構的私鑰加密的，CA機構的私鑰只有CA機構自己知道，如果證書被中間人劫持，他拿到證書，修改了證書中的公鑰，因為公鑰修改後，資料的Hash值，就和數字簽名解密後的Hash值不同了，瀏覽器就知道證書被動過，而中間人無法偽造數字簽名，因為數字簽名是用CA機構的私鑰加密的，他要偽造，就必須拿到CA機構的私鑰！
中間人有可能把證書掉包嗎
假設有另一個網站B也拿到了CA機構認證的證書，它想劫持網站A的資訊。於是它成為中間人攔截到了A傳給瀏覽器的證書，然後替換成自己的證書，傳給瀏覽器，之後瀏覽器就會錯誤地拿到B的證書裡的公鑰了，這確實會導致上文“中間人攻擊”那裡提到的漏洞？
其實這並不會發生，因為證書裡包含了網站A的資訊，包括域名，瀏覽器把證書裡的域名與自己請求的域名比對一下就知道有沒有被掉包了。
瀏覽器怎麼得到CA機構的公鑰
CA機構的公鑰去通過網路獲取，如果通過網路去獲取，那CA機構生成的證書就沒意義了。
一般瀏覽器會內建主流的CA機構的公鑰。