1. HTTPS是什么？

HTTP也是一個應用層協議，是在HTTP協議基礎上引入了一個加密層。
HTTP協議內容大譜是按照文本的方式明文傳輸的，這就導致在傳輸的過程中會有被纂改的情況。

2. 加密是什么？

加密就是把明文(要傳輸的信息)進行一系列的變換，生成密文。
解密就是把密文再進行一系列的變換，還原成明文。

那么如何對數據進行加密呢？

2.1 引入對稱加密（效率高）

對稱加密就是加密和解密時使用的密鑰時相同的。

使用對稱加密，每個客戶端都生成一個自己的密鑰，這個密鑰就是以后在HTTP通訊中使用的密鑰，那么服務器就需要把客戶端和密鑰的關系維護起來。

客戶端和服務器在第一次建立連接的時候就需要協商出來一個密鑰，在協商密鑰的過程肯定不能以明文傳輸，所以在協商密鑰的時候也需要進行密文傳輸，所以就引入了非對稱加密。

2.2 引入非對稱加密（效率低）

非對稱加密就是使用公鑰加密用私鑰解密；使用私鑰加密用公鑰解密。公鑰加密的密文不能使用公鑰加密；私鑰加密的密文不能使用私鑰解密。

私鑰只保存在服務器，公鑰保存在客戶端。所有的客戶端持有相同的公鑰。

在客戶端和服務端協商密鑰時使用非對稱加密進行加密，那么此時客戶端和中間設備都持有公鑰，服務器持有私鑰。協商時，客戶端使用公鑰加密來傳輸協商的密文，此時即便中間設備截胡了信息但是中間設備沒有私鑰，并不能破解，也就拿不到協商的密鑰了。之后被公鑰加密的密鑰傳輸到服務器，服務器使用私鑰進行解密，獲取到了協商的密文，服務器在給客戶端返回響應的時候就會使用密鑰加密要傳輸的數據。

在進行第一次協商正常通訊使用的密鑰時，借助非對稱加密，當正常密鑰協商完成之后，所有的交互都使用對稱加密進行通訊。

即便是這樣，中間設備依舊可以使用一些特殊的手段獲取到密鑰：中間設備可以自己生成一對私鑰和密鑰，中間設備在客戶端向服務器發送連接請求時攔截該請求，阻止其到達真實服務器，中間設備偽裝成服務器把自己偽造的公鑰發送給客戶端。客戶端將自己生成的此后進行通訊的密鑰使用公鑰加密發送給服務器時，中間設備再次進行攔截，此時就可以使用私鑰進行解密，獲取到客戶端和服務器協商的密鑰，然后再假裝若無其事的把破解出來的密鑰使用服務器真實發送的公鑰進行加密發送給服務器，服務器接收到時就察覺不到，依舊使用自己持有的私鑰進行正常解密。

那么此時僅僅引入一個非對稱加密就解決不了被中間設備惡意破解的問題了，此時就又引入了一個驗證公鑰真偽的證書。

2.3 引入證書

服務器在使用HTTPS前，需要向CA機構申領一份數字證書，數字證書里含有證書申請者信息、公鑰信息等。服務器把證書傳輸給瀏覽器，瀏覽器從證書中獲取公鑰就行了，證書就像身份證一樣，證明服務器公鑰的權威性。

這個把這個證書理解為一個結構化的字符串，里面包含了一下信息：證書發布機構、證書有效期、公鑰、證書所有者、簽名…

2.3.1 數據簽名

簽名的形成是基于非對稱加密算法的，注意，目前暫時和https沒有關系，不要和https中的公鑰私鑰搞混了。

當服務端申請CA證書的時候，CA機構會對該服務端進行審核，并專門為該網站形成數字簽名，過程如下:

1. CA機構擁有非對稱加密的私鑰A和公鑰A’
2. CA機構對服務端申請的證書明文數據進行hash（使用MD5算法等），形成數據摘要（是一個字符串）。
3. 然后對數據摘要用CA私鑰A’加密，得到數字簽名S服務端申請的證書明文和數字簽名S共同組成了數字證書，這樣一份數字證書就可以頒發給服務端了。

為什么數據摘要在網絡傳輸的時候一定要使用私鑰加密形成數字簽名呢？
常見的數據摘要算法有：MD5、SHA系列。
以MD5為例，我們不需要研究具體的計算簽名的過程，只需要了解MD5的特點：

1. 定長。無論多長的字符串，計算出來的MD5值都是固定的長度（16字節版本或32字節版本）。
2. 分散。源字符串只要改變一點點，最終得到的MD5值都會差別很大。
3. 不可逆。通過源字符串生成MD5 很容易，但是通過MD5 還原成源字符串理論上不可能的。
   正因為MD5有這樣的特性，我們可以認為：如果兩個字符串的MD5 值相同，則認為這兩個字符串相同。
   此時，如果中間設備把內容進行修改并重新hash，客戶端就分辨不出來了，所以被傳輸的哈希值不能傳輸明文，需要傳輸密文。所以CA使用自己的私鑰加密形成數字簽名，將證書內容和加密的數字簽名合起來形成證書，辦法給服務器，當客戶端請求時就發給客戶端，中間人沒有CA私鑰，就無法更改或者整體掉包，就能保證安全。最后，客戶端通過操作系統中已經存了的證書發布機構的公鑰進行解密，還原出原始的哈希值，再進行校驗。

中間人有沒有可能纂改該證書？
即便中間人纂改了該證書，由于他沒有CA機構的私鑰，所以無法hash之后用私鑰加密形成簽名，那么也就沒辦法對纂改之后的證書形成匹配的簽名。如果強行進行纂改的化，客戶端收到該證書后會發現明文和簽名解密后的值不一致，則說明證書已經被纂改，證書不可信，從而終止向服務器傳輸信息，防止信息泄露給中間人。

有沒有可能中間人直接掉包整個證書？
因為中間人沒有CA私鑰，所以無法制作假的證書，所以中間人只能向CA申請真證書，然后用自己申請的證書進行掉包，這個確實能夠做到證書的整體掉包，但是證書明文中包含了域名等服務端認證信息，如果整體掉包，客戶端依舊能夠識別出來。

為什么簽名不直接進行加密，而是要先hash形成摘要？
縮小簽名密文的長度，加快數字簽名的驗證簽名的運算速度。

2.3.2 通過證書解決中間人攻擊

在客戶端和服務端剛建立連接的時候，服務器就給服務端返回一個證書，這個證書包含了公鑰，也包含了網站的身份信息。

當客戶端獲取到這個證書之后，會對證書進行校驗（防止證書是偽造的）。

1. 判定證書的有效期是否過期。
2. 判斷證書的發布機構是的受信任。
3. 驗證證書是否被纂改：從系統中拿到該證書發布機構的公鑰，對簽名進行解密