前綴https和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證書的合法性，間接表明公鑰來源的合法性)。

自簽證書實現django+http+ssl

由於正規的證書需要向CA機構申請，在此，我通過自簽證書的形式簡單配置一個基於https通信的django伺服器。

(1)、創建簽發CA根證書的配置文件MyCompanyCA.cnf