白話HTTPS加密機制

2019 年 10 月 10 日
筆記

在講主題之前，我們先來區分兩個概念：簽名和加密有什麼區別？

我們從字面意思看：

簽名就是一個人對文件簽署自己的名字，證明這個文件是我寫的或者我認可的，所以只要別人看到我的簽名，認識我字跡的人就知道這個文件確實是可以信任的，如果文件沒有我的簽名，或者簽名不對，說明文件可能被改動了，是個假的，不可信。在網路安全中，簽名的意義是防止文件篡改，只有簽名正確的文件才可信。
加密就是將一段內容按照一定規則打亂，讓不懂規則的人看不懂這段文字內容，而知道規則的人可以將亂序的內容反推出原文來，從而實現了內容在傳遞過程中不被不相關的人所理解，達到安全的目的。

為什麼要講這兩個東西呢？因為這兩個概念在HTTPS加密過程中是很重要的概念，他們解決了安全傳輸中的兩個重要問題：

保證資訊在傳輸過程中是加密的狀態，
保證資訊不被篡改

正題

為了生動的講述加密過程，我們利用一段角色故事來說明：

故事裡有三個角色：分別是小紅A，小強B，和小賤C.

小紅A代表伺服器，小強B代表客戶端，小賤C代表中間劫持者。以下用ABC簡稱。

故事是這樣的：小紅和小強互相愛慕對方，但是二者離得有點遠，只能通過扔紙條的方式把資訊傳遞給對方。而C特別好奇，就老想在中間把紙條攔截下來偷看（注意，C的目的是偷看資訊，而不是破壞消息，當然去如果他能破解裡面的資訊，可以往裡面加入一些假的東西，比如離間AB，但前提還是要破解消息內容），顯然A和B是不願意的，所以他們要想出一個辦法，既要實現二者的溝通，又要實現資訊的「保密」。

他們想到了以下幾種方案：

方案1：

A和B用一套相同的規則對消息進行加密和解密，這套規則需要一個字元串x作為密鑰來加密和解密，這樣C不知道x的話即使截獲到了消息也看不懂內容。

這套方案就是對稱加密方案，對稱加密方案效率高，但是有個很大的缺陷：A和B怎麼商定這個x呢？第一次傳遞的時候明文把x傳遞給對方嗎？顯然不行，因為可能被C截獲到，這樣C也能解密消息了。

這個時候，人們發明了一種神奇的盒子，這個盒子可以實現只有擁有者可以解開這個盒子，別人只能往裡塞資訊，卻打不開，看不到裡面裝了啥，A和B正犯愁呢，聽說這個神奇的盒子後，想出了一套新的方案：

方案2：

A和B都拿了個黑盒子，他們互相把自己的黑盒子扔給對方，然後彼此把消息放到黑盒子里，扔回去，然後A和B從盒子里拿出對方發送的消息。這樣就解決安全問題了，但是有個很大的缺點，就是每條資訊兩個人都要向黑盒子里塞東西，這個過程太麻煩了，效率很低，於是AB又開始發愁了。

方案二是用的純非對稱加密的方法，其中黑盒子就是非對稱加密的公鑰，往盒子里扔東西就是用這段公鑰對資訊加密的過程，之後帶有資訊的黑盒子只有利用私鑰才能解開。

故事裡往黑盒子里塞東西的過程很「麻煩」，其實就是非對稱加密缺點，計算量大，使得效率降低，因此HTTPS也沒有採用這個方案。那麼有沒有更好的方案呢？當然有～，我們看方案1，其實最大的問題就是密鑰x的商討問題，即A和B怎麼互相確定對稱加密密鑰x，而且還不能明文傳輸讓別人知道，於是有第三套方案

方案3:

A這樣操作：給B扔一個黑盒子，B拿到盒子以後，往裡放一段隨機生成的密鑰x，扔回了A。這個過程即是被C截獲了，C也拿不到盒子內部的東西，所以是安全的。之後A從盒子里把B給他的密鑰拿出來，然後他們就用這段密鑰x通過方法1的方式溝通了。

該方法就是現在HTTPS的加密方法，利用的非對稱加密+對稱加密的方式結合的方式，非對稱加密傳遞確認對稱加密的密鑰x，之後完全用對稱加密傳送資訊。

那麼這套方案就沒有漏洞了嗎？聰明的C又想出來一個辦法：在截獲A給B黑盒子時，他也買了一個黑盒子，把這個A給的黑盒子替換成自己的盒子，給了B，B拿到「假盒子」後，把密鑰x放了進去，C又截獲了這個帶有x的黑盒子，因為是自己買的黑盒子，當然能解開了，所以就拿到了密鑰x。然後他把x放進A的真盒子，扔給了A，這時A不知道發生了什麼，使用盒子里的x作為後續交流的密鑰，跟B進行後續的溝通。而其實，C早就知道他倆的密碼了，隨時都可以拿到消息進行解密。

因此，這套方案唯一的問題就是：B怎麼知道它拿到的黑盒子就是A給的？？現實中，盒子就是一個公鑰，只是一個字元串，怎麼知道這個字元串就是網站的呢？這個問題確實難倒了A，她想在現實生活中尋找答案：我快遞給了別人一個號碼，怎麼證明這個號碼是我的，而且中間沒有人改過？她突然想起了自己的身份證，身份證號碼是一個人的唯一標識，當我告訴別人我的身份證號碼時，別人怎麼相信的這個號碼是我的？給他身份證看！小紅感覺靈感來了，她接著想，別人為什麼看到身份證就相信了呢？很簡單，身份證上有我的名字，有我的ID，最重要的，身份證是公安局發的，別人偽造不了！於是小紅想出了一套解決方案，方案的關鍵就是去「公安局」製作一套「公鑰身份證」。
其實現實中的HTTPS，正是採用了小紅的方案，身份證號碼可以類比網站公鑰，身份證姓名頭像可以類比網站域名等相關資訊，我們來看詳細的解決過程：

如何證明客戶端收到的公鑰是該網站的公鑰

HTTPS採用的類似於身份證的方法，所有用HTTPS的網站都要有一個「公信」機構頒發的證書，證書就像一個身份證一樣，客戶端可以對其進行真實有效性判斷。而這個公信機構就是CA,身份證的防偽手段採用的就是數字簽名，後面會詳細闡述。我們以小紅把身份證寄給小強為例：這個過程分為四步：

小紅把去公安局製作印有公鑰資訊的「身份證」。
把身份證寄給小強。
小強拿到身份證，驗證身份證真偽，
身份證是真的還不夠，因為小賤也可以去公安局做「身份證」，把小紅的快遞調包。所以小強還要看身份證內容，比如看名字，頭像是不是小紅。

以上四步完成以後，後續操作同方案3：小強從身份證上讀取公鑰，利用該公鑰對隨機數X加密,blabla…

我們依次看這四步對應到HTTPS中是怎麼實現的。

製作「身份證」：製作機構是國際組織CA，它負責頒發給申請者一份證書。證書包含兩部分，內容和簽名，內容就像身份證上的身份證號，姓名等，簽名就像身份證的防偽手段一樣，防止證書內容被篡改。CA利用非對稱加密製作簽名，它先將明文的證書內容進行hash，然後對hash值利用私鑰加密生成簽名，最後把簽名和內容一塊發給網站，就是網站的證書。至於證書怎麼防偽的，在小強驗證的時候會詳細說明。
寄快遞：自然是通過網路傳輸，服務端把證書傳遞給客戶端。注意，原來方案三傳輸的是明文的公鑰，現在公鑰寫在了證書上，傳輸的是證書。
小強收到快遞，驗證真偽：如何驗證呢？之前說到，CA製作簽名時用的私鑰，而客戶端都有CA的公鑰（是的，作業系統，瀏覽器等都存有CA的證書，可以拿到其公鑰），用公鑰對證書籤名解密得到一段字元串，拿它跟證書內容的hash值對比，如果相同，則說明證書是可靠真實的。為什麼呢？試想，第三方截獲內容，把內容修改了，比如把證書內容里的域名從www.baidu.com改成了www.google.com，但是因為第三方沒有CA的私鑰，所以沒法將改動後的內容進行加密，如果用錯誤的密鑰加密，用戶驗證的時候簽名是對不上的，因此第三方是改不了證書內容的。也就是說，一個網站在全世界只有這一份唯一的證書，永遠沒有人能改動它，只要改了，就能被識破。整個過程可以借用網上的一個圖片來解釋，見文末。
讀取身份證內容：很簡單，看證書內容就可以了，證書的內容里包含了網站的域名等資訊，如果第三方攻擊者把整個證書文件更改了(包括簽名和內容)，比如上面的百度變Google,客戶端本來想跟百度交流的，但看到內容里寫的是Google，就拒絕跟它溝通，就像你拿到了張三給的身份證，但是上面寫著王五，當然你就不理他了！

注意，有個地方容易混淆，即加密過程牽扯到了兩對公私鑰：CA對證書的加密私鑰對應客戶端早以安裝的CA解密公鑰；客戶端對X加密的公鑰和服務端對X解密的私鑰。其中X即上文中寫的對稱加密的密鑰，整個過程客戶端用了兩個公鑰，CA和服務端各有一個私鑰。

最後用通俗的話總結這個過程：小紅向公安局申請身份證，身份證上寫著她的名字以及她跟小強交流用的公鑰，公安局製作完畢後給小紅，小紅拿著身份證寄給了小強，之後小強通過上面的防偽標誌和姓名確認了其真偽和正確，用上面的公鑰給隨機生成的x加密，還給了小紅，小紅拿著自己的私鑰解出了x，二者用x愉快的交流起來～～～

以上就是HTTPS加密的原理淺析，有漏洞之處，歡迎指出～