一篇文章讀懂HTTPS及其背後的加密原理

來自：Hollis（微訊號：hollischuang）

原作者：安靜的boy，Hollis做了簡單的修改與排版。

HTTPS（全稱：Hypertext Transfer Protocol Secure，超文字傳輸安全協議），是以安全為標的的HTTP通道，簡單講是HTTP的安全版。本文，就來深入介紹下其原理。

 

1

為什麼需要https

使用https的原因其實很簡單，就是因為http的不安全。

當我們往伺服器傳送比較隱私的資料（比如說你的銀行卡，身份證）時，如果使用http進行通訊。那麼安全性將得不到保障。

首先資料在傳輸的過程中，資料可能被中間人抓包拿到，那麼資料就會被中間人竊取。

其次資料被中間人拿到後，中間人可能對資料進行修改或者替換，然後發往伺服器。

最後伺服器收到資料後，也無法確定資料有沒有被修改或替換，當然，如果伺服器也無法判斷資料就真的是來源於客戶端。

總結下來，http存在三個弊端：

• 無法保證訊息的保密性

• 無法保證訊息的完整性和準確性

• 無法保證訊息來源的可靠性

https就是為瞭解決上述問題應運而生的。

2

基本概念

為瞭解決http中存在的問題，https採用了一些加解密，數字證書，數字簽名的技術來實現。下麵先介紹一下這些技術的基本概念

對稱加密與非對稱加密

為了保證訊息的保密性，就需要用到加密和解密。加解密演演算法目前主流的分為對稱加密和非對稱加密。

1.對稱加密（共享密匙加密）：客戶端和伺服器公用一個密匙用來對訊息加解密，這種方式稱為對稱加密。客戶端和伺服器約定好一個加密的密匙。客戶端在發訊息前用該密匙對訊息加密，傳送給伺服器後，伺服器再用該密匙進行解密拿到訊息。

對稱加密的優點：

• 對稱加密解決了http中訊息保密性的問題

對稱加密的缺點：

• 對稱加密雖然保證了訊息保密性，但是因為客戶端和伺服器共享一個密匙，這樣就使得密匙特別容易洩露。

• 因為密匙洩露風險較高，所以很難保證訊息來源的可靠性、訊息的完整性和準確性。

2.非對稱加密（公有密匙加密）：既然對稱加密中，密匙那麼容易洩露，那麼我們可以採用一種非對稱加密的方式來解決。

採用非對稱加密時，客戶端和服務端均擁有一個公有密匙和一個私有密匙。公有密匙可以對外暴露，而私有密匙只有自己可見。

使用公有密匙加密的訊息，只有對應的私有密匙才能解開。反過來，使用私有密匙加密的訊息，只有公有密匙才能解開。這樣客戶端在傳送訊息前，先用伺服器的公匙對訊息進行加密，伺服器收到後再用自己的私匙進行解密。

非對稱加密的優點：

• 非對稱加密採用公有密匙和私有密匙的方式，解決了http中訊息保密性問題，而且使得私有密匙洩露的風險降低。

• 因為公匙加密的訊息只有對應的私匙才能解開，所以較大程度上保證了訊息的來源性以及訊息的準確性和完整性。

非對稱加密的缺點：

• 非對稱加密時需要使用到接收方的公匙對訊息進行加密，但是公匙不是保密的，任何人都可以拿到，中間人也可以。那麼中間人可以做兩件事，第一件是中間人可以在客戶端與伺服器交換公匙的時候，將客戶端的公匙替換成自己的。這樣伺服器拿到的公匙將不是客戶端的，而是伺服器的。伺服器也無法判斷公匙來源的正確性。第二件是中間人可以不替換公匙，但是他可以截獲客戶端發來的訊息，然後篡改，然後用伺服器的公匙加密再發往伺服器，伺服器將收到錯誤的訊息。

• 非對稱加密的效能相對對稱加密來說會慢上幾倍甚至幾百倍，比較消耗系統資源。正是因為如此，https將兩種加密結合了起來。

數字證書與數字簽名

為瞭解決非對稱加密中公匙來源的不安全性。我們可以使用數字證書和數字簽名來解決。

1.數字證書的申請

在現實中，有一些專門的權威機構用來頒發數字證書，我們稱這些機構為認證中心（CA Certificate Authority）。

我們（伺服器）可以向這些CA來申請數字證書。

申請的過程大致是：

自己本地先生成一對密匙，然後拿著自己的公匙以及其他資訊（比如說企業名稱啊什麼的）去CA申請數字證書。

CA在拿到這些資訊後，會選擇一種單向Hash演演算法（比如說常見的MD5）對這些資訊進行加密，加密之後的東西我們稱之為摘要。

單向Hash演演算法有一種特點就是單向不可逆的，只要原始內容有一點變化，加密後的資料都將會是千差萬別（當然也有很小的可能性會重覆，有興趣的小夥伴鴿巢原理瞭解一下），這樣就防止了資訊被篡改。

生成摘要後還不算完，CA還會用自己的私匙對摘要進行加密，摘要加密後的資料我們稱之為數字簽名。

最後，CA將會把我們的申請資訊（包含伺服器的公匙）和數字簽名整合在一起，由此而生成數字證書。然後CA將數字證書傳遞給我們。

2.數字證書怎麼起作用

伺服器在獲取到數字證書後，伺服器會將數字證書傳送給客戶端，客戶端就需要用CA的公匙解密數字證書並驗證數字證書的合法性。那我們如何能拿到CA的公匙呢？我們的電腦和瀏覽器中已經內建了一部分權威機構的根證書，這些根證書中包含了CA的公匙。

之所以是根證書，是因為現實生活中，認證中心是分層級的，也就是說有頂級認證中心，也有下麵的各個子級的認證中心，是一個樹狀結構，計算機中內建的是最頂級機構的根證書，不過不用擔心，根證書的公匙在子級也是適用的。

客戶端用CA的公匙解密數字證書，如果解密成功則說明證書來源於合法的認證機構。解密成功後，客戶端就拿到了摘要。

此時，客戶端會按照和CA一樣的Hash演演算法將申請資訊生成一份摘要，並和解密出來的那份做對比，如果相同則說明內容完整，沒有被篡改。最後，客戶端安全的從證書中拿到伺服器的公匙就可以和伺服器進行安全的非對稱加密通訊了。伺服器想獲得客戶端的公匙也可以透過相同方式。

下圖用圖解的方式說明一般的證書申請及其使用過程。

1

https原理

透過上面的學習，我們瞭解對稱加密與非對稱加密的特點和優缺點，以及數字證書的作用。https沒有採用單一的技術去實現，而是根據他們的特點，充分的將這些技術整合進去，以達到效能與安全最大化。這套整合的技術我們稱之為SSL（Secure Scoket Layer 安全套接層）。所以https並非是一項新的協議，它只是在http上披了一層加密的外殼。 

https的建立

先看一下建立的流程圖：

這裡把https建立到斷開分為6個階段，12過程。下麵將對12個過程一 一做解釋

1.客戶端透過傳送Client Hello報文開始SSL通訊。報文中包含客戶端支援的SSL的指定版本、加密元件（Cipher Suite）串列（所使用的加密演演算法及密匙長度等）。

2.伺服器可進行SSL通訊時，會以Server Hello報文作為應答。和客戶端一樣，在報文中包含SSL版本以及加密元件。伺服器的加密元件內容時從接收到的客戶端加密元件內篩選出來的。

3.伺服器傳送證書報文。報文中包含公開密匙證書。

4.最後伺服器傳送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束。

5.SSL第一次握手結束之後，客戶端以Client Key Exchange報文作為回應。報文包含通訊加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密匙進行加密。

6.接著客戶端繼續傳送Change Cipher Spec報文。該報文會提示伺服器，在此報文之後的通訊會採用Pre-master secret密匙加密。

7.客戶端傳送Finished報文。該報文包含連線至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正確解密該報文作為判定標準。

8.伺服器同樣傳送Change Cipher Spec報文

9.伺服器同樣傳送Finished報文

10.伺服器和客戶端的Finished報文交換完畢之後，SSL連線就算建立完成。當然，通訊會收到SSL的保護。從此處開始進行應用層協議的通訊，即傳送HTTP請求。

11.應用層協議通訊，即傳送HTTP相應。

12.最後由客戶端斷開連線。斷開連線時，傳送close_notify報文。上圖做了一些省略，這步之後再傳送TCP FIN報文來關閉與TCP的通訊。

另外，在以上流程圖中，應用層傳送資料時會附加一種叫做MAC（Message Authentication Code）的報文摘要。MAC能夠查知報文是否遭到篡改，從而保證報文的完整性。

下麵再用圖解來形象的說明一下，此圖比上面數字證書的圖更加的詳細一些（圖片來源於《圖解HTTP》）

經過上面的介紹，我們可以看出https先是利用數字證書保證伺服器端的公匙可以安全無誤的到達客戶端。然後再用非對稱加密安全的傳遞共享密匙，最後用共享密匙安全的交換資料。

1

https的使用

https那麼的安全，是不是我們在什麼場景下都要去使用https進行通訊呢？答案是否定的。

1.https雖然提供了訊息安全傳輸的通道，但是每次訊息的加解密十分耗時，訊息系統資源。所以，除非在一些對安全性比較高的場景下，比如銀行系統，購物系統中我們必須要使用https進行通訊，其他一些對安全性要求不高的場景，我們其實沒必要使用https。

2.使用https需要使用到數字證書，但是一般權威機構頒發的數字證書都是收費的，而且價格也是不菲的，所以對於一些個人網站特別是學生來講，如果對安全性要求不高，也沒必要使用https。

參考資料

https://www.jianshu.com/p/4932cb1499bf

https://mp.weixin.qq.com/s/StqqafHePlBkWAPQZg3NrA