本文由ELab技術團隊分享圈匆，原題“探秘HTTPS”漠另，有修訂和改動。
1跃赚、引言
對于IM開發(fā)者來說笆搓，IM里最常用的通信技術就是Socket長連接和HTTP短連接（通常一個主流im會是這兩種通信手段的結合）。從通信安全的角度來說纬傲，Socket長連接的安全性满败，就是基于SSL/TLS加密的TCP協(xié)議來實現(xiàn)的（比如微信的mmtls，見《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》）叹括；而對于HTTP短連接的安全性算墨，也就是HTTPS了。
到底什么是HTTPS汁雷？為什么要用HTTPS净嘀？今天就借此機會报咳，跟大家一起深入學習一下HTTPS的相關知識，包括HTTP的發(fā)展歷程挖藏、HTTP遇到的問題暑刃、對稱與非對稱加密算法、數(shù)字簽名膜眠、第三方證書頒發(fā)機構等概念岩臣。
（本文已同步發(fā)布于：http://www.52im.net/thread-3897-1-1.html）
2、系列文章
本文是IM通訊安全知識系列文章中的第9篇柴底，此系列總目錄如下：
《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《即時通訊安全篇（五）：對稱加密技術在Android平臺上的應用實踐》
《即時通訊安全篇（七）：如果這樣來理解HTTPS原理婿脸，一篇就夠了》
《即時通訊安全篇（八）：你知道，HTTPS用的是對稱加密還是非對稱加密柄驻？》
《即時通訊安全篇（九）：為什么要用HTTPS狐树？深入淺出，探密短連接的安全性》（本文）
3鸿脓、寫在前面
說到HTTPS抑钟，那就得回到HTTP協(xié)議。
對于HTTP協(xié)議野哭，大家肯定都熟得不能再熟了在塔。那么HTTPS和HTTP的區(qū)別大家了解嗎？
對于這個經(jīng)典的面試題拨黔，大部分人會這么回答：
1）HTTPS比HTTP多了一個S(Secure)：也就是說HTTPS是安全版的HTTP蛔溃；
2）端口號不同：HTTP使用80端口，HTTPS使用443端口篱蝇；
3）加密算法：HTTPS用的是非對稱加密算法贺待。
上面的回答能給幾分？等看完本文我們可以再回頭來看下這個回答零截。
那么麸塞，HTTPS是如何實現(xiàn)安全的短連接數(shù)據(jù)傳輸呢？想徹底搞明白這個問題涧衙，還是要從HTTP的發(fā)展歷程說起 ......
4哪工、HTTP協(xié)議回顧
4.1 基礎常識
HTTP是Hypertext Transfer Protocal 的縮寫，中文全稱是超文本傳輸協(xié)議（詳見《深入淺出弧哎，全面理解HTTP協(xié)議》）雁比。
通俗了解釋就是：
1）超文本是指包含但不限于文本外的圖片、音頻傻铣、視頻等多媒體資源章贞；
2）協(xié)議是通信雙方約定好的數(shù)據(jù)傳輸格式以及通信規(guī)則。
HTTP是TCP/IP協(xié)議簇的最高層——應用層協(xié)議：
▲ 上圖引用自《深入淺出非洲，全面理解HTTP協(xié)議》
瀏覽器和服務器在使用HTTP協(xié)議相互傳遞超文本數(shù)據(jù)時，將數(shù)據(jù)放入報文體內(nèi)，同時填充首部（請求頭或響應頭）構成完整HTTP報文并交到下層傳輸層懂从，之后每一層加上相應的首部（控制部分）便一層層的下發(fā)艰垂，最終由物理層將二進制數(shù)據(jù)以電信號的形式發(fā)送出去。
HTTP的請求如下圖所示：
▲ 上圖引用自《深入淺出梦染，全面理解HTTP協(xié)議》
HTTP報文結構如下
4.2 發(fā)展歷程
HTTP的發(fā)展歷程如下：
由HTTP的發(fā)展歷程來看赡麦，最開始版本的HTTP(HTTP1.0)在每次建立TCP連接后只能發(fā)起一次HTTP請求，請求完畢就釋放TCP連接帕识。
我們都知道TCP連接的建立需要經(jīng)過三次握手的過程泛粹，而每次發(fā)送HTTP請求都需要重新建立TCP連接，毫無疑問是很低效的肮疗。所以HTTP1.1改善了這一點晶姊，使用長連接的機制，也就是“一次TCP連接伪货，N次HTTP請求”们衙。
HTTP協(xié)議的長連接和短連接，實質上是 TCP 協(xié)議的長連接和短連接碱呼。
在使用長連接的情況下蒙挑，當一個網(wǎng)頁打開完成后，客戶端和服務器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關閉愚臀，客戶端再次訪問這個服務器時忆蚀，會繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會永久保持連接姑裂，它有一個保持時間馋袜，可以在不同的服務器軟件（如Apache）中設定這個時間。實現(xiàn)長連接需要客戶端和服務端都支持長連接炭分。
PS：對于IM開發(fā)者來說桃焕，為了與Socket長連接通道區(qū)分，通常認為HTTP就是“短連接”（雖然這個“短連接”不一定真的“短”）捧毛。
HTTP1.0若要開啟長連接观堂，需要加上Connection: keep-alive請求頭。有關HTTP協(xié)議的詳細發(fā)展歷程可閱讀《一文讀懂HTTP協(xié)議的歷史演變和設計思路》一文呀忧。
4.3 安全問題
隨著HTTP越來越廣泛的使用师痕，HTTP的安全性問題也逐漸暴露。
回憶一下多年前遍地都是的運營商劫持而账，當你訪問一個本來很正常的網(wǎng)頁胰坟，但頁面上卻莫名其妙出現(xiàn)了一些廣告標簽、跳轉腳本泞辐、欺騙性的紅包按鈕笔横，甚至有時候本來要下載一個文件竞滓，最后下載下來卻變成了另外一個完全不同的東西，這些都是被運營商劫持了HTTP明文數(shù)據(jù)的現(xiàn)象吹缔。
下圖就是似曾相識的運營商劫持效果圖：
PS：關于運營商劫持問題商佑，可以詳細閱讀《全面了解移動端DNS域名劫持等雜癥：原理、根源厢塘、HttpDNS解決方案等》茶没。
HTTP主要有以下3點安全性問題：
歸納一下就是：
1）數(shù)據(jù)保密性問題：因為HTTP無狀態(tài)，而且又是明文傳輸晚碾，所有數(shù)據(jù)內(nèi)容都在網(wǎng)絡中裸奔抓半，包用戶括身份信息、支付賬號與密碼格嘁。這些敏感信息極易泄露造成安全隱患笛求；
2）數(shù)據(jù)完整性問題：HTTP數(shù)據(jù)包在到達目的主機前會經(jīng)過很多轉發(fā)設備，每一個設備節(jié)點都可能會篡改或調(diào)包信息讥蔽，無法驗證數(shù)據(jù)的完整性涣易；
3）身份校驗問題：有可能遭受中間人攻擊，我們無法驗證通信的另一方就是我們的目標對象冶伞。
因此新症，為了保證數(shù)據(jù)傳輸?shù)陌踩裕仨氁獙TTP數(shù)據(jù)進行加密响禽。
5徒爹、常見的加密方式
5.1 基本情況
常見的加密方式分為三種：
1）對稱加密；
2）非對稱加密芋类；
3）數(shù)字摘要隆嗅。
前兩種適合數(shù)據(jù)傳輸加密，而數(shù)字摘要不可逆的特性常被用于數(shù)字簽名侯繁。
接下來胖喳，我們逐一簡要學習一下這三種常見的加密方法。
5.2 對稱加密
對稱加密也稱為密鑰加密或單向加密贮竟，就是使用同一套密鑰來進行加密和解密丽焊。密鑰可以理解為加密算法。
對稱加密圖示如下：
廣泛使用的對稱加密有：
對稱加密算法的優(yōu)缺點和適用場景：
1）優(yōu)點：算法公開咕别、簡單技健，加密解密容易，加密速度快惰拱，效率高雌贱；
2）缺點：相對來說不算特別安全，只有一把鑰匙，密文如果被攔截欣孤，且密鑰也被劫持馋没，那么，信息很容易被破譯导街；
3）適用場景：加解密速度快披泪、效率高纤子，因此適用于大量數(shù)據(jù)的加密場景搬瑰。由于如何傳輸密鑰是較為頭痛的問題，因此適用于無需進行密鑰交換的場景控硼，如內(nèi)部系統(tǒng)泽论，事先就可以直接確定密鑰。
PS：可以在線體驗對稱加密算法卡乾，鏈接是：http://www.jsons.cn/textencrypt/
小知識：base64編碼也屬于對稱加密哦翼悴！
5.3 非對稱加密
非對稱加密使用一對密鑰（公鑰和私鑰）進行加密和解密。
非對稱加密可以在不直接傳遞密鑰的情況下幔妨，完成解密鹦赎，具體步驟如下：
1）乙方生成兩把密鑰（公鑰和私鑰）。公鑰是公開的误堡，任何人都可以獲得古话，私鑰則是保密的；
2）甲方獲取乙方的公鑰锁施，然后用它對信息加密陪踩；
3）乙方得到加密后的信息，用私鑰解密悉抵。
以最典型的非對稱加密算法RSA為例肩狂，舉個例子：
想要徹底搞懂RSA，需要了解數(shù)論的知識姥饰，全部推導過程RSA加密算法傻谁。簡單介紹思路：使用兩個超大質數(shù)以及其乘積作為生成公鑰和私鑰的材料，想要從公鑰推算出私鑰是非常困難的（需要對超大數(shù)因式分解為兩個很大質數(shù)的乘積）列粪。目前被破解的最長RSA密鑰是768個二進制位审磁。也就是說，長度超過768位的密鑰篱竭，還無法破解（至少沒人公開宣布）力图。因此可以認為，1024位的RSA密鑰基本安全掺逼，2048位的密鑰極其安全吃媒。
非對稱加密算法的優(yōu)缺點和適用場景：
1）優(yōu)點：強度高、安全性強于對稱加密算法、無需傳遞私鑰導致沒有密鑰泄露風險赘那；
2）缺點：計算量大刑桑、速度慢；
3）適用場景：適用于需要密鑰交換的場景募舟，如互聯(lián)網(wǎng)應用祠斧，無法事先約定密鑰。
實踐應用過程中拱礁，其實可以與對稱加密算法結合：
1）利用非對稱加密算法安全性較好的特點來傳遞對稱加密算法的密鑰琢锋。
2）利用對稱加密算法加解密速度快的特點，進行數(shù)據(jù)內(nèi)容比較大的加密場景的加密（如HTTPS）呢灶。
PS：對于IM開發(fā)者來說吴超，《探討組合加密算法在IM中的應用》一文值得一讀。
5.4 如何選擇鸯乃？
1）如果選擇對稱加密：
HTTP請求方使用對稱算法加密數(shù)據(jù)鲸阻，那么為了接收方能夠解密，發(fā)送方還需要把密鑰一同傳遞到接收方缨睡。在傳遞密鑰的過程中還是可能遭到嗅探攻擊鸟悴，攻擊者竊取密鑰后依然可以解密從而得到發(fā)送的數(shù)據(jù)，所以這種方案不可行奖年。
2）如果選擇非對稱加密：
接收方保留私鑰细诸，把公鑰傳遞給發(fā)送方。發(fā)送方用公鑰來加密數(shù)據(jù)拾并，接收方使用私鑰解密數(shù)據(jù)揍堰。攻擊者雖然不能直接獲取這些數(shù)據(jù)（因為沒有私鑰），但是可以通過攔截傳遞的公鑰嗅义，然后把自己的公鑰傳給發(fā)送方屏歹，再用自己的私鑰對發(fā)送方發(fā)送數(shù)據(jù)進行解密。
整個過程通信雙方都不知道中間人的存在之碗，但是中間人能夠獲得完整的數(shù)據(jù)信息蝙眶。
3）兩種加密方法的混合：
先使用非對稱加密算法加密并傳遞對稱加密的密鑰，然后雙方通過對稱加密方式加密要發(fā)送的數(shù)據(jù)褪那。看起來沒什么問題幽纷，但事實是這樣嗎？
中間人依然可以攔截公鑰的傳遞博敬，并以自己的公鑰作為替換友浸，治標不治本。
想要治本偏窝，就要找到一個第三方公證人來證明公鑰沒有被替換收恢，因此就引出了數(shù)字證書的概念武学，這也是下一節(jié)將分享的內(nèi)容。
6伦意、數(shù)字證書
6.1 CA機構
CA就是 Certificate Authority火窒，即頒發(fā)數(shù)字證書的機構。
作為受信任的第三方驮肉，CA承擔公鑰體系中公鑰的合法性檢驗的責任熏矿。
證書就是源服務器向可信任的第三方機構申請的數(shù)據(jù)文件。這個證書除了表明這個域名是屬于誰的离钝，頒發(fā)日期等票编，還包括了第三方證書的私鑰。
服務器將公鑰放在數(shù)字證書中奈辰，只要證書是可信的栏妖，公鑰就是可信的。
下面兩圖是飛書域名的證書中部分內(nèi)容的信：
6.2 數(shù)字簽名
摘要算法：一般用哈希函數(shù)來實現(xiàn)奖恰，可以理解成一種定長的壓縮算法，它能把任意長度的數(shù)據(jù)壓縮到固定長度宛裕。這好比是給數(shù)據(jù)加了一把鎖瑟啃，對數(shù)據(jù)有任何微小的改動都會使摘要變得截然不同。
通常情況下：數(shù)字證書的申請人（服務器）將生成由私鑰和公鑰以及證書請求文件（Certificate Signing Request揩尸，CSR）組成的密鑰對蛹屿。CSR是一個編碼的文本文件，其中包含公鑰和其他將包含在證書中的信息（例如：域名岩榆、組織错负、電子郵件地址等）。密鑰對和CSR生成通常在將要安裝證書的服務器上完成勇边，并且 CSR 中包含的信息類型取決于證書的驗證級別犹撒。與公鑰不同，申請人的私鑰是安全的粒褒，永遠不要向 CA（或其他任何人）展示识颊。
生成 CSR 后：申請人將其發(fā)送給 CA，CA 會驗證其包含的信息是否正確奕坟，如果正確祥款，則使用頒發(fā)的私鑰對證書進行數(shù)字簽名，然后將簽名放在證書內(nèi)隨證書一起發(fā)送給申請人月杉。
在SSL握手階段：瀏覽器在收到服務器的證書后刃跛，使用CA的公鑰進行解密，取出證書中的數(shù)據(jù)苛萎、數(shù)字簽名以及服務器的公鑰桨昙。如果解密成功跌帐，則可驗證服務器身份真實。之后瀏覽器再對數(shù)據(jù)做Hash運算绊率，將結果與數(shù)字簽名作對比谨敛，如果一致則可以認為內(nèi)容沒有收到篡改。
對稱加密和非對稱加密是公鑰加密滤否、私鑰解密脸狸， 而數(shù)字簽名正好相反——是私鑰加密（簽名）、公鑰解密（驗證）藐俺，如下圖所示炊甲。
限于篇幅，關于數(shù)字證書的內(nèi)容本文就不再贅述欲芹，想詳細了解的可以閱讀：
1）一文讀懂Https的安全性原理卿啡、數(shù)字證書、單項認證菱父、雙項認證等颈娜；
2）你知道，HTTPS用的是對稱加密還是非對稱加密浙宜？官辽；
3）如果這樣來理解HTTPS，一篇就夠了粟瞬。
7同仆、為什么要使用HTTPS
《圖解HTTP》一書中提到HTTPS就是身披SSL外殼的HTTP。
7.1 SSL
SSL 在1999年被更名為TLS裙品。
所以說：HTTPS 并不是一項新的應用層協(xié)議俗批，只是 HTTP 通信接口部分由 SSL 和 TLS 替代而已。
具體就是：HTTP 會先直接和 TCP 進行通信市怎，而HTTPS 會演變?yōu)橄群?SSL 進行通信岁忘，然后再由 SSL 和 TCP 進行通信。
SSL是一個獨立的協(xié)議焰轻，不只有 HTTP 可以使用臭觉，其他應用層協(xié)議也可以使用，比如FTP辱志、SMTP都可以使用SSL來加密蝠筑。
7.2 HTTPS請求流程
HTTPS請求全流程如下圖：
如上圖所示：
1）用戶在瀏覽器發(fā)起HTTPS請求，默認使用服務端的443端口進行連接揩懒；
2）HTTPS需要使用一套CA 數(shù)字證書什乙，證書內(nèi)會附帶一個服務器的公鑰Pub，而與之對應的私鑰Private保留在服務端不公開已球；
3）服務端收到請求臣镣，返回配置好的包含公鑰Pub的證書給客戶端辅愿；
4）客戶端收到證書，校驗合法性忆某，主要包括是否在有效期內(nèi)点待、證書的域名與請求的域名是否匹配，上一級證書是否有效（遞歸判斷弃舒，直到判斷到系統(tǒng)內(nèi)置或瀏覽器配置好的根證書）癞埠，如果不通過，則顯示HTTPS警告信息聋呢，如果通過則繼續(xù)苗踪；
5）客戶端生成一個用于對稱加密的隨機Key，并用證書內(nèi)的公鑰Pub進行加密削锰，發(fā)送給服務端通铲；
6）服務端收到隨機Key的密文，使用與公鑰Pub配對的私鑰Private進行解密器贩，得到客戶端真正想發(fā)送的隨機Key颅夺；
7）服務端使用客戶端發(fā)送過來的隨機Key對要傳輸?shù)腍TTP數(shù)據(jù)進行對稱加密，將密文返回客戶端磨澡；
8）客戶端使用隨機Key對稱解密密文碗啄，得到HTTP數(shù)據(jù)明文；
9）后續(xù)HTTPS請求使用之前交換好的隨機Key進行對稱加解密稳摄。
7.3 HTTPS到底解決了什么問題
HTTPS確實解決了HTTP的三個安全性問題：
1）?保密性：結合非對稱加密和對稱加密實現(xiàn)保密性。用非對稱加密方式加密對稱加密的秘鑰饲宿，再用對稱加密方式加密數(shù)據(jù)厦酬；
2）?完整性：通過第三方CA的數(shù)字簽名解決完整性問題；
3）?身份校驗：通過第三方CA的數(shù)字證書驗證服務器的身份瘫想。
7.4 HTTPS優(yōu)缺點
最后我們總結一下HTTPS的優(yōu)缺點：
可以看到：HTTPS的確是當今安全傳輸HTTP的最優(yōu)解仗阅，但他并不是完美的，仍會有漏洞国夜。
8减噪、參考資料
[5]?你知道一個TCP連接上能發(fā)起多少個HTTP請求嗎车吹？
[8]?你知道，HTTPS用的是對稱加密還是非對稱加密窄驹？
[9]?HTTPS時代已來朝卒，打算更新你的HTTP服務了嗎？
[10]?一篇讀懂HTTPS：加密原理乐埠、安全邏輯抗斤、數(shù)字證書等
[11]?全面了解移動端DNS域名劫持等雜癥：原理囚企、根源、HttpDNS解決方案等
（本文已同步發(fā)布于：http://www.52im.net/thread-3897-1-1.html）
