1、理解 HTTPS 及配置Django+HTTPS 開發(fā)環(huán)境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)景(NetSc)公司設(shè)計了SSL(Secure Sockets Layer)協(xié)議“

2、接層”協(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ù)完整性的呢?在此,需要再進(jìn)一步探討該協(xié)議的加密邏輯.加密算法有兩種,分別是“對稱加密”和“非對稱加密”.(本文不對學(xué)中的加密算法的實現(xiàn)做探討,僅解釋加密原理)

3、.對稱加密關(guān)于“對稱加密”,可以理解成一種“互逆”的數(shù)算(對比單向加密它是一種可逆的加密算法).也就是說有加密,就可以,但是不管是加密還是的過程中,必須有一個的稱之為“密鑰”的東西參與運(yùn)算.對稱加密最大的特點(diǎn)就在于加密和使用“相同的”密鑰.那么關(guān)鍵問題來了客戶端和服務(wù)器交互使用共同的“密鑰”來加密通信,這就需要服務(wù)器將密鑰傳輸給客戶端,但是如此操作又如何才能夠保證密鑰在傳輸過程中的安全性呢?如果密鑰在傳輸過程中遭遇第,那就意味著雙端通信之于第而言和明文通信沒有區(qū)別了.也就是說對稱加密并不適用于密鑰需要網(wǎng)絡(luò)傳輸?shù)膽?yīng)用場景.由此,誕生了“非對稱加密”.非對稱加密所謂的“非對稱加密”就是加密和使用的

4、密鑰是不同的,雙端通信各自產(chǎn)生公鑰和私,并交換雙端的公鑰用于通信加密.如下圖所示,當(dāng)服務(wù)器把公鑰交給客戶端,客戶端在通信時使用公鑰對數(shù)據(jù)進(jìn)行加理,即使公鑰在傳輸過程中遭遇第,由于的密鑰始終在服務(wù)端并不會對外公開,所以方僅用一個公鑰是無法數(shù)據(jù)的.但是上述應(yīng)用場景仍然存在一定的被的風(fēng)險.也就是說,作為者,在服務(wù)器響應(yīng)給客戶端的公鑰后,服務(wù)端,給客戶端響應(yīng)者的公鑰.此后客戶端使用者的公鑰加密數(shù)據(jù),者在數(shù)據(jù)消息后,利用自己的私鑰進(jìn)行,得到明文數(shù)據(jù)后篡改數(shù)據(jù),然后在使用服務(wù)器公鑰加密數(shù)據(jù)和服務(wù)器通信.整個通信的過程中,客戶端都無法察覺自己通信的對端到底是者還是服務(wù)器.觀察下圖中的圖示模型,假設(shè)通信過程已

5、被.那么問題到底出在哪里?非對稱加密中的風(fēng)險圖示可以從整個流程的一開始去分析.客戶端在第一次請求公鑰,并在響應(yīng)中得到了來自“對端”的公鑰.然后就利用該“公鑰”通信.問題就是出在了這個環(huán)節(jié)顯而易見,作為客戶端并沒有對該“公鑰”的“來源”做驗證.換句話說,客戶端并不清楚,該“公鑰”是否真的來自真正的服務(wù)器而不是第者.如此,客戶端就必須對“公鑰”做驗證,確定該公鑰確實是來自合法的服務(wù)器后,才能夠保證雙端通信的安全性.CA 認(rèn)證機(jī)制這里需要引入第機(jī)構(gòu):頒發(fā)機(jī)構(gòu)(CA,Authority)即頒發(fā)數(shù)字的機(jī)構(gòu).是負(fù)責(zé)和管理數(shù)字的機(jī)構(gòu),作為電子商務(wù)交易中受信任的第,承擔(dān)公鑰體系中公鑰檢驗的責(zé)任.CA中心會為每

6、個使用公鑰的用戶一個數(shù)字,數(shù)字的作用是證明中列出的用戶公鑰的.CA 機(jī)構(gòu)的數(shù)字簽名使得者無法和篡改.換句話說,無法篡改,只要是有效且合法的,那么中的公鑰就是有效且合法的!服務(wù)器將公鑰提供給 CA 機(jī)構(gòu),CA 機(jī)構(gòu)使用自己的私鑰將服務(wù)器公鑰加密后將 CA(該證書保存有服務(wù)器公鑰)返回給服務(wù)器.一般操作系統(tǒng)或者瀏覽器中都會內(nèi)置 CA 根.當(dāng)客戶端(比如瀏覽器)請求服務(wù)器時,服務(wù)器會將 CA提供給客戶端,客戶端獲取到 CA后會使用CA 根進(jìn)行本地驗證(驗證通過即表明服務(wù)器 CA的,間接表明公鑰來源的).自書實現(xiàn) django+http+ssl由于正規(guī)的需要向 CA 機(jī)構(gòu)申請,在此,我通過自書的形式簡

7、單配置一個基于 https通信的 django 服務(wù)器.(1)、創(chuàng)建簽發(fā) CA 根的配置文件f(2)、創(chuàng)建拓展配置文件(用于創(chuàng)建服務(wù)器 CA)panyLocalhost.ext(3)、創(chuàng)建 CA及密鑰(需要使用 openssl,可以通過包管理工具安裝)(4)、創(chuàng)建 ssl密鑰及申請文件(5)、簽發(fā) ssl經(jīng)過上述步驟,通過 openssl 實現(xiàn)自簽發(fā)其中panyCA.cer 為 CA 根(由于我們這是自簽發(fā), 系統(tǒng)或瀏覽器中并不會內(nèi)置該根, 需要手動添加).ssl文件為panyLocalhost.cer,ssl密鑰文件為panyLocalhost.pvk.Django 啟動HTTPS 測試服務(wù)器.(1)、安裝依賴項(2)、修改Django 配置文件(3)、啟動 django 的 https 服務(wù)自此 django 已啟動 https 服務(wù),但使用瀏覽器仍然無法使用 https(服務(wù)器不).需要將自簽發(fā)的