一篇讀懂HTTPS：加密原理、安全邏輯、數字證書等
一、引言
HTTPS（全稱： Hypertext Transfer Protocol Secure，超文本傳輸安全協議），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。本文，就來深刻介紹下其原理。php
補充：限於篇幅，本文對於https的相關技術要點的介紹儘可能簡明扼要，如想要詳細瞭解HTTPS的方方面面，請閱讀《即時通信安全篇（七）：若是這樣來理解HTTPS，一篇就夠了》。html
（本文同步發佈於：http://www.52im.net/thread-2446-1-1.html）算法
二、相關文章
《即時通信安全篇（七）：若是這樣來理解HTTPS，一篇就夠了》瀏覽器
《一文讀懂Https的安全性原理、數字證書、單項認證、雙項認證等》安全
《HTTPS時代已來，打算更新你的HTTP服務了嗎？》服務器
三、爲何須要https
緣由其實很簡單：就是由於http不安全。學習
當咱們往服務器發送比較隱私的數據（好比說你的銀行卡，身份證）時，若是使用http進行通訊。那麼安全性將得不到保障。網站
首先數據在傳輸的過程當中，數據可能被中間人抓包拿到，那麼數據就會被中間人竊取。
其次數據被中間人拿到後，中間人可能對數據進行修改或者替換，而後發往服務器。
最後服務器收到數據後，也沒法肯定數據有沒有被修改或替換，固然，若是服務器也沒法判斷數據就真的是來源於客戶端。
總結下來，http存在三個弊端：
1）沒法保證消息的保密性；
2）沒法保證消息的完整性和準確性；
3）沒法保證消息來源的可靠性。
https就是爲了解決上述問題應運而生的。
四、基本概念：加密技術、數字證書和數字簽名
爲了解決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算法將申請信息生成一份摘要，並和解密出來的那份作對比，若是相同則說明內容完整，沒有被篡改。最後，客戶端安全的從證書中拿到服務器的公匙就能夠和服務器進行安全的非對稱加密通訊了。服務器想得到客戶端的公匙也能夠經過相同方式。
下圖用圖解的方式說明通常的證書申請及其使用過程：
五、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先是利用數字證書保證服務器端的公匙能夠安全無誤的到達客戶端。而後再用非對稱加密安全的傳遞共享密匙，最後用共享密匙安全的交換數據。
六、必定要用https嗎？
https那麼的安全，是否是咱們在什麼場景下都要去使用https進行通訊呢？答案是否認的。
1）https雖然提供了消息安全傳輸的通道，可是每次消息的加解密十分耗時，消息系統資源。因此，除非在一些對安全性比較高的場景下，好比銀行系統，購物系統中咱們必需要使用https進行通訊，其餘一些對安全性要求不高的場景，咱們其實不必使用https。
2）使用https須要使用到數字證書，可是通常權威機構頒發的數字證書都是收費的，並且價格也是不菲的，因此對於一些我的網站特別是學生來說，若是對安全性要求不高，也不必使用https。
七、參考資料
[2]一個故事講完https
[3] 圖解HTTP
附錄：更多安全方面的文章
《即時通信安全篇（一）：正確地理解和使用Android端加密算法》
《即時通信安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《即時通信安全篇（五）：對稱加密技術在Android平臺上的應用實踐》
《即時通信安全篇（七）：用JWT技術解決IM系統Socket長鏈接的身份認證痛點》
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯繫實際：一套典型的IM通訊協議設計詳解（含安全層設計）》
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通信服務的技術實踐分享》
《Web端即時通信安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《即時通信安全篇（七）：若是這樣來理解HTTPS原理，一篇就夠了》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-2446-1-1.html）
- 1. 一篇讀懂HTTPS：加密原理、安全邏輯、數字證書等
- 2. 一文讀懂Https的安全性原理、數字證書、單項認證、雙項認證等
- 3. https數字證書加密理解
- 4. 一文完全搞懂加密、數字簽名、數字證書!
- 5. 一篇文章讀懂HTTPS及其背後的加密原理
- 6. HTTPS加密通訊原理及數字證書系統
- 7. 【下】安全HTTPS-全面詳解對稱加密，非對稱加密，數字簽名，數字證書和HTTPS
- 8. HTTPS的數字證書驗證原理
- 9. Linux安全和加密篇（二）CA和證書原理
- 10. https 證書驗證等原理
- 更多相關文章...
- • Eclipse 添加書籤 - Eclipse 教程
- • ASP.NET MVC - 安全 - ASP.NET 教程
- • ☆技術問答集錦（13）Java Instrument原理
- • Java Agent入門實戰（三）-JVM Attach原理與使用
-
每一个你不满意的现在，都有一个你没有努力的曾经。