理解HTTPS及配置Django+HTTPS開發環境HTTP的弊端及HTTPS的由來對稱加密非對稱加密CA認證機制自簽證書實現django+http+ssl

發布時間：2023-07-03 02:40:07 作者：網友整理

HTTP的弊端及HTTPS的由來

眾所周知HTTP協議是以TCP協議為基石誕生的一個用于傳輸Web內容的一個網絡協議,在"網絡分層模型"中屬于"應用層協議"的一種.那么在這里我們并不研究該協議標準本身,而是從安全角度去探究使用該協議傳輸數據本身存在的安全問題:

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

為了解決HTTP協議存在的安全性問題,上世紀90年代由網景(NetScape)公司設計了SSL(Secure Sockets Layer)協議——"安全套接層"協議.經過多年發展SSL在互聯網上廣泛應用,標準化后名稱改為TLS(Transport Layer Security)——"傳輸層安全"協議.

所謂的HTTPS即是"HTTP+SSL/TLS"的結合使用而已.解決的是HTTP協議數據傳輸的安全性問題——在HTTP協議層和TCP傳輸層之間加入"安全層",使得應用層數據報經過加密后再傳輸,保證數據在傳輸過程中的完整性.

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

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

對稱加密

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

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

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

非對稱加密

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

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

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

非對稱加密中的竊聽風險圖示

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

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

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

CA認證機制

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

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

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