[[354426]]

【51CTO.com原創(chuàng)稿件】

 一、HTTP Begin

1、什么是 HTTP

HTTP 是基于文本傳輸?shù)膮f(xié)議，它位于 OSI 七層模型的應(yīng)用層(Application) ，HTTP 是通過(guò)客戶(hù)端向服務(wù)器發(fā)送請(qǐng)求，服務(wù)器響應(yīng)請(qǐng)求來(lái)進(jìn)行通訊，截止到目前位置 HTTP 協(xié)議分別由 6 個(gè)獨(dú)立的協(xié)議說(shuō)明組成，這 6 個(gè)協(xié)議說(shuō)明分別是 RFC 7230 、 RFC 7231 、 RFC 7232 、RFC 7233 、 RFC 7234 、 RFC 7235 。

說(shuō)到 HTTP 就不得不說(shuō)通訊報(bào)文，下面我們來(lái)看看 HTTP 通訊報(bào)文。通訊報(bào)文分為 請(qǐng)求報(bào)文和 響應(yīng)報(bào)文 。

①請(qǐng)求報(bào)文

HTTP請(qǐng)求報(bào)文通常由請(qǐng)求行(request line)、請(qǐng)求頭部(header)、空行和請(qǐng)求數(shù)據(jù)4個(gè)部分組，如下圖所示：

請(qǐng)求行包含請(qǐng)求方法、URL 和 HTTP 協(xié)議版本三個(gè)字段組成，在這里需要說(shuō)的是 請(qǐng)求方法可以實(shí) GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT，但是常見(jiàn)的經(jīng)常用到的就是 GET、POST、DELETE和 PUT。

請(qǐng)求頭部由大量鍵值對(duì)組成，請(qǐng)求頭部的數(shù)據(jù)都是向服務(wù)器告知客戶(hù)端的信息，比較常見(jiàn)的請(qǐng)求頭有 User-Agent 瀏覽器類(lèi)型，Accept 客戶(hù)端可識(shí)別的內(nèi)容類(lèi)型列表，Host 請(qǐng)求的主機(jī)名。接下來(lái)是一個(gè)空行，它主要用來(lái)通知服務(wù)器從當(dāng)前行開(kāi)始往下就不再是請(qǐng)求頭了。

請(qǐng)求數(shù)據(jù)主要是在 POST 和 PUT 方法中使用，用來(lái)向服務(wù)器提交客戶(hù)端的表單信息，一般需要配合著 Content-Type和Content-Length 使用。

②響應(yīng)報(bào)文

響應(yīng)報(bào)文也是由三部分組成，狀態(tài)行、消息報(bào)頭和響應(yīng)正文。狀態(tài)行用來(lái)告知客戶(hù)端所請(qǐng)求資源的情況，狀態(tài)行由 HTTP 版本、服務(wù)器回發(fā)響應(yīng)狀態(tài)碼和狀態(tài)碼文本描述組成。這里要說(shuō)一下響應(yīng)狀態(tài)碼，狀態(tài)碼類(lèi)型如下表所示：

上表看著響應(yīng)狀態(tài)碼很多，但是大部分在實(shí)際運(yùn)用中很少遇到，經(jīng)常遇到的狀態(tài)碼一共 7 中，如下表所示：

2、HTTP 致命缺點(diǎn)

HTTP 有一個(gè)致命的缺點(diǎn)，就是 HTTP 的報(bào)文都是以明文的方式進(jìn)行傳輸，這樣就會(huì)導(dǎo)致中間人攻擊問(wèn)題。什么是中間人攻擊了，下面我們通過(guò)圖文的形式講一下。

A 在客戶(hù)端向服務(wù)器發(fā)送了一句話“我今天很好”，這時(shí)在數(shù)據(jù)還沒(méi)有到達(dá)服務(wù)器的時(shí)候被 B 攔截到，B 將發(fā)送的內(nèi)容改為“我昨天很好”并發(fā)送給服務(wù)器，最后服務(wù)器接收到的信息就是“我昨天很好”而不是“我今天很好”。

在這里 B 就是中間人，B 所執(zhí)行的所有操作就叫做中間人攻擊，一圖勝千言我們來(lái)看圖。

3、HTTP 預(yù)防致命缺點(diǎn)手段

要想預(yù)防中間人攻擊我們就需要對(duì)發(fā)送的報(bào)文信息進(jìn)行加密處理，一般來(lái)說(shuō)我們會(huì)采用兩種加密手段來(lái)預(yù)防中間人攻擊：對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密。

①對(duì)稱(chēng)加密

首先 A 發(fā)送一條信息告訴服務(wù)器我要和你通訊了，服務(wù)器收到這條信息后響應(yīng)一條信息告訴 A 的加密方式(例如 AES 加密)和密鑰，最后 A 用和服務(wù)器協(xié)商好的加密方式對(duì)信息進(jìn)行加密并發(fā)送，服務(wù)器收到信息后利用密鑰進(jìn)行解密即可。

通過(guò)上圖看出點(diǎn)什么沒(méi)?發(fā)送的內(nèi)容雖然已經(jīng)加密了，但是加密方式和密鑰依然是明文，中間人如果攔截到第一次通信的話，它就可以拿著攔截到的加密方式和密鑰就可以對(duì)后面的通信進(jìn)行解密，修改內(nèi)容后再以同樣的加密方式和密鑰進(jìn)行加密后發(fā)送個(gè)服務(wù)器。

②非對(duì)稱(chēng)加密

針對(duì)前面所說(shuō)的情況我們可以使用非對(duì)稱(chēng)加密對(duì)密鑰進(jìn)行加密處理。同樣首先 A 發(fā)送一條信息告訴服務(wù)器我要和你通訊了，服務(wù)器收到這條信息后先利用非對(duì)稱(chēng)加密(例如RSA)生成一個(gè)公鑰和一個(gè)私鑰，然后服務(wù)器將公鑰發(fā)發(fā)送給 A ，A 在本地生成一個(gè)密鑰并利用服務(wù)器發(fā)回的公鑰進(jìn)行加密，完成后發(fā)送給服務(wù)器，服務(wù)器收到后利用私鑰進(jìn)行解密得到對(duì)稱(chēng)加密的密鑰，最后雙方利用約定好的加密方式和密鑰進(jìn)行通信。

到目前為止看起來(lái)不錯(cuò)密鑰和信息都加密了，應(yīng)該就沒(méi)問(wèn)題了吧。真的是這樣嗎，如果真的是這樣的話 HTTPS 就沒(méi)有出現(xiàn)的必要了。

既然密鑰都加密了，那么中間人在攔截到第一次通信時(shí)可以拿到服務(wù)器發(fā)給客戶(hù)端的加密方式和公鑰，然后自己生成一個(gè)私鑰和一個(gè)公鑰，并將攔截到的服務(wù)器發(fā)來(lái)的公鑰替換成自己生成的公鑰后發(fā)送給客戶(hù)端，這時(shí)客戶(hù)端加密 AES 密鑰的公鑰就是中間人的了。

客戶(hù)端對(duì) AES 密鑰加密后發(fā)送給服務(wù)器，中間人再次攔截并利用自己的私鑰解析密文得到AES 密鑰，然后使用服務(wù)器的公鑰對(duì) AES 密鑰加密并發(fā)送給服務(wù)器。最后在客戶(hù)端和服務(wù)器的整個(gè)通訊期間中間人就可以用接獲到 AES 密鑰對(duì)信息解密并修改。

到這里一定會(huì)由同學(xué)問(wèn)，這兩種方法都無(wú)法完全避免中間人攻擊，還有其他的辦法嗎?下面我們偉大的 HTTPS 就要登場(chǎng)了，它可以完全避免中間人攻擊。

二、HTTPS End

1.什么是 HTTPS

HTTPS 就是 HTTP 和 TLS 的簡(jiǎn)稱(chēng)，以前的 HTTPS 使用的是 SSL ，現(xiàn)在的 HTTPS 使用的是 SSL 。TLS 整體上來(lái)說(shuō)和非對(duì)稱(chēng)加密是一樣的，主要是對(duì) AES 密鑰加密的。

簡(jiǎn)單來(lái)說(shuō)就是 A 發(fā)送一條信息給服務(wù)器告訴服務(wù)器我要和你通信，然后服務(wù)器返回 TLS/SSL證書(shū)，客戶(hù)端在收到證書(shū)后校驗(yàn)證書(shū)的有效性，如果證書(shū)有效就生成生成 AES 密鑰并用證書(shū)中的公鑰加密，然后發(fā)送給服務(wù)器。服務(wù)器確認(rèn)收到后，就可以利用 AES 密鑰進(jìn)行加密通信了。

2.關(guān)于 CA 認(rèn)證體系

CA 認(rèn)證體系是 HTTPS 防止中間人攻擊的核心，客戶(hù)端需要對(duì)服務(wù)器發(fā)來(lái)的證書(shū)進(jìn)行安全性校驗(yàn)。那么客戶(hù)端是怎么校驗(yàn)證書(shū)的安全性呢?下面我們來(lái)講解一下。

證書(shū)都是由權(quán)威的認(rèn)證機(jī)構(gòu)頒發(fā)的，并且這些認(rèn)證機(jī)構(gòu)辦法的證書(shū)目前已經(jīng)內(nèi)置到了操作系統(tǒng)中(Windows 是這樣，其他的操作系統(tǒng)不慎了解)，這些證書(shū)被稱(chēng)為 CA 根證書(shū)。

當(dāng)我們的服務(wù)器需要使用 HTTPS 的時(shí)候，就需要將服務(wù)器生成的公鑰和網(wǎng)站相關(guān)信息發(fā)給權(quán)威認(rèn)證機(jī)構(gòu)，然后權(quán)威認(rèn)證機(jī)構(gòu)通過(guò)服務(wù)器發(fā)送的相關(guān)信息用進(jìn)行加簽，由此得到了服務(wù)器證書(shū)，這個(gè)證書(shū)對(duì)應(yīng)的生成證書(shū)內(nèi)容的簽名，并將該這個(gè)簽名使用權(quán)威認(rèn)證機(jī)構(gòu)的私鑰進(jìn)行加密得到證書(shū)指紋，并且和上級(jí)證書(shū)生成關(guān)系鏈(上級(jí)證書(shū)最后都是 CA 根證書(shū))。

當(dāng)客戶(hù)端收到服務(wù)器發(fā)來(lái)的證書(shū)后，首先會(huì)通過(guò)層級(jí)關(guān)系找到上級(jí)證書(shū)，然后利用上級(jí)證書(shū)里的公鑰解密服務(wù)器證書(shū)的證書(shū)指紋，解密后得到簽名。

然后通過(guò)簽名算法算出服務(wù)器證書(shū)的簽名，并對(duì)比兩個(gè)簽名是否一樣，一樣就說(shuō)明服務(wù)器發(fā)來(lái)的證書(shū)是不存在問(wèn)題的。

這里證書(shū)校驗(yàn)用的 RSA 是通過(guò)私鑰加密證書(shū)簽名，公鑰解密來(lái)巧妙的驗(yàn)證證書(shū)有效性的。通過(guò) CA 認(rèn)證體系就可以避免了中間人竊取 AES 密鑰并發(fā)起攔截和修改 HTTP 通訊的報(bào)文。

三、總結(jié)

這篇文章嘮嘮叨叨的講了這么多關(guān)于 HTTP 和 HTTPS 的知識(shí)，看似很基礎(chǔ)其實(shí)在很多時(shí)候我們發(fā)出去或接受到的數(shù)據(jù)不準(zhǔn)確其實(shí)就是因?yàn)橹虚g人攻擊造成的，因此我們?cè)陂_(kāi)發(fā)部署網(wǎng)站的時(shí)候應(yīng)該盡可能的使用 HTTPS 。

作者：朱鋼，筆名喵叔

簡(jiǎn)介：.NET 高級(jí)開(kāi)發(fā)人員，2019 年度博客之星 20 強(qiáng)，長(zhǎng)期從事電子政務(wù)系統(tǒng)和AI客服系統(tǒng)的設(shè)計(jì)與開(kāi)發(fā)，目前就職于國(guó)內(nèi)某 BIM 大廠從事招投標(biāo)軟件的開(kāi)發(fā)。

編輯：陶家龍

征稿：有投稿、尋求報(bào)道意向技術(shù)人請(qǐng)私信小編

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】