本文原作者“虞大膽的嘰嘰喳喳”，原文鏈接：jianshu.com/p/8861da5734ba，感謝原作者。
1、引言
很多人一提到 HTTPS，第一反應(yīng)就是安全，對于普通用戶來說這就足夠了；
但對于程序員，很有必要了解下 HTTP 到底有什么問題？以及HTTPS 是如何解決這些問題的？其背后的解決思路和方法是什么？
本文只做簡單的描述，力求簡單明了的闡明主要內(nèi)容，因為HTTPS 體系非常復(fù)雜，這么短的文字是無法做到很詳細(xì)和精準(zhǔn)的分析。想要詳細(xì)了解HTTPS的方方面面，可以閱讀此前即時通訊網(wǎng)整理的《即時通訊安全篇（七）：如果這樣來理解HTTPS，一篇就夠了》一文。
（本文同步發(fā)布于：http://www.52im.net/thread-2027-1-1.html）
2、HTTPS相關(guān)文章
《即時通訊安全篇（七）：如果這樣來理解HTTPS，一篇就夠了》
《一文讀懂Https的安全性原理、數(shù)字證書、單項認(rèn)證、雙項認(rèn)證等》
《HTTPS時代已來，打算更新你的HTTP服務(wù)了嗎？》
《蘋果即將強制實施 ATS，你的APP準(zhǔn)備好切換到HTTPS了嗎？》
3、對HTTPS性能的理解
HTTP 有典型的幾個問題，第一就是性能，HTTP 是基于 TCP 的，所以網(wǎng)絡(luò)層就不說了（快慢不是 HTTP 的問題）。
比較嚴(yán)重的問題在于 HTTP 頭是不能壓縮的，每次要傳遞很大的數(shù)據(jù)包。另外 HTTP 的請求模型是每個連接只能支持一個請求，所以會顯得很慢。
那么 HTTPS 是解決這些問題的嗎？
不是，實際上 HTTPS 是在 HTTP 協(xié)議上又加了一層，會更慢，相信未來會逐步解決的。同時 HTTPS 用到了很多加密算法，這些算法的執(zhí)行也是會影響速度的。
為什么說 HTTPS 提升了性能呢？因為只有支持了 HTTPS，才能部署 HTTP/2，而 HTTP/2 協(xié)議會提升速度，能夠有效減輕客戶端和服務(wù)器端的壓力，讓響應(yīng)更快速。有關(guān)HTTP/2詳細(xì)文章可以看看《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計思路》、《腦殘式網(wǎng)絡(luò)編程入門(四)：快速理解HTTP/2的服務(wù)器推送(Server Push)》，這里只要知道一點：HTTP/2 能夠加快速度的主要原因在于多路復(fù)用，同一個連接能夠并行發(fā)送和接收多個請求。
4、傳統(tǒng)HTTP的安全性問題
當(dāng)用戶在瀏覽器輸入一個網(wǎng)址的時候，在地址欄上看到小鎖圖標(biāo)，就會安心，潛意識的認(rèn)為自己的上網(wǎng)行為是安全的，當(dāng)然對于小白用戶來說可能還不明白，但是未來會慢慢改善的（萬事開頭難嘛）。
那么 HTTP 到底有什么安全問題呢，看幾個例子：
1）由于互聯(lián)網(wǎng)傳輸是能夠被攔截的，所以假如你的上網(wǎng)方式被別人控制了（沒有絕對的安全），那么你的任何行為和信息攻擊者都會知道，比如我們連上一個匿名的 WIFI，當(dāng)你上網(wǎng)的時候，輸入的網(wǎng)站密碼可能就已經(jīng)泄漏了；
2）當(dāng)我們在上一個網(wǎng)站的時候，莫名其妙跳出一個廣告（這個廣告并不是這個網(wǎng)站的），那是因為訪問的頁面可能被運營商強制修改了（加入了他自己的內(nèi)容，比如廣告）。
HTTP 最大的問題就在于數(shù)據(jù)沒有加密，以及通信雙方?jīng)]有辦法進(jìn)行身份驗證（ confidentiality and authentication），由于數(shù)據(jù)沒有加密，那么只要數(shù)據(jù)包被攻擊者劫持，信息就泄漏了。
身份驗證的意思就是服務(wù)器并不知道連接它的客戶端到底是誰，而客戶端也不確定他連接的服務(wù)器就是他想連接的服務(wù)器，雙方之間沒有辦法進(jìn)行身份確認(rèn)。
有關(guān)HTTP比較好的文章，可以看看：
《網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計思路》
《腦殘式網(wǎng)絡(luò)編程入門(三)：HTTP協(xié)議必知必會的一些知識》
5、HTTPS 背后的密碼學(xué)
為了解決 HTTP 的兩個核心問題，HTTPS 出現(xiàn)了，HTTPS 包含了核心的幾個部分：TLS 協(xié)議、OpenSSL，證書。
什么是 OpenSSL 呢，它實現(xiàn)了世界上非常重要和多的密碼算法，而密碼學(xué)是解決問題最重要的一個環(huán)節(jié)。
TLS 最重要的是握手的處理方式。證書的體系也很大，但是他們背后都是基于同樣的密碼學(xué)。
1）既然 HTTP 沒有數(shù)據(jù)加密，那么我們就加密下，對稱加密算法上場了，這種算法加密和解密要使用同一個密鑰，通信雙方需要知道這個密鑰（或者每次協(xié)商一個），實際上這種方法不太可能，這涉及到密鑰保密和配送的問題，一旦被攻擊者知道了密鑰，那么傳輸?shù)臄?shù)據(jù)等同沒有加密。
2）這個時候非對稱加密算法上場了，公鑰和私鑰是分開的，客戶端保存公鑰，服務(wù)器保存私鑰（不會公開），這時候好像能夠完美解決問題了。
但實際上會存在兩個問題，第一就是非對稱加密算法運算很慢，第二就是會遇到中間人攻擊問題。
先說說中間人攻擊的問題，假如使用非對稱加密算法，對于客戶端來說它拿到的公鑰可能并不是真正服務(wù)器的公鑰，因為客戶端上網(wǎng)的時候可能不會仔細(xì)分辨某個公鑰是和某個公司綁定的，假如錯誤的拿到攻擊者的公鑰，那么他發(fā)送出去的數(shù)據(jù)包被劫持后，攻擊者用自己的私鑰就能反解了。
3）接下來如何解決公鑰認(rèn)證的問題呢？證書出現(xiàn)了，證書是由 CA 機構(gòu)認(rèn)證的，客戶端都充分信任它，它能夠證明你拿到的公鑰是特定機構(gòu)的，然后就能使用非對稱加密算法加密了。
證書是怎么加密的呢？實際上也是通過非對稱加密算法，但是區(qū)別在于證書是用私鑰加密，公鑰解密。
CA 機構(gòu)會用自己的私鑰加密服務(wù)器用戶的公鑰，而客戶端則用 CA 機構(gòu)的公鑰解出服務(wù)器的公鑰。聽上去有點暈，仔細(xì)體會下。這方面的知識，可以詳細(xì)閱讀：《即時通訊安全篇（七）：如果這樣來理解HTTPS，一篇就夠了》。
4）上面說了非對稱加密算法加密解密非常耗時，對于 HTTP 這樣的大數(shù)據(jù)包，速度就更慢了，這時候可以使用對稱加密算法，這個密鑰是由客戶端和服務(wù)器端協(xié)商出來，并由服務(wù)器的公鑰進(jìn)行加密傳遞，所以不存在安全問題。
5）另外客戶端拿到證書后會驗證證書是否正確，它驗證的手段就是通過 Hash 摘要算法，CA 機構(gòu)會將證書信息通過 Hash 算法運算后再用私鑰加密，客戶端用 CA 的公鑰解出后，再計算證書的 Hash 摘要值，兩者一致就說明驗證身份通過。
6）HTTPS 解決的第三個問題是完整性問題，就是信息有沒有被篡改（信息能夠被反解），用的是 HMAC 算法，這個算法和 Hash 方法差不多，但是需要傳遞一個密鑰，這個密鑰就是客戶端和服務(wù)器端上面協(xié)商出來的。
附錄：更多安全方面的文章
《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時通訊安全篇（二）：探討組合加密算法在IM中的應(yīng)用》
《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》
《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風(fēng)險》
《即時通訊安全篇（五）：對稱加密技術(shù)在Android平臺上的應(yīng)用實踐》
《即時通訊安全篇（六）：非對稱加密技術(shù)的原理與應(yīng)用實踐》
《傳輸層安全協(xié)議SSL/TLS的Java平臺實現(xiàn)簡介和Demo演示》
《理論聯(lián)系實際：一套典型的IM通信協(xié)議設(shè)計詳解（含安全層設(shè)計）》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通訊服務(wù)的技術(shù)實踐分享》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端安全通信的利器——端到端加密（E2EE）技術(shù)詳解》
《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《通俗易懂：一篇掌握即時通訊的消息傳輸安全原理》
《IM開發(fā)基礎(chǔ)知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《快速讀懂量子通信、量子加密技術(shù)》
《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》
《一分鐘理解 HTTPS 到底解決了什么問題》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-2027-1-1.html）