Django+HTTPS開發(fā)環(huán)境如何配置？[python培訓(xùn)]

HTTP的弊端及HTTPS的由來

眾所周知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ù)本身存在的安全問題:
(1)通信使用明文(不加密)，內(nèi)容可能被竊聽;
(2)不驗(yàn)證通信方的身份，因此可能遭遇偽裝;
(3)無法證明報(bào)文的完整行，所以可能被篡改。

為了解決HTTP協(xié)議存在的安全性問題，上世紀(jì)90年代由網(wǎng)景(NetScape)公司設(shè)計(jì)了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é)議。【推薦了解傳智播客python+人工智能課程】

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

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

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

對(duì)稱加密

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

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

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

非對(duì)稱加密

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

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

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

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

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

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

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

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

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

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

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

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

由于正規(guī)的證書需要向CA機(jī)構(gòu)申請(qǐng)，在此，我通過自簽證書的形式簡(jiǎn)單配置一個(gè)基于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證書密鑰及申請(qǐng)文件

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

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

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

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

(2)修改Django配置文件

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

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

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

(1)添加根證書

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

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