?如何配置Django+HTTPS開(kāi)發(fā)環(huán)境？

HTTP的弊端及HTTPS的由來(lái)

眾所周知HTTP協(xié)議是以TCP協(xié)議為基石誕生的一個(gè)用于傳輸Web內(nèi)容的一個(gè)網(wǎng)絡(luò)協(xié)議，在“網(wǎng)絡(luò)分層模型”中屬于“應(yīng)用層協(xié)議”的一種。那么在這里我們并不研究該協(xié)議標(biāo)準(zhǔn)本身，而是從安全角度去探究使用該協(xié)議傳輸數(shù)據(jù)本身存在的安全問(wèn)題:(1)通信使用明文(不加密)，內(nèi)容可能被竊聽(tīng);(2)不驗(yàn)證通信方的身份，因此可能遭遇偽裝;(3)無(wú)法證明報(bào)文的完整行，所以可能被篡改。

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

所謂的HTTPS即是“HTTP+SSL/TLS”的結(jié)合使用而已。解決的是HTTP協(xié)議數(shù)據(jù)傳輸?shù)陌踩詥?wèn)題——在HTTP協(xié)議層和TCP傳輸層之間加入“安全層”，使得應(yīng)用層數(shù)據(jù)報(bào)經(jīng)過(guò)加密后再傳輸，保證數(shù)據(jù)在傳輸過(guò)程中的完整性。

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

加密算法有兩種，分別是“對(duì)稱(chēng)加密”和“非對(duì)稱(chēng)加密”。(本文不對(duì)密碼學(xué)中的加密算法的實(shí)現(xiàn)做探討，僅解釋加密原理)。

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

關(guān)于“對(duì)稱(chēng)加密”，可以理解成一種“互逆”的數(shù)學(xué)運(yùn)算(對(duì)比單向加密它是一種可逆的加密算法)。也就是說(shuō)有加密，就可以解密，但是不管是加密還是解密的過(guò)程中，必須有一個(gè)至關(guān)重要的稱(chēng)之為“密鑰”的東西參與運(yùn)算。

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

由此，誕生了“非對(duì)稱(chēng)加密”。

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

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

但是上述應(yīng)用場(chǎng)景仍然存在一定的被竊聽(tīng)的風(fēng)險(xiǎn)。也就是說(shuō)，作為竊聽(tīng)者，在攔截服務(wù)器響應(yīng)給客戶端的公鑰后，偽造服務(wù)端身份，給客戶端響應(yīng)竊聽(tīng)者的公鑰。此后客戶端使用竊聽(tīng)者的公鑰加密數(shù)據(jù)，竊聽(tīng)者在攔截?cái)?shù)據(jù)消息后，利用自己的私鑰進(jìn)行解密，得到明文數(shù)據(jù)后篡改數(shù)據(jù)，然后在使用服務(wù)器公鑰加密數(shù)據(jù)和服務(wù)器通信。整個(gè)通信的過(guò)程中，客戶端都無(wú)法察覺(jué)自己通信的對(duì)端到底是竊聽(tīng)者還是服務(wù)器。

觀察下圖中的圖示模型，假設(shè)通信過(guò)程已被竊聽(tīng)。那么問(wèn)題到底出在哪里?【推薦了解黑馬程序員python+人工智能課程】

非對(duì)稱(chēng)加密中的竊聽(tīng)風(fēng)險(xiǎn)圖示

我們可以從整個(gè)流程的一開(kāi)始去分析。

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

如此，客戶端就必須對(duì)“公鑰”做驗(yàn)證，確定該公鑰確實(shí)是來(lái)自合法的服務(wù)器后，才能夠保證雙端通信的安全性。

CA認(rèn)證機(jī)制

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

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

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

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

由于正規(guī)的證書(shū)需要向CA機(jī)構(gòu)申請(qǐng)，在此，我通過(guò)自簽證書(shū)的形式簡(jiǎn)單配置一個(gè)基于https通信的django服務(wù)器。

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

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

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

(4)創(chuàng)建ssl證書(shū)密鑰及申請(qǐng)文件

(5)簽發(fā)ssl證書(shū)

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

Django啟動(dòng)HTTPS測(cè)試服務(wù)器

(1)安裝依賴項(xiàng)

(2)修改Django配置文件

(3)啟動(dòng)django的https服務(wù)

自此django已啟動(dòng)https服務(wù)，但使用瀏覽器仍然無(wú)法使用https訪問(wèn)(服務(wù)器證書(shū)不可信)。

需要將自簽發(fā)的CA根證書(shū)安裝到需要使用https訪問(wèn)的客戶端中。以下為macos系統(tǒng)中添加證書(shū)的操作圖示(windows中也有相關(guān)界面操作):

(1)添加根證書(shū)

(2)設(shè)置系統(tǒng)信任該證書(shū)

自此，客戶端一方(瀏覽器)添加完成后，就可以使用https訪問(wèn)服務(wù)器。