若是這樣來理解HTTPS，一篇就夠了！
一、前言
可能有初學者會問，即時通信應用的通訊安全，不就是對Socket長鏈接進行SSL/TLS加密這些知識嗎，幹嘛要理解HTTPS協議呢。php
這實際上是個誤解：當今主流的移動端IM數據通訊，總結下來無外乎就是長鏈接+短鏈接的方式，長鏈接就是衆所周之的TCP、UDP、WebSocket（WebSocket的本質仍是TCP），而短鏈接就是HTTP/HTTPS了。即時通信IM應用中，短鏈接的安全跟長鏈接相比，一樣很重要。市面上的主流短鏈接通訊方式，都已逐步從HTTP過渡到HTTPS了（iOS上的應用就更完全了，蘋果直接強制要求使用HTTPS協議，不然不容許上架APP Store，詳見《蘋果即將強制實施 ATS，你的APP準備好切換到HTTPS了嗎？》。不過，鑑於多方面緣由，蘋果實際上推遲了ATS的強制執行，有興趣能夠到蘋果官方瞭解）。html
題外話：關於短鏈接、長鏈接的定義，微信是一個特例，微信在網絡通訊這一層作的比較完全和極端，幾乎再造了一套針對移動端IM的網絡層框架（詳見：《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》），因此針對微信來講短鏈接可能並不能就是HTTP/HTTPS了。git
總之，不管是即時通信IM仍是其它應用，在移動網絡日益發達的今天，安全顯的尤其重要，HTTPS已經愈來愈普及，儘快擁抱它纔是符合技術潮流的。github
本文將嘗試用通俗易懂的語言，一步步還原HTTPS的設計過程，以便您能輕鬆理解爲何HTTPS最終會是這副模樣。但鑑於HTTPS的複雜性，本文的文字主要是爲了方便您的理解，而並不表明徹底聽從HTTPS的真實設計過程。在閱讀本文時，你能夠嘗試放下已有的對HTTPS的理解，這樣更利於您「理解」這個過程和技術原理。算法
學習交流：編程
- 即時通信開發交流3羣：185926912[推薦]segmentfault
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》瀏覽器
（本文同步發佈於：http://www.52im.net/thread-1890-1-1.html）安全
二、關於做者
翟志軍，我的博客地址：https://showme.codes/，Github：https://github.com/zacker330。感謝做者的原創分享。性能優化
三、相關文章
要理解HTTPS，須對HTTP協議有所瞭解，如下文章多是您須要的：
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
本文是IM通信安全知識系列文章中的第7篇，此係列總目錄以下：
《即時通信安全篇（一）：正確地理解和使用Android端加密算法》
《即時通信安全篇（四）：實例分析Android中密鑰硬編碼的風險》
四、一個引子
咱們先不了聊HTTP/HTTPS，咱們先從一個IM聊天軟件提及。
假設咱們想要實現A能發一個hello消息給B：
由於只是爲了方便講解原理，咱們要實現這個IM聊天的通訊功能，本文只考慮安全性問題。
那麼咱們的這個IM聊天功能，安全性上必需要達到：
A發給B的hello消息包，即便被中間人攔截到了，也沒法得知消息的內容。
好，帶着這個問題，我來繼續往下理解基本的通訊安全知識。
好，問題域已經定義好了（現實中固然不止這一種定義）。對於解決方案，很容易就想到了對消息進行加密。
題外話，可是隻有這一種方法嗎？我看未必，說不定在未來會出現一種物質打破當前世界的通訊假設，實現真正意義上的保密。
對於A與B這樣的簡單通訊模型，咱們很容易作出選擇： 對稱加密算法
這就是對稱加密算法，其中圖中的密鑰S同時扮演加密和解密的角色。具體細節不是本文範疇。
如上圖所示，只要這個密鑰S不公開給第三者，同時密鑰S足夠安全，咱們就解決了咱們一開始所定問題域了。由於世界上有且只有A與B知道如何加密和解密他們之間的消息。
可是，在WWW環境下，咱們的Web服務器的通訊模型沒有這麼簡單：
若是服務器端對全部的客戶端通訊都使用一樣的對稱加密算法，無異於沒有加密。那怎麼辦呢？即能使用對稱加密算法，又不公開密鑰？請讀者思考21秒鐘。^_^
答案是：Web服務器與每一個客戶端使用不一樣的對稱加密算法：
五、如何肯定對稱加密算法
慢着，另外一個問題來了，咱們的服務器端怎麼告訴客戶端該使用哪一種對稱加密算法？
固然是經過協商：
可是，你協商的過程是沒有加密的，仍是會被中間人攔截。那咱們再對這個協商過程進行對稱加密就行了，那你對協商過程加密的加密仍是沒有加密，怎麼辦？再加密不就行了……好吧，進行雞生蛋蛋生雞的問題了。
六、如何對協商過程進行加密
新問題來了，如何對協商過程進行加密？密碼學領域中，有一種稱爲「非對稱加密」的加密算法，特色是私鑰加密後的密文，只要是公鑰，均可以解密，可是公鑰加密後的密文，只有私鑰能夠解密。私鑰只有一我的有，而公鑰能夠發給全部的人。
雖然服務器端向A、B……的方向仍是不安全的，可是至少A、B向服務器端方向是安全的。
好了，如何協商加密算法的問題，咱們解決了：使用非對稱加密算法進行對稱加密算法協商過程。
這下，你明白爲何HTTPS同時須要對稱加密算法和非對稱加密算法了吧？
七、協商什麼加密算法
要達到Web服務器針對每一個客戶端使用不一樣的對稱加密算法，同時，咱們也不能讓第三者知道這個對稱加密算法是什麼，怎麼辦？
使用隨機數，就是使用隨機數來生成對稱加密算法。這樣就能夠作到服務器和客戶端每次交互都是新的加密算法、只有在交互的那一該才肯定加密算法。
這下，你明白爲何HTTPS協議握手階段會有這麼多的隨機數了吧。
八、如何獲得公鑰？
細心的人可能已經注意到了若是使用非對稱加密算法，咱們的客戶端A，B須要一開始就持有公鑰，要不無法開展加密行爲啊。
這下，咱們又遇到新問題了，如何讓A、B客戶端安全地獲得公鑰？
我能想到的方案只有這些：
方案1：服務器端將公鑰發送給每個客戶端；
方案2：服務器端將公鑰放到一個遠程服務器，客戶端能夠請求獲得。
咱們選擇方案1，由於方案2又多了一次請求，還要另外處理公鑰的放置問題。
九、公鑰被調包了怎麼辦？又是一個雞生蛋蛋生雞問題？
可是方案1有個問題：若是服務器端發送公鑰給客戶端時，被中間人調包了，怎麼辦？
我畫了張圖方便理解：
顯然，讓每一個客戶端的每一個瀏覽器默認保存全部網站的公鑰是不現實的。
十、使用第三方機構的公鑰解決雞生蛋蛋生雞問題
公鑰被調包的問題出現，是由於咱們的客戶端沒法分辨返回公鑰的人究竟是中間人，仍是真的服務器。這其實就是密碼學中提的身份驗證問題。
若是讓你來解決，你怎麼解決？若是你瞭解過HTTPS，會知道使用數字證書來解決。可是你想過證書的本質是什麼麼？請放下你對HTTPS已有的知識，本身嘗試找到解決方案。
我是這樣解決的。既然服務器須要將公鑰傳給客戶端，這個過程自己是不安全，那麼咱們爲何不對這個過程自己再加密一次？但是，你是使用對稱加密，仍是非對稱加密？這下好了，我感受又進了雞生蛋蛋生雞問題了。
問題的難點是若是咱們選擇直接將公鑰傳遞給客戶端的方案，咱們始終沒法解決公鑰傳遞被中間人調包的問題。
因此，咱們不能直接將服務器的公鑰傳遞給客戶端，而是第三方機構使用它的私鑰對咱們的公鑰進行加密後，再傳給客戶端。客戶端再使用第三方機構的公鑰進行解密。
下圖就是咱們設計的初版「數字證書」，證書中只有服務器交給第三方機構的公鑰，並且這個公鑰被第三方機構的私鑰加密了：
若是能解密，就說明這個公鑰沒有被中間人調包。由於若是中間人使用本身的私鑰加密後的東西傳給客戶端，客戶端是沒法使用第三方的公鑰進行解密的。
原理圖以下：
話到此，我覺得解決問題了。可是現實中HTTPS，還有一個數字簽名的概念，我無法理解它的設計理由。
原來，我漏掉了一個場景：
第三方機構不可能只給你一家公司製做證書，它也可能會給中間人這樣有壞心思的公司發放證書。這樣的，中間人就有機會對你的證書進行調包，客戶端在這種狀況下是沒法分辨出是接收的是你的證書，仍是中間人的。由於不論中間人，仍是你的證書，都能使用第三方機構的公鑰進行解密。
像下面這樣。。。
第三方機構向多家公司頒發證書的狀況：
客戶端能解密同一家第三機構頒發的全部證書：
最終致使其它持有同一家第三方機構證書的中間人能夠進行調包：
十一、數字簽名，解決同一機構頒發的不一樣證書被篡改問題
要解決這個問題，咱們首先要想清楚一個問題，辨別同一機構下不一樣證書的這個職責，咱們應該放在哪？
只能放到客戶端了。意思是，客戶端在拿到證書後，本身就有能力分辨證書是否被篡改了。如何纔能有這個能力呢？
咱們從現實中找靈感。好比你是HR，你手上拿到候選人的學歷證書，證書上寫了持證人，頒發機構，頒發時間等等，同時證書上，還寫有一個最重要的：證書編號！咱們怎麼鑑別這張證書是的真僞呢？只要拿着這個證書編號上相關機構去查，若是證書上的持證人與現實的這個候選人一致，同時證書編號也能對應上，那麼就說明這個證書是真實的。
咱們的客戶端能不能採用這個機制呢？像這樣：
但是，這個「第三方機構」究竟是在哪呢？是一個遠端服務？不可能吧？若是是個遠端服務，整個交互都會慢了。因此，這個第三方機構的驗證功能只能放在客戶端的本地了。
十二、客戶端本地怎麼驗證證書呢？
客戶端本地怎麼驗證證書呢？答案是證書自己就已經告訴客戶端怎麼驗證證書的真僞。
也就是證書上寫着如何根據證書的內容生成證書編號。客戶端拿到證書後根據證書上的方法本身生成一個證書編號，若是生成的證書編號與證書上的證書編號相同，那麼說明這個證書是真實的。
同時，爲避免證書編號自己又被調包，因此使用第三方的私鑰進行加密。
這地方有些抽象，咱們來個圖幫助理解：
證書的製做如上圖所示。證書中的「編號生成方法MD5」就是告訴客戶端：你使用MD5對證書的內容求值就能夠獲得一個證書編號。
當客戶端拿到證書後，開始對證書中的內容進行驗證，若是客戶端計算出來的證書編號與證書中的證書編號相同，則驗證經過：
可是第三方機構的公鑰怎麼跑到了客戶端的機器中呢？世界上這麼多機器。
其實呢，現實中，瀏覽器和操做系統都會維護一個權威的第三方機構列表（包括它們的公鑰）。由於客戶端接收到的證書中會寫有頒發機構，客戶端就根據這個頒發機構的值在本地找相應的公鑰。
題外話：
若是瀏覽器和操做系統這道防線被破了，就沒辦法。想一想當年本身裝過的很是規XP系統，都懼怕。
說到這裏，想必你們已經知道上文所說的，證書就是HTTPS中數字證書，證書編號就是數字簽名，而第三方機構就是指數字證書籤發機構（CA）。
1三、CA如何頒發數字證書給服務器端的？
當我聽到這個問題時，我誤覺得，咱們的SERVER須要髮網絡請求到CA部門的服務器來拿這個證書。 究竟是我理解能力問題，仍是。。
其實，問題應該是CA如何頒發給咱們的網站管理員，而咱們的管理員又如何將這個數字證書放到咱們的服務器上。
咱們如何向CA申請呢？每一個CA機構都大同小異，我在網上找了一個：
拿到證書後，咱們就能夠將證書配置到本身的服務器上了。那麼如何配置？這是具體細節了，留給你們google了。
1四、也許咱們須要整理一下思路
咱們經過推算的方式嘗試還原HTTPS的設計過程。這樣，咱們也就明白了爲何HTTPS比HTTP多那麼屢次的交互，爲何HTTPS的性能會差，以及找到HTTPS的性能優化點。
而上面一大堆工做都是爲了讓客戶端與服務器端安全地協商出一個對稱加密算法。這就是HTTPS中的SSL/TLS協議主要乾的活。剩下的就是通訊時雙方使用這個對稱加密算法進行加密解密。
如下是一張HTTPS協議的真實交互圖（從網上copy的，忘了從哪了，若是侵權麻煩告知）：
1五、能不能用一句話總結HTTPS？
答案是不能，由於HTTPS自己實在太複雜。
可是我仍是嘗試使用一段話來總結HTTPS:
HTTPS要使客戶端與服務器端的通訊過程獲得安全保證，必須使用的對稱加密算法，可是協商對稱加密算法的過程，須要使用非對稱加密算法來保證安全，然而直接使用非對稱加密的過程自己也不安全，會有中間人篡改公鑰的可能性，因此客戶端與服務器不直接使用公鑰，而是使用數字證書籤發機構頒發的證書來保證非對稱加密過程自己的安全。這樣經過這些機制協商出一個對稱加密算法，就此雙方使用該算法進行加密解密。從而解決了客戶端與服務器端之間的通訊安全問題。
好長的一段話。
1六、後記
以上是我的爲理解HTTPS而編造出來的自圓其說的見解。頂多只能算是HTTPS的科普文章。若有錯誤，請指出，萬分感謝。
那麼，我爲何會以爲以這種方式理解HTTPS會更容易呢？我我的給出的答案是：當你本身爲一家人作一次菜時，你就會理解媽媽每天作菜的不易了。
1七、參考資料
《理解 HTTPS》
附錄：更多通訊安全方面的文章
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯繫實際：一套典型的IM通訊協議設計詳解（含安全層設計）》
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通信服務的技術實踐分享》
《Web端即時通信安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《即時通信安全篇（七）：若是這樣來理解HTTPS原理，一篇就夠了》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-1890-1-1.html）
- 1. HTTPS協議，看這一篇就夠了
- 2. [譯] 理解CORS這一篇就夠了
- 3. 瞭解 MongoDB 看這一篇就夠了
- 4. 瞭解爬蟲，這一篇就夠了！
- 5. 瞭解HandlerThread這一篇就夠了
- 6. nginx 這一篇就夠了
- 7. Ajax這一篇就夠了????
- 8. 解密Cookie，這一篇就夠了
- 9. 圖解Word2vec，讀這一篇就夠了
- 10. 看這一篇就夠了！-Ajax詳解
- 更多相關文章...
- • CAP理論是什麼？ - NoSQL教程
- • 物理地址（MAC地址）是什麼？ - TCP/IP教程
- • 三篇文章瞭解 TiDB 技術內幕——說存儲
- • 三篇文章瞭解 TiDB 技術內幕 —— 說計算
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Appium入門
- 2. Spring WebFlux 源碼分析(2)-Netty 服務器啓動服務流程 --TBD
- 3. wxpython入門第六步（高級組件）
- 4. CentOS7.5安裝SVN和可視化管理工具iF.SVNAdmin
- 5. jedis 3.0.1中JedisPoolConfig對象缺少setMaxIdle、setMaxWaitMillis等方法，問題記錄
- 6. 一步一圖一代碼，一定要讓你真正徹底明白紅黑樹
- 7. 2018-04-12—（重點）源碼角度分析Handler運行原理
- 8. Spring AOP源碼詳細解析
- 9. Spring Cloud（1）
- 10. python簡單爬去油價信息發送到公衆號
- 1. HTTPS協議，看這一篇就夠了
- 2. [譯] 理解CORS這一篇就夠了
- 3. 瞭解 MongoDB 看這一篇就夠了
- 4. 瞭解爬蟲，這一篇就夠了！
- 5. 瞭解HandlerThread這一篇就夠了
- 6. nginx 這一篇就夠了
- 7. Ajax這一篇就夠了????
- 8. 解密Cookie，這一篇就夠了
- 9. 圖解Word2vec，讀這一篇就夠了
- 10. 看這一篇就夠了！-Ajax詳解