【轉】HTTPS系列乾貨（一）：HTTPS 原理詳解

HTTPS系列乾貨（一）：HTTPS 原理詳解

前言

HTTPS（全稱：HyperText Transfer Protocol over Secure Socket Layer），其實 HTTPS 並非一個新鮮協議，Google 很早就開始啓用了，初衷是爲了保證數據安全。 近兩年，Google、Baidu、Facebook 等這樣的互聯網巨頭，不謀而合地開始大力推行 HTTPS， 國內外的大型互聯網公司不少也都已經啓用了全站 HTTPS，這也是將來互聯網發展的趨勢。

爲鼓勵全球網站的 HTTPS 實現，一些互聯網公司都提出了本身的要求：

1）Google 已調整搜索引擎算法，讓採用 HTTPS 的網站在搜索中排名更靠前；

2）從 2017 年開始，Chrome 瀏覽器已把採用 HTTP 協議的網站標記爲不安全網站；

3）蘋果要求 2017 年 App Store 中的全部應用都必須使用 HTTPS 加密鏈接；

4）當前國內炒的很火熱的微信小程序也要求必須使用 HTTPS 協議；

5）新一代的 HTTP/2 協議的支持需以 HTTPS 爲基礎。

等等，所以想必在不久的未來，全網 HTTPS 勢在必行。

概念

協議

一、HTTP 協議（HyperText Transfer Protocol，超文本傳輸協議）：是客戶端瀏覽器或其餘程序與Web服務器之間的應用層通訊協議 。

二、HTTPS 協議（HyperText Transfer Protocol over Secure Socket Layer）：能夠理解爲HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL，所以加密的詳細內容就須要 SSL，用於安全的 HTTP 數據傳輸。

    如上圖所示  HTTPS 相比 HTTP 多了一層 SSL/TLS

    SSL（Secure Socket Layer，安全套接字層）：1994年爲 Netscape 所研發，SSL 協議位於 TCP/IP 協議與各類應用層協議之間，爲數據通信提供安全支持。

    TLS（Transport Layer Security，傳輸層安全）：其前身是 SSL，它最初的幾個版本（SSL 1.0、SSL 2.0、SSL 3.0）由網景公司開發，1999年從 3.1 開始被 IETF 標準化並更名，發展至今已經有 TLS 1.0、TLS 1.一、TLS 1.2 三個版本。SSL3.0和TLS1.0因爲存在安全漏洞，已經不多被使用到。TLS 1.3 改動會比較大，目前還在草案階段，目前使用最普遍的是TLS 1.一、TLS 1.2。

加密算法：

據記載，公元前400年，古希臘人就發明了置換密碼；在第二次世界大戰期間，德國軍方啓用了「恩尼格瑪」密碼機，因此密碼學在社會發展中有着普遍的用途。

一、對稱加密

有流式、分組兩種，加密和解密都是使用的同一個密鑰。

例如：DES、AES-GCM、ChaCha20-Poly1305等

二、非對稱加密

加密使用的密鑰和解密使用的密鑰是不相同的，分別稱爲：公鑰、私鑰，公鑰和算法都是公開的，私鑰是保密的。非對稱加密算法性能較低，可是安全性超強，因爲其加密特性，非對稱加密算法能加密的數據長度也是有限的。

例如：RSA、DSA、ECDSA、 DH、ECDHE

三、哈希算法

將任意長度的信息轉換爲較短的固定長度的值，一般其長度要比信息小得多，且算法不可逆。

例如：MD五、SHA-一、SHA-二、SHA-256 等

四、數字簽名

簽名就是在信息的後面再加上一段內容（信息通過hash後的值），能夠證實信息沒有被修改過。hash值通常都會加密後（也就是簽名）再和信息一塊兒發送，以保證這個hash值不被修改。

詳解

1、HTTP 訪問過程

抓包以下：

如上圖所示，HTTP請求過程當中，客戶端與服務器之間沒有任何身份確認的過程，數據所有明文傳輸，「裸奔」在互聯網上，因此很容易遭到黑客的攻擊，以下：

能夠看到，客戶端發出的請求很容易被黑客截獲，若是此時黑客冒充服務器，則其可返回任意信息給客戶端，而不被客戶端察覺，因此咱們常常會聽到一詞「劫持」，現象以下：

下面兩圖中，瀏覽器中填入的是相同的URL，左邊是正確響應，而右邊則是被劫持後的響應

因此 HTTP 傳輸面臨的風險有：

（1） 竊聽風險：黑客能夠獲知通訊內容。

（2） 篡改風險：黑客能夠修改通訊內容。

（3） 冒充風險：黑客能夠冒充他人身份參與通訊。

2、HTTP 向 HTTPS 演化的過程

第一步：爲了防止上述現象的發生，人們想到一個辦法：對傳輸的信息加密（即便黑客截獲，也沒法破解）

如上圖所示，此種方式屬於對稱加密，雙方擁有相同的密鑰，信息獲得安全傳輸，但此種方式的缺點是：

（1）不一樣的客戶端、服務器數量龐大，因此雙方都須要維護大量的密鑰，維護成本很高

（2）因每一個客戶端、服務器的安全級別不一樣，密鑰極易泄露

第二步：既然使用對稱加密時，密鑰維護這麼繁瑣，那咱們就用非對稱加密試試

如上圖所示，客戶端用公鑰對請求內容加密，服務器使用私鑰對內容解密，反之亦然，但上述過程也存在缺點：

（1）公鑰是公開的（也就是黑客也會有公鑰），因此第 ④ 步私鑰加密的信息，若是被黑客截獲，其可使用公鑰進行解密，獲取其中的內容

第三步：非對稱加密既然也有缺陷，那咱們就將對稱加密，非對稱加密二者結合起來，取其精華、去其糟粕，發揮二者的各自的優點

如上圖所示

（1）第 ③ 步時，客戶端說：（我們後續回話採用對稱加密吧，這是對稱加密的算法和對稱密鑰）這段話用公鑰進行加密，而後傳給服務器

（2）服務器收到信息後，用私鑰解密，提取出對稱加密算法和對稱密鑰後，服務器說：（好的）對稱密鑰加密

（3）後續二者之間信息的傳輸就可使用對稱加密的方式了

遇到的問題：

（1）客戶端如何得到公鑰

（2）如何確認服務器是真實的而不是黑客

第四步：獲取公鑰與確認服務器身份

一、獲取公鑰

（1）提供一個下載公鑰的地址，回話前讓客戶端去下載。（缺點：下載地址有多是假的；客戶端每次在回話前都先去下載公鑰也很麻煩）
（2）回話開始時，服務器把公鑰發給客戶端（缺點：黑客冒充服務器，發送給客戶端假的公鑰）

二、那有木有一種方式既能夠安全的獲取公鑰，又能防止黑客冒充呢？   那就須要用到終極武器了：SSL 證書（申購）

如上圖所示，在第 ② 步時服務器發送了一個SSL證書給客戶端，SSL 證書中包含的具體內容有：

（1）證書的發佈機構CA

（2）證書的有效期

（3）公鑰

（4）證書全部者

（5）簽名

………

三、客戶端在接受到服務端發來的SSL證書時，會對證書的真僞進行校驗，以瀏覽器爲例說明以下：

（1）首先瀏覽器讀取證書中的證書全部者、有效期等信息進行一一校驗

（2）瀏覽器開始查找操做系統中已內置的受信任的證書發佈機構CA，與服務器發來的證書中的頒發者CA比對，用於校驗證書是否爲合法機構頒發 

（3）若是找不到，瀏覽器就會報錯，說明服務器發來的證書是不可信任的。

（4）若是找到，那麼瀏覽器就會從操做系統中取出  頒發者CA  的公鑰，而後對服務器發來的證書裏面的簽名進行解密

（5）瀏覽器使用相同的hash算法計算出服務器發來的證書的hash值，將這個計算的hash值與證書中籤名作對比

（6）對比結果一致，則證實服務器發來的證書合法，沒有被冒充

（7）此時瀏覽器就能夠讀取證書中的公鑰，用於後續加密了

四、因此經過發送SSL證書的形式，既解決了公鑰獲取問題，又解決了黑客冒充問題，一舉兩得，HTTPS加密過程也就此造成

    因此相比HTTP，HTTPS 傳輸更加安全

（1） 全部信息都是加密傳播，黑客沒法竊聽。

（2） 具備校驗機制，一旦被篡改，通訊雙方會馬上發現。

（3） 配備身份證書，防止身份被冒充。

總結

綜上所述，相比 HTTP 協議，HTTPS 協議增長了不少握手、加密解密等流程，雖然過程很複雜，但其能夠保證數據傳輸的安全。因此在這個互聯網膨脹的時代，其中隱藏着各類看不見的危機，爲了保證數據的安全，維護網絡穩定，建議你們多多推廣HTTPS。

HTTPS 缺點：

（1）SSL 證書費用很高，以及其在服務器上的部署、更新維護很是繁瑣

（2）HTTPS 下降用戶訪問速度（屢次握手）

（3）網站改用HTTPS 之後，由HTTP 跳轉到 HTTPS 的方式增長了用戶訪問耗時（多數網站採用302跳轉）

（4）HTTPS 涉及到的安全算法會消耗 CPU 資源，須要增長大量機器（https訪問過程須要加解密）

……………

那如何解決上述這些問題呢，且見下回分解！