全國(guó)咨詢(xún)/投訴熱線(xiàn):400-618-4000

首頁(yè)技術(shù)文章正文

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

更新時(shí)間:2019-10-23 來(lái)源:黑馬程序員 瀏覽量:


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é)議。

1571821094457_Django+HTTPS01.jpg

所謂的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)算。

1571821161501_Django+HTTPS02.jpg


對(duì)稱(chēng)加密最大的特點(diǎn)就在于加密和解密使用“相同的”密鑰。那么關(guān)鍵問(wèn)題來(lái)了——客戶(hù)端和服務(wù)器交互使用共同的“密鑰”來(lái)加密通信,這就需要服務(wù)器將密鑰傳輸給客戶(hù)端,但是如此操作又如何才能夠保證密鑰在傳輸過(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ù)器把公鑰交給客戶(hù)端,客戶(hù)端在通信時(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)給客戶(hù)端的公鑰后,偽造服務(wù)端身份,給客戶(hù)端響應(yīng)竊聽(tīng)者的公鑰。此后客戶(hù)端使用竊聽(tīng)者的公鑰加密數(shù)據(jù),竊聽(tīng)者在攔截?cái)?shù)據(jù)消息后,利用自己的私鑰進(jìn)行解密,得到明文數(shù)據(jù)后篡改數(shù)據(jù),然后在使用服務(wù)器公鑰加密數(shù)據(jù)和服務(wù)器通信。整個(gè)通信的過(guò)程中,客戶(hù)端都無(wú)法察覺(jué)自己通信的對(duì)端到底是竊聽(tīng)者還是服務(wù)器。

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

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


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

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

如此,客戶(hù)端就必須對(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è)使用公鑰的用戶(hù)發(fā)放一個(gè)數(shù)字證書(shū),數(shù)字證書(shū)的作用是證明證書(shū)中列出的用戶(hù)公鑰的合法性。CA機(jī)構(gòu)的數(shù)字簽名使得攻擊者無(wú)法偽造和篡改證書(shū)。換句話(huà)說(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)客戶(hù)端(比如瀏覽器)請(qǐng)求服務(wù)器時(shí),服務(wù)器會(huì)將CA證書(shū)提供給客戶(hù)端,客戶(hù)端獲取到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

1571821247938_Django+HTTPS05.jpg


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

1571821254474_Django+HTTPS06.jpg

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

1571821261138_Django+HTTPS07.jpg

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

1571821309129_Django+HTTPS08.jpg

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

1571821334333_Django+HTTPS09.jpg

經(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)安裝依賴(lài)項(xiàng)

1571821366141_Django+HTTPS10.jpg

(2)修改Django配置文件

1571821373180_Django+HTTPS11.jpg

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

1571821380867_Django+HTTPS12.jpg

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

1571821407904_Django+HTTPS13.jpg

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

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

1571821416466_Django+HTTPS14.jpg

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

1571821423569_Django+HTTPS15.jpg

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

1571821429149_Django+HTTPS16.jpg

分享到:
在線(xiàn)咨詢(xún) 我要報(bào)名
和我們?cè)诰€(xiàn)交談!