HTTP的弊端及HTTPS的由來

眾所周知HTTP協(xié)議是以TCP協(xié)議為基石誕生的一個用于傳輸Web內(nèi)容的一個網(wǎng)絡(luò)協(xié)議,在"網(wǎng)絡(luò)分層模型"中屬于"應(yīng)用層協(xié)議"的一種.那么在這里我們并不研究該協(xié)議標(biāo)準(zhǔn)本身,而是從安全角度去探究使用該協(xié)議傳輸數(shù)據(jù)本身存在的安全問題:

(1)、通信使用明文(不加密),內(nèi)容可能被竊聽;
(2)、不驗證通信方的身份,因此可能遭遇偽裝;
(3)、無法證明報文的完整行,所以可能被篡改.

為了解決HTTP協(xié)議存在的安全性問題,上世紀(jì)90年代由網(wǎng)景(NetScape)公司設(shè)計了SSL(Secure Sockets Layer)協(xié)議——"安全套接層"協(xié)議.經(jīng)過多年發(fā)展SSL在互聯(lián)網(wǎng)上廣泛應(yīng)用,標(biāo)準(zhǔn)化后名稱改為TLS(Transport Layer Security)——"傳輸層安全"協(xié)議.

所謂的HTTPS即是"HTTP+SSL/TLS"的結(jié)合使用而已.解決的是HTTP協(xié)議數(shù)據(jù)傳輸?shù)陌踩詥栴}——在HTTP協(xié)議層和TCP傳輸層之間加入"安全層",使得應(yīng)用層數(shù)據(jù)報經(jīng)過加密后再傳輸,保證數(shù)據(jù)在傳輸過程中的完整性.

那么,SSL/TLS在數(shù)據(jù)傳輸過程中是如何實現(xiàn)加密保證數(shù)據(jù)完整性的呢?在此,我們需要再進一步探討該協(xié)議的加密邏輯.

加密算法有兩種,分別是"對稱加密"和"非對稱加密".(本文不對密碼學(xué)中的加密算法的實現(xiàn)做探討,僅解釋加密原理).

對稱加密

關(guān)于"對稱加密",可以理解成一種"互逆"的數(shù)學(xué)運算(對比單向加密它是一種可逆的加密算法).也就是說有加密,就可以解密,但是不管是加密還是解密的過程中,必須有一個至關(guān)重要的稱之為"密鑰"的東西參與運算.

對稱加密最大的特點就在于加密和解密使用"相同的"密鑰.那么關(guān)鍵問題來了——客戶端和服務(wù)器交互使用共同的"密鑰"來加密通信,這就需要服務(wù)器將密鑰傳輸給客戶端,但是如此操作又如何才能夠保證密鑰在傳輸過程中的安全性呢?如果密鑰在傳輸過程中遭遇第三方攔截,那就意味著雙端通信之于第三方而言和明文通信沒有區(qū)別了.也就是說對稱加密并不適用于密鑰需要網(wǎng)絡(luò)傳輸?shù)膽?yīng)用場景.

由此,誕生了"非對稱加密".

非對稱加密

所謂的"非對稱加密"就是加密和解密使用的密鑰是不同的,雙端通信各自產(chǎn)生公鑰和私鑰匙,并交換雙端的公鑰用于通信加密.如下圖所示,當(dāng)服務(wù)器把公鑰交給客戶端,客戶端在通信時使用公鑰對數(shù)據(jù)進行加密處理,即使公鑰在傳輸過程中遭遇第三方攔截,由于解密的密鑰始終存儲在服務(wù)端并不會對外公開,所以攔截方僅用一個公鑰是無法解密數(shù)據(jù)的.

但是上述應(yīng)用場景仍然存在一定的被竊聽的風(fēng)險.也就是說,作為竊聽者,在攔截服務(wù)器響應(yīng)給客戶端的公鑰后,偽造服務(wù)端身份,給客戶端響應(yīng)竊聽者的公鑰.此后客戶端使用竊聽者的公鑰加密數(shù)據(jù),竊聽者在攔截數(shù)據(jù)消息后,利用自己的私鑰進行解密,得到明文數(shù)據(jù)后篡改數(shù)據(jù),然后在使用服務(wù)器公鑰加密數(shù)據(jù)和服務(wù)器通信.整個通信的過程中,客戶端都無法察覺自己通信的對端到底是竊聽者還是服務(wù)器.

觀察下圖中的圖示模型,假設(shè)通信過程已被竊聽.那么問題到底出在哪里?

非對稱加密中的竊聽風(fēng)險圖示

我們可以從整個流程的一開始去分析.

客戶端在第一次請求公鑰,并在響應(yīng)中得到了來自"對端"的公鑰.然后就利用該"公鑰"通信.問題就是出在了這個環(huán)節(jié)——顯而易見,作為客戶端并沒有對該"公鑰"的"來源"做驗證.換句話說,客戶端并不清楚,該"公鑰"是否真的來自真正的服務(wù)器而不是第三方竊聽者.

如此,客戶端就必須對"公鑰"做驗證,確定該公鑰確實是來自合法的服務(wù)器后,才能夠保證雙端通信的安全性.

CA認(rèn)證機制

這里需要引入第三方機構(gòu): 證書頒發(fā)機構(gòu)(CA, Certificate Authority)即頒發(fā)數(shù)字證書的機構(gòu).是負(fù)責(zé)發(fā)放和管理數(shù)字證書的權(quán)威機構(gòu),作為電子商務(wù)交易中受信任的第三方,承擔(dān)公鑰體系中公鑰合法性檢驗的責(zé)任.

CA中心會為每個使用公鑰的用戶發(fā)放一個數(shù)字證書,數(shù)字證書的作用是證明證書中列出的用戶公鑰的合法性.CA機構(gòu)的數(shù)字簽名使得攻擊者無法偽造和篡改證書.換句話說,證書無法篡改,只要證書是有效且合法的,那么證書中的公鑰就是有效且合法的!

服務(wù)器將公鑰提供給CA機構(gòu),CA機構(gòu)使用自己的私鑰將服務(wù)器公鑰加密后將CA證書(該證書保存有服務(wù)器公鑰)返回給服務(wù)器.一般操作系統(tǒng)或者瀏覽器中都會內(nèi)置CA根證書.當(dāng)客戶端(比如瀏覽器)請求服務(wù)器時,服務(wù)器會將CA證書提供給客戶端,客戶端獲取到CA證書后會使用CA根證書進行本地驗證(驗證通過即表明服務(wù)器CA證書的合法性,間接表明公鑰來源的合法性).

自簽證書實現(xiàn)django+http+ssl

由于正規(guī)的證書需要向CA機構(gòu)申請,在此,我通過自簽證書的形式簡單配置一個基于https通信的django服務(wù)器.

(1)、創(chuàng)建簽發(fā)CA根證書的配置文件MyCompanyCA.cnf

(2)、創(chuàng)建拓展配置文件(用于創(chuàng)建服務(wù)器CA證書)MyCompanyLocalhost.ext

(3)、創(chuàng)建CA證書及密鑰(需要使用openssl,可以通過包管理工具安裝)

(4)、創(chuàng)建ssl證書密鑰及申請文件

(5)、簽發(fā)ssl證書

經(jīng)過上述步驟,通過openssl實現(xiàn)自簽發(fā)證書,其中MyCompanyCA.cer為CA根證書(由于我們這是自簽發(fā),系統(tǒng)或瀏覽器中并不會內(nèi)置該根證書,需要我們手動添加).ssl證書文件為MyCompanyLocalhost.cer,ssl證書密鑰文件為MyCompanyLocalhost.pvk.

Django啟動HTTPS測試服務(wù)器.

(1)、安裝依賴項