本文由ELab技術(shù)團(tuán)隊(duì)分享，原題“探秘HTTPS”，有修訂和改動(dòng)。

1、引言

對(duì)于IM開發(fā)者來(lái)說(shuō)，IM里最常用的通信技術(shù)就是Socket長(zhǎng)連接和HTTP短連接（通常一個(gè)主流im會(huì)是這兩種通信手段的結(jié)合）。從通信安全的角度來(lái)說(shuō)，Socket長(zhǎng)連接的安全性，就是基于SSL/TLS加密的TCP協(xié)議來(lái)實(shí)現(xiàn)的（比如微信的mmtls，見(jiàn)《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》）；而對(duì)于HTTP短連接的安全性，也就是HTTPS了。

到底什么是HTTPS？為什么要用HTTPS？今天就借此機(jī)會(huì)，跟大家一起深入學(xué)習(xí)一下HTTPS的相關(guān)知識(shí)，包括HTTP的發(fā)展歷程、HTTP遇到的問(wèn)題、對(duì)稱與非對(duì)稱加密算法、數(shù)字簽名、第三方證書頒發(fā)機(jī)構(gòu)等概念。

學(xué)習(xí)交流：

- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK?

（本文已同步發(fā)布于：http://www.52im.net/thread-3897-1-1.html）

2、系列文章

本文是IM通訊安全知識(shí)系列文章中的第9篇，此系列總目錄如下：

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

• 《即時(shí)通訊安全篇（二）：探討組合加密算法在IM中的應(yīng)用》

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

• 《即時(shí)通訊安全篇（四）：實(shí)例分析Android中密鑰硬編碼的風(fēng)險(xiǎn)》

• 《即時(shí)通訊安全篇（五）：對(duì)稱加密技術(shù)在Android平臺(tái)上的應(yīng)用實(shí)踐》

• 《即時(shí)通訊安全篇（六）：非對(duì)稱加密技術(shù)的原理與應(yīng)用實(shí)踐》

• 《即時(shí)通訊安全篇（七）：如果這樣來(lái)理解HTTPS原理，一篇就夠了》

• 《即時(shí)通訊安全篇（八）：你知道，HTTPS用的是對(duì)稱加密還是非對(duì)稱加密？》

• 《即時(shí)通訊安全篇（九）：為什么要用HTTPS？深入淺出，探密短連接的安全性》（* 本文）

3、寫在前面

說(shuō)到HTTPS，那就得回到HTTP協(xié)議。

對(duì)于HTTP協(xié)議，大家肯定都熟得不能再熟了。那么HTTPS和HTTP的區(qū)別大家了解嗎？

對(duì)于這個(gè)經(jīng)典的面試題，大部分人會(huì)這么回答：

• 1）HTTPS比HTTP多了一個(gè)S(Secure)：也就是說(shuō)HTTPS是安全版的HTTP；

• 2）端口號(hào)不同：HTTP使用80端口，HTTPS使用443端口；

• 3）加密算法：HTTPS用的是非對(duì)稱加密算法。

上面的回答能給幾分？等看完本文我們可以再回頭來(lái)看下這個(gè)回答。

那么，HTTPS是如何實(shí)現(xiàn)安全的短連接數(shù)據(jù)傳輸呢？想徹底搞明白這個(gè)問(wèn)題，還是要從HTTP的發(fā)展歷程說(shuō)起 ......

4、HTTP協(xié)議回顧

4.1 基礎(chǔ)常識(shí)

HTTP是Hypertext Transfer Protocal 的縮寫，中文全稱是超文本傳輸協(xié)議（詳見(jiàn)《深入淺出，全面理解HTTP協(xié)議》）。

通俗了解釋就是：

• 1）超文本是指包含但不限于文本外的圖片、音頻、視頻等多媒體資源；

• 2）協(xié)議是通信雙方約定好的數(shù)據(jù)傳輸格式以及通信規(guī)則。

HTTP是TCP/IP協(xié)議簇的最高層——應(yīng)用層協(xié)議：

▲ 上圖引用自《深入淺出，全面理解HTTP協(xié)議》

瀏覽器和服務(wù)器在使用HTTP協(xié)議相互傳遞超文本數(shù)據(jù)時(shí)，將數(shù)據(jù)放入報(bào)文體內(nèi)，同時(shí)填充首部（請(qǐng)求頭或響應(yīng)頭）構(gòu)成完整HTTP報(bào)文并交到下層傳輸層，之后每一層加上相應(yīng)的首部（控制部分）便一層層的下發(fā)，最終由物理層將二進(jìn)制數(shù)據(jù)以電信號(hào)的形式發(fā)送出去。

HTTP的請(qǐng)求如下圖所示：

▲ 上圖引用自《深入淺出，全面理解HTTP協(xié)議》

HTTP報(bào)文結(jié)構(gòu)如下：

4.2 發(fā)展歷程

HTTP的發(fā)展歷程如下：

由HTTP的發(fā)展歷程來(lái)看，最開始版本的HTTP(HTTP1.0)在每次建立TCP連接后只能發(fā)起一次HTTP請(qǐng)求，請(qǐng)求完畢就釋放TCP連接。

我們都知道TCP連接的建立需要經(jīng)過(guò)三次握手的過(guò)程，而每次發(fā)送HTTP請(qǐng)求都需要重新建立TCP連接，毫無(wú)疑問(wèn)是很低效的。所以HTTP1.1改善了這一點(diǎn)，使用長(zhǎng)連接的機(jī)制，也就是“一次TCP連接，N次HTTP請(qǐng)求”。

HTTP協(xié)議的長(zhǎng)連接和短連接，實(shí)質(zhì)上是 TCP 協(xié)議的長(zhǎng)連接和短連接。

在使用長(zhǎng)連接的情況下，當(dāng)一個(gè)網(wǎng)頁(yè)打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉，客戶端再次訪問(wèn)這個(gè)服務(wù)器時(shí)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長(zhǎng)連接需要客戶端和服務(wù)端都支持長(zhǎng)連接。

PS：對(duì)于IM開發(fā)者來(lái)說(shuō)，為了與Socket長(zhǎng)連接通道區(qū)分，通常認(rèn)為HTTP就是“短連接”（雖然這個(gè)“短連接”不一定真的“短”）。

HTTP1.0若要開啟長(zhǎng)連接，需要加上Connection: keep-alive請(qǐng)求頭。有關(guān)HTTP協(xié)議的詳細(xì)發(fā)展歷程可閱讀《一文讀懂HTTP協(xié)議的歷史演變和設(shè)計(jì)思路》一文。

4.3 安全問(wèn)題

隨著HTTP越來(lái)越廣泛的使用，HTTP的安全性問(wèn)題也逐漸暴露。

回憶一下多年前遍地都是的運(yùn)營(yíng)商劫持，當(dāng)你訪問(wèn)一個(gè)本來(lái)很正常的網(wǎng)頁(yè)，但頁(yè)面上卻莫名其妙出現(xiàn)了一些廣告標(biāo)簽、跳轉(zhuǎn)腳本、欺騙性的紅包按鈕，甚至有時(shí)候本來(lái)要下載一個(gè)文件，最后下載下來(lái)卻變成了另外一個(gè)完全不同的東西，這些都是被運(yùn)營(yíng)商劫持了HTTP明文數(shù)據(jù)的現(xiàn)象。

下圖就是似曾相識(shí)的運(yùn)營(yíng)商劫持效果圖：

PS：關(guān)于運(yùn)營(yíng)商劫持問(wèn)題，可以詳細(xì)閱讀《全面了解移動(dòng)端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》。

HTTP主要有以下3點(diǎn)安全性問(wèn)題：

?

歸納一下就是：

• 1）數(shù)據(jù)保密性問(wèn)題：因?yàn)镠TTP無(wú)狀態(tài)，而且又是明文傳輸，所有數(shù)據(jù)內(nèi)容都在網(wǎng)絡(luò)中裸奔，包用戶括身份信息、支付賬號(hào)與密碼。這些敏感信息極易泄露造成安全隱患；

• 2）數(shù)據(jù)完整性問(wèn)題：HTTP數(shù)據(jù)包在到達(dá)目的主機(jī)前會(huì)經(jīng)過(guò)很多轉(zhuǎn)發(fā)設(shè)備，每一個(gè)設(shè)備節(jié)點(diǎn)都可能會(huì)篡改或調(diào)包信息，無(wú)法驗(yàn)證數(shù)據(jù)的完整性；

• 3）身份校驗(yàn)問(wèn)題：有可能遭受中間人攻擊，我們無(wú)法驗(yàn)證通信的另一方就是我們的目標(biāo)對(duì)象。

因此，為了保證數(shù)據(jù)傳輸?shù)陌踩裕仨氁獙?duì)HTTP數(shù)據(jù)進(jìn)行加密。

5、常見(jiàn)的加密方式

5.1 基本情況

常見(jiàn)的加密方式分為三種：

• 1）對(duì)稱加密；

• 2）非對(duì)稱加密；

• 3）數(shù)字摘要。

前兩種適合數(shù)據(jù)傳輸加密，而數(shù)字摘要不可逆的特性常被用于數(shù)字簽名。

接下來(lái)，我們逐一簡(jiǎn)要學(xué)習(xí)一下這三種常見(jiàn)的加密方法。

5.2 對(duì)稱加密

對(duì)稱加密也稱為密鑰加密或單向加密，就是使用同一套密鑰來(lái)進(jìn)行加密和解密。密鑰可以理解為加密算法。

對(duì)稱加密圖示如下：

廣泛使用的對(duì)稱加密有：

對(duì)稱加密算法的優(yōu)缺點(diǎn)和適用場(chǎng)景：

• 1）優(yōu)點(diǎn)：算法公開、簡(jiǎn)單，加密解密容易，加密速度快，效率高；

• 2）缺點(diǎn)：相對(duì)來(lái)說(shuō)不算特別安全，只有一把鑰匙，密文如果被攔截，且密鑰也被劫持，那么，信息很容易被破譯；

• 3）適用場(chǎng)景：加解密速度快、效率高，因此適用于大量數(shù)據(jù)的加密場(chǎng)景。由于如何傳輸密鑰是較為頭痛的問(wèn)題，因此適用于無(wú)需進(jìn)行密鑰交換的場(chǎng)景，如內(nèi)部系統(tǒng)，事先就可以直接確定密鑰。

PS：可以在線體驗(yàn)對(duì)稱加密算法，鏈接是：http://www.jsons.cn/textencrypt/

小知識(shí)：base64編碼也屬于對(duì)稱加密哦！

5.3 非對(duì)稱加密

非對(duì)稱加密使用一對(duì)密鑰（公鑰和私鑰）進(jìn)行加密和解密。

非對(duì)稱加密可以在不直接傳遞密鑰的情況下，完成解密，具體步驟如下：

• 1）乙方生成兩把密鑰（公鑰和私鑰）。公鑰是公開的，任何人都可以獲得，私鑰則是保密的；

• 2）甲方獲取乙方的公鑰，然后用它對(duì)信息加密；

• 3）乙方得到加密后的信息，用私鑰解密。

以最典型的非對(duì)稱加密算法RSA為例，舉個(gè)例子：

想要徹底搞懂RSA，需要了解數(shù)論的知識(shí)，全部推導(dǎo)過(guò)程RSA加密算法。簡(jiǎn)單介紹思路：使用兩個(gè)超大質(zhì)數(shù)以及其乘積作為生成公鑰和私鑰的材料，想要從公鑰推算出私鑰是非常困難的（需要對(duì)超大數(shù)因式分解為兩個(gè)很大質(zhì)數(shù)的乘積）。目前被破解的最長(zhǎng)RSA密鑰是768個(gè)二進(jìn)制位。也就是說(shuō)，長(zhǎng)度超過(guò)768位的密鑰，還無(wú)法破解（至少?zèng)]人公開宣布）。因此可以認(rèn)為，1024位的RSA密鑰基本安全，2048位的密鑰極其安全。

非對(duì)稱加密算法的優(yōu)缺點(diǎn)和適用場(chǎng)景：

• 1）優(yōu)點(diǎn)：強(qiáng)度高、安全性強(qiáng)于對(duì)稱加密算法、無(wú)需傳遞私鑰導(dǎo)致沒(méi)有密鑰泄露風(fēng)險(xiǎn)；

• 2）缺點(diǎn)：計(jì)算量大、速度慢；

• 3）適用場(chǎng)景：適用于需要密鑰交換的場(chǎng)景，如互聯(lián)網(wǎng)應(yīng)用，無(wú)法事先約定密鑰。

實(shí)踐應(yīng)用過(guò)程中，其實(shí)可以與對(duì)稱加密算法結(jié)合：

• 1）利用非對(duì)稱加密算法安全性較好的特點(diǎn)來(lái)傳遞對(duì)稱加密算法的密鑰。

• 2）利用對(duì)稱加密算法加解密速度快的特點(diǎn)，進(jìn)行數(shù)據(jù)內(nèi)容比較大的加密場(chǎng)景的加密（如HTTPS）。

PS：對(duì)于IM開發(fā)者來(lái)說(shuō)，《探討組合加密算法在IM中的應(yīng)用》一文值得一讀。

5.4 如何選擇？

1）如果選擇對(duì)稱加密：

HTTP請(qǐng)求方使用對(duì)稱算法加密數(shù)據(jù)，那么為了接收方能夠解密，發(fā)送方還需要把密鑰一同傳遞到接收方。在傳遞密鑰的過(guò)程中還是可能遭到嗅探攻擊，攻擊者竊取密鑰后依然可以解密從而得到發(fā)送的數(shù)據(jù)，所以這種方案不可行。

2）如果選擇非對(duì)稱加密：

接收方保留私鑰，把公鑰傳遞給發(fā)送方。發(fā)送方用公鑰來(lái)加密數(shù)據(jù)，接收方使用私鑰解密數(shù)據(jù)。攻擊者雖然不能直接獲取這些數(shù)據(jù)（因?yàn)闆](méi)有私鑰），但是可以通過(guò)攔截傳遞的公鑰，然后把自己的公鑰傳給發(fā)送方，再用自己的私鑰對(duì)發(fā)送方發(fā)送數(shù)據(jù)進(jìn)行解密。

整個(gè)過(guò)程通信雙方都不知道中間人的存在，但是中間人能夠獲得完整的數(shù)據(jù)信息。

3）兩種加密方法的混合：

先使用非對(duì)稱加密算法加密并傳遞對(duì)稱加密的密鑰，然后雙方通過(guò)對(duì)稱加密方式加密要發(fā)送的數(shù)據(jù)?？雌饋?lái)沒(méi)什么問(wèn)題，但事實(shí)是這樣嗎？

中間人依然可以攔截公鑰的傳遞，并以自己的公鑰作為替換，治標(biāo)不治本。

想要治本，就要找到一個(gè)第三方公證人來(lái)證明公鑰沒(méi)有被替換，因此就引出了數(shù)字證書的概念，這也是下一節(jié)將分享的內(nèi)容。

6、數(shù)字證書

6.1 CA機(jī)構(gòu)

CA就是 Certificate Authority，即頒發(fā)數(shù)字證書的機(jī)構(gòu)。

作為受信任的第三方，CA承擔(dān)公鑰體系中公鑰的合法性檢驗(yàn)的責(zé)任。

證書就是源服務(wù)器向可信任的第三方機(jī)構(gòu)申請(qǐng)的數(shù)據(jù)文件。這個(gè)證書除了表明這個(gè)域名是屬于誰(shuí)的，頒發(fā)日期等，還包括了第三方證書的私鑰。

服務(wù)器將公鑰放在數(shù)字證書中，只要證書是可信的，公鑰就是可信的。

下面兩圖是飛書域名的證書中部分內(nèi)容的信：

6.2 數(shù)字簽名

摘要算法：一般用哈希函數(shù)來(lái)實(shí)現(xiàn)，可以理解成一種定長(zhǎng)的壓縮算法，它能把任意長(zhǎng)度的數(shù)據(jù)壓縮到固定長(zhǎng)度。這好比是給數(shù)據(jù)加了一把鎖，對(duì)數(shù)據(jù)有任何微小的改動(dòng)都會(huì)使摘要變得截然不同。

通常情況下：數(shù)字證書的申請(qǐng)人（服務(wù)器）將生成由私鑰和公鑰以及證書請(qǐng)求文件（Certificate Signing Request，CSR）組成的密鑰對(duì)。CSR是一個(gè)編碼的文本文件，其中包含公鑰和其他將包含在證書中的信息（例如：域名、組織、電子郵件地址等）。密鑰對(duì)和CSR生成通常在將要安裝證書的服務(wù)器上完成，并且 CSR 中包含的信息類型取決于證書的驗(yàn)證級(jí)別。與公鑰不同，申請(qǐng)人的私鑰是安全的，永遠(yuǎn)不要向 CA（或其他任何人）展示。

生成 CSR 后：申請(qǐng)人將其發(fā)送給 CA，CA 會(huì)驗(yàn)證其包含的信息是否正確，如果正確，則使用頒發(fā)的私鑰對(duì)證書進(jìn)行數(shù)字簽名，然后將簽名放在證書內(nèi)隨證書一起發(fā)送給申請(qǐng)人。

在SSL握手階段：瀏覽器在收到服務(wù)器的證書后，使用CA的公鑰進(jìn)行解密，取出證書中的數(shù)據(jù)、數(shù)字簽名以及服務(wù)器的公鑰。如果解密成功，則可驗(yàn)證服務(wù)器身份真實(shí)。之后瀏覽器再對(duì)數(shù)據(jù)做Hash運(yùn)算，將結(jié)果與數(shù)字簽名作對(duì)比，如果一致則可以認(rèn)為內(nèi)容沒(méi)有收到篡改。

對(duì)稱加密和非對(duì)稱加密是公鑰加密、私鑰解密， 而數(shù)字簽名正好相反——是私鑰加密（簽名）、公鑰解密（驗(yàn)證），如下圖所示。

限于篇幅，關(guān)于數(shù)字證書的內(nèi)容本文就不再贅述，想詳細(xì)了解的可以閱讀：

• 1）一文讀懂Https的安全性原理、數(shù)字證書、單項(xiàng)認(rèn)證、雙項(xiàng)認(rèn)證等；

• 2）你知道，HTTPS用的是對(duì)稱加密還是非對(duì)稱加密？；

• 3）如果這樣來(lái)理解HTTPS，一篇就夠了。

7、為什么要使用HTTPS

《圖解HTTP》一書中提到HTTPS就是身披SSL外殼的HTTP。

7.1 SSL

SSL 在1999年被更名為TLS。

所以說(shuō)：HTTPS 并不是一項(xiàng)新的應(yīng)用層協(xié)議，只是 HTTP 通信接口部分由 SSL 和 TLS 替代而已。

具體就是：HTTP 會(huì)先直接和 TCP 進(jìn)行通信，而HTTPS 會(huì)演變?yōu)橄群?SSL 進(jìn)行通信，然后再由 SSL 和 TCP 進(jìn)行通信。

SSL是一個(gè)獨(dú)立的協(xié)議，不只有 HTTP 可以使用，其他應(yīng)用層協(xié)議也可以使用，比如FTP、SMTP都可以使用SSL來(lái)加密。

7.2 HTTPS請(qǐng)求流程

HTTPS請(qǐng)求全流程如下圖：

如上圖所示：

• 1）用戶在瀏覽器發(fā)起HTTPS請(qǐng)求，默認(rèn)使用服務(wù)端的443端口進(jìn)行連接；

• 2）HTTPS需要使用一套CA 數(shù)字證書，證書內(nèi)會(huì)附帶一個(gè)服務(wù)器的公鑰Pub，而與之對(duì)應(yīng)的私鑰Private保留在服務(wù)端不公開；

• 3）服務(wù)端收到請(qǐng)求，返回配置好的包含公鑰Pub的證書給客戶端；

• 4）客戶端收到證書，校驗(yàn)合法性，主要包括是否在有效期內(nèi)、證書的域名與請(qǐng)求的域名是否匹配，上一級(jí)證書是否有效（遞歸判斷，直到判斷到系統(tǒng)內(nèi)置或?yàn)g覽器配置好的根證書），如果不通過(guò)，則顯示HTTPS警告信息，如果通過(guò)則繼續(xù)；

• 5）客戶端生成一個(gè)用于對(duì)稱加密的隨機(jī)Key，并用證書內(nèi)的公鑰Pub進(jìn)行加密，發(fā)送給服務(wù)端；

• 6）服務(wù)端收到隨機(jī)Key的密文，使用與公鑰Pub配對(duì)的私鑰Private進(jìn)行解密，得到客戶端真正想發(fā)送的隨機(jī)Key；

• 7）服務(wù)端使用客戶端發(fā)送過(guò)來(lái)的隨機(jī)Key對(duì)要傳輸?shù)腍TTP數(shù)據(jù)進(jìn)行對(duì)稱加密，將密文返回客戶端；

• 8）客戶端使用隨機(jī)Key對(duì)稱解密密文，得到HTTP數(shù)據(jù)明文；

• 9）后續(xù)HTTPS請(qǐng)求使用之前交換好的隨機(jī)Key進(jìn)行對(duì)稱加解密。

7.3 HTTPS到底解決了什么問(wèn)題

HTTPS確實(shí)解決了HTTP的三個(gè)安全性問(wèn)題：

• 1）?保密性：結(jié)合非對(duì)稱加密和對(duì)稱加密實(shí)現(xiàn)保密性。用非對(duì)稱加密方式加密對(duì)稱加密的秘鑰，再用對(duì)稱加密方式加密數(shù)據(jù)；

• 2）?完整性：通過(guò)第三方CA的數(shù)字簽名解決完整性問(wèn)題；

• 3）?身份校驗(yàn)：通過(guò)第三方CA的數(shù)字證書驗(yàn)證服務(wù)器的身份。

7.4 HTTPS優(yōu)缺點(diǎn)

最后我們總結(jié)一下HTTPS的優(yōu)缺點(diǎn)：

可以看到：HTTPS的確是當(dāng)今安全傳輸HTTP的最優(yōu)解，但他并不是完美的，仍會(huì)有漏洞。

8、參考資料

[1]?深入淺出，全面理解HTTP協(xié)議

[2]?HTTP協(xié)議必知必會(huì)的一些知識(shí)

[3]?從數(shù)據(jù)傳輸層深度解密HTTP

[4]?一文讀懂HTTP協(xié)議的歷史演變和設(shè)計(jì)思路

[5]?你知道一個(gè)TCP連接上能發(fā)起多少個(gè)HTTP請(qǐng)求嗎？

[6]?如果這樣來(lái)理解HTTPS，一篇就夠了

[7]?一分鐘理解 HTTPS 到底解決了什么問(wèn)題

[8]?你知道，HTTPS用的是對(duì)稱加密還是非對(duì)稱加密？

[9]?HTTPS時(shí)代已來(lái)，打算更新你的HTTP服務(wù)了嗎？

[10]?一篇讀懂HTTPS：加密原理、安全邏輯、數(shù)字證書等

[11]?全面了解移動(dòng)端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等

（本文已同步發(fā)布于：http://www.52im.net/thread-3897-1-1.html）