1、引言

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

補充：限于篇幅，本文對于https的相關技術要點的介紹盡量簡明扼要，如想要詳細了解HTTPS的方方面面，請閱讀《即時通訊安全篇（七）：如果這樣來理解HTTPS，一篇就夠了》。

（本文同步發布于：http://www.52im.net/thread-2446-1-1.html）

2、相關文章

《即時通訊安全篇（七）：如果這樣來理解HTTPS，一篇就夠了》

《一文讀懂Https的安全性原理、數字證書、單項認證、雙項認證等》

《HTTPS時代已來，打算更新你的HTTP服務了嗎？》

《蘋果即將強制實施 ATS，你的APP準備好切換到HTTPS了嗎？》

《一分鐘理解 HTTPS 到底解決了什么問題》

3、為什么需要https

原因其實很簡單：就是因為http不安全。

當我們往服務器發送比較隱私的數據（比如說你的銀行卡，身份證）時，如果使用http進行通信。那么安全性將得不到保障。

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

其次數據被中間人拿到后，中間人可能對數據進行修改或者替換，然后發往服務器。

最后服務器收到數據后，也無法確定數據有沒有被修改或替換，當然，如果服務器也無法判斷數據就真的是來源于客戶端。

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

1）無法保證消息的保密性；

2）無法保證消息的完整性和準確性；

3）無法保證消息來源的可靠性。

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

4、基本概念：加密技術、數字證書和數字簽名

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

4.1 對稱加密與非對稱加密

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

（4.1.1）對稱加密（共享密匙加密）：

客戶端和服務器公用一個密匙用來對消息加解密，這種方式稱為對稱加密。客戶端和服務器約定好一個加密的密匙。客戶端在發消息前用該密匙對消息加密，發送給服務器后，服務器再用該密匙進行解密拿到消息。

對稱加密的優點：對稱加密解決了http中消息保密性的問題

對稱加密的缺點：對稱加密雖然保證了消息保密性，但是因為客戶端和服務器共享一個密匙，這樣就使得密匙特別容易泄露。

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

（4.1.2）非對稱加密（公有密匙加密）：

既然對稱加密中，密匙那么容易泄露，那么我們可以采用一種非對稱加密的方式來解決。

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

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

非對稱加密的優點：

1）非對稱加密采用公有密匙和私有密匙的方式，解決了http中消息保密性問題，而且使得私有密匙泄露的風險降低；

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

非對稱加密的缺點：

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

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

4.2 數字證書與數字簽名

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

（4.2.1）數字證書的申請：

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

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

申請的過程大致是：

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

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

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

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

4）最后，CA將會把我們的申請信息（包含服務器的公匙）和數字簽名整合在一起，由此而生成數字證書。

5）然后CA將數字證書傳遞給我們。

（4.2.2）數字證書怎么起作用：

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

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

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

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

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

5、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先是利用數字證書保證服務器端的公匙可以安全無誤的到達客戶端。然后再用非對稱加密安全的傳遞共享密匙，最后用共享密匙安全的交換數據。

6、一定要用https嗎？

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

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

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

7、參考資料

[1] 通俗理解數字簽名，數字證書和https

[2]一個故事講完https

[3] 圖解HTTP

附錄：更多安全方面的文章

《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》

《即時通訊安全篇（二）：探討組合加密算法在IM中的應用》

《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》

《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風險》

《即時通訊安全篇（五）：對稱加密技術在Android平臺上的應用實踐》

《即時通訊安全篇（六）：非對稱加密技術的原理與應用實踐》

《即時通訊安全篇（七）：用JWT技術解決IM系統Socket長連接的身份認證痛點》

《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》

《理論聯系實際：一套典型的IM通信協議設計詳解（含安全層設計）》

《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》

《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》

《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》

《移動端安全通信的利器——端到端加密（E2EE）技術詳解》

《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》

《通俗易懂：一篇掌握即時通訊的消息傳輸安全原理》

《IM開發基礎知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

《快速讀懂量子通信、量子加密技術》

《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》

《一分鐘理解 HTTPS 到底解決了什么問題》

《一篇讀懂HTTPS：加密原理、安全邏輯、數字證書等》

>> 更多同類文章 ……

（本文同步發布于：http://www.52im.net/thread-2446-1-1.html）