HTTPS原理

摘要： 本文主要內容 概念 加密演算法 HTTPS原理 總結 1、概念 HTTP 協議（HyperText Transfer Protocol，超文字傳輸協議）：是客戶端瀏覽器或其他程式與Web伺服器之間的應用層通訊協議 。 HTTPS ...

本文主要內容

• 概念
• 加密演算法
• HTTPS原理
• 總結

1、概念

• 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，可以把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.1、TLS 1.2 三個版本。SSL3.0和TLS1.0由於存在安全漏洞，已經很少被使用到。TLS 1.3 改動會比較大，目前還在草案階段，目前使用最廣泛的是TLS 1.1、TLS 1.2。

2、加密演算法

HTTPS 協議中用了不同的加密演算法，在此我們學習下加密演算法的基礎知識，加密演算法有對稱加密和非對稱加密的方式。

• 對稱加密，有流式、分組兩種，加密和解密都是使用的同一個金鑰。例如：DES、AES-GCM、ChaCha20-Poly1305等

• 非對稱加密，加密使用的金鑰和解密使用的金鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和演算法都是公開的，私鑰是保密的。非對稱加密演算法效能較低，但是安全性超強，由於其加密特性，非對稱加密演算法能加密的資料長度也是有限的。例如：RSA、DSA、ECDSA、 DH、ECDHE

由此可見，使用 git 即是使用非對稱加密，我們需要在網頁端填寫公鑰值。

除加密方法外，還有其它方法可以在一定程度上保證安全性

• 雜湊演算法，將任意長度的資訊轉換為較短的固定長度的值，通常其長度要比資訊小得多，且演算法不可逆。例如：MD5、SHA-1、SHA-2、SHA-256 等

此前闡述過 android apk 簽名及驗證過程，裡邊就有涉及 SHA-256 演算法等，通過此演算法可以驗證資訊有沒有被修改，如果修改了，雜湊之後得到的值肯定會變化，所以雜湊演算法可以用於鑑定資訊是否被篡改。

• 數字簽名，保證資訊傳輸的完整性、傳送者的身份認證、防止交易中的抵賴發生。 數字簽名技術是將摘要資訊用傳送者的私鑰加密，與原文一起傳送給接收者。 接收者只有用傳送者的公鑰才能解密被加密的摘要資訊，然後用對收到的原文產生一個摘要資訊，與解密的摘要資訊對比。

3、HTTPS原理

HTTP 協議是明文協議，使用它通訊，存在三個風險：

• 竊聽風險（eavesdropping）：第三方可以獲知通訊內容。
• 篡改風險（tampering）：第三方可以修改通訊內容。
• 冒充風險（pretending）：第三方可以冒充他人身份參與通訊。

為了解決這三個問題，HTTPS 協議可以說是煞費苦心。

第1步，既然明文協議不安全，那就執行加密通訊

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

• 不同的客戶端、伺服器數量龐大，所以雙方都需要維護大量的金鑰，維護成本很高
• 因每個客戶端、伺服器的安全級別不同，金鑰極易洩露

第2步，既然對稱加密不行，我們換成非對稱加密試試：

如上圖所示，客戶端使用公鑰傳送主動，服務端使用私鑰解密請求，並且將響應內容加密，發給客戶端。但上述過程也存在缺點：

• 公鑰是公開的（也就是黑客也會有公鑰），所以第 ④ 步私鑰加密的資訊，如果被黑客截獲，其可以使用公鑰進行解密，獲取其中的內容

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

如上圖所示：

• 第 ③ 步時，客戶端說：（咱們後續回話採用對稱加密吧，這是對稱加密的演算法和對稱金鑰）這段話用公鑰進行加密，然後傳給伺服器

• 伺服器收到資訊後，用私鑰解密，提取出對稱加密演算法和對稱金鑰後，伺服器說：（好的）對稱金鑰加密

• 後續兩者之間資訊的傳輸就可以使用對稱加密的方式了

這裡存在兩個問題，客戶端如何獲取公鑰呢？如何確定這是真實的伺服器而不是黑客呢？如果客戶端到某個地址去下載公鑰，下載地址有可能是假的，而且每次對話之前還要去下載，很麻煩。如果是伺服器主動將公鑰交給客戶端，客戶端怎麼確定伺服器是真實的而不是黑客冒充的呢？

為了解決公鑰問題，SSL證書派上用場了。

在第2步中，伺服器會將一個SSL證書傳送給客戶端，SSL證書稽核嚴格而且還是要收費的，它不會被冒充。客戶端接收證書後，會對證書進行驗證，證書驗證為真後，客戶端會從SSL證書中讀取出一個公鑰，用於接下來的非對稱加密。在非對稱加密中，客戶端將對稱加密的金鑰發給伺服器，伺服器接收後，後續的通訊就可以使用對稱加密了。

SSL證書的驗證過程：

（1）首先瀏覽器讀取證書中的證書所有者、有效期等資訊進行一一校驗

（2）瀏覽器開始查詢作業系統中已內建的受信任的證書釋出機構CA，與伺服器發來的證書中的頒發者CA比對，用於校驗證書是否為合法機構頒發

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

（4）如果找到，那麼瀏覽器就會從作業系統中取出 頒發者CA 的公鑰，然後對伺服器發來的證書裡面的簽名進行解密

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

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

4、總結

HTTPS協議比HTTP協議安全可靠，整個過程中黑客也沒有辦法監聽或者篡改、冒充了。

（1） 所有信息都是加密傳播，黑客無法竊聽。

（2） 具有校驗機制，一旦被篡改，通訊雙方會立刻發現。

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

另外需要提一點的就是TCP協議和 HTTP 及 HTTPS 協議的關係，TPC/IP協議是傳輸層協議，主要解決資料如何在網路中傳輸，而HTTP是應用層協議，主要解決如何包裝資料。

關於TCP/IP和HTTP協議的關係，網路有一段比較容易理解的介紹：“我們在傳輸資料時，可以只使用（傳輸層）TCP/IP協議，但是那樣的話，如果沒有應用層，便無法識別資料內容，如果想要使傳輸的資料有意義，則必須使用到應用層協議，應用層協議有很多，比如HTTP、FTP、TELNET等。

HTTPS 協議在android應用時，與 HTTP 協議有一些差別，注意這些即可。