今天給大家分享下 HTTPS 的相關知識。作爲前端工程師，對於天天打交道的 HTTP 我們肯定都熟得不能再熟了，每一次通過瀏覽器發出的請求都是需要符合 HTTP 協議的。那麼 HTTPS 和 HTTP 的區別大家瞭解嗎？

這是一個經典的面試題，大部分人會這麼回答

1. HTTPS 比 HTTP 多了一個 S(Secure)，也就是說 HTTPS 是安全版的 HTTP

2. 端口號不同。HTTP 使用 80 端口，HTTPS 使用 443 端口

3. HTTPS 用的是非對稱加密算法

上面的回答能給幾分？等看完本文我們可以再回頭來看下這個回答

那麼，HTTPS 是如何實現安全的數據傳輸呢？想徹底搞明白這個問題，就需要了解 HTTP 的發展歷程、HTTP 遇到的問題、對稱與非對稱加密算法、數字簽名、第三方證書頒發機構等概念。

所以，想要全面瞭解 HTTPS，還是要從 HTTP 的發展歷程說起......

I.HTTP

HTTP 是 Hypertext Transfer Protocal 的縮寫，中文全稱是超文本傳輸協議。

• 超文本是指包含但不限於文本外的圖片、音頻、視頻等多媒體資源。

• 協議是通信雙方約定好的數據傳輸格式以及通信規則。

HTTP 是 TCP/IP 協議簇的最高層 -- 應用層協議。

瀏覽器和服務器在使用 HTTP 協議相互傳遞超文本數據時，將數據放入報文體內，同時填充首部 (請求頭或響應頭) 構成完整 HTTP 報文並交到下層傳輸層，之後每一層加上相應的首部（控制部分）便一層層的下發，最終由物理層將二進制數據以電信號的形式發送出去。HTTP 報文結構如下👇

• HTTP 發展歷程如下👇

y3wjFH

由 HTTP 的發展歷程來看，最開始版本的 HTTP(HTTP1.0) 在每次建立 TCP 連接後只能發起一次 HTTP 請求，請求完畢就釋放 TCP 連接。我們都知道 TCP 連接的建立需要經過三次握手的過程，而每次發送 HTTP 請求都需要重新建立 TCP 連接，毫無疑問是很低效的。所以 HTTP1.1 改善了這一點，使用長連接的機制，也就是 “一次 TCP 連接，N 次 HTTP 請求”。

HTTP 協議的長連接和短連接，實質上是 TCP 協議的長連接和短連接。

在使用長連接的情況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸 HTTP 數據的 TCP 連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive 不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如 Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。

（HTTP1.0 若要開啓長連接，需要加上 Connection: keep-alive 請求頭）

• 隨着 HTTP 越來越廣泛的使用，HTTP 的安全性問題也逐漸暴露。

  回憶一下多年前遍地都是的運營商劫持，當你訪問一個本來很正常的網頁，但頁面上卻莫名其妙出現了一些廣告標籤、跳轉腳本、欺騙性的紅包按鈕，甚至有時候本來要下載一個文件，最後下載下來卻變成了另外一個完全不同的東西，這些都是被運營商劫持了 HTTP 明文數據的現象。

  HTTP 有以下 3 點安全性問題：

• 數據保密性問題

  因爲 HTTP 無狀態，而且又是明文傳輸，所有數據內容都在網絡中裸奔，包用戶括身份信息、支付賬號與密碼。這些敏感信息極易泄露造成安全隱患。

• 數據完整性問題

  HTTP 數據包在到達目的主機前會經過很多轉發設備，每一個設備節點都可能會篡改或調包信息，無法驗證數據的完整性。

• 身份校驗問題

  有可能遭受中間人攻擊，我們無法驗證通信的另一方就是我們的目標對象。

因此，爲了保證數據傳輸的安全性，必須要對 HTTP 數據進行加密。

II. 加密方式

加密方式分爲三種：對稱加密、非對稱加密、數字摘要。前兩種適合數據傳輸加密，而數字摘要不可逆的特性常被用於數字簽名。

對稱加密

對稱加密也稱爲密鑰加密或單向加密，就是使用同一套密鑰來進行加密和解密。密鑰可以理解爲加密算法。對稱加密圖示如下👇

廣泛使用的對稱加密有：

LTai2K

• 優點：算法公開、簡單，加密解密容易，加密速度快，效率高。

• 缺點：相對來說不算特別安全，只有一把鑰匙，密文如果被攔截，且密鑰也被劫持，那麼，信息很容易被破譯。

• 適用場景：加解密速度快、效率高，因此適用於大量數據的加密場景。由於如何傳輸密鑰是較爲頭痛的問題，因此適用於無需進行密鑰交換的場景，如內部系統，事先就可以直接確定密鑰。

可以在線體驗👉對稱加密 [1]

P.S. base64 編碼也屬於對稱加密哦

非對稱加密

非對稱加密使用一對密鑰 (公鑰和私鑰) 進行加密和解密。非對稱加密可以在不直接傳遞密鑰的情況下，完成解密，具體步驟如下👇：

1. 乙方生成兩把密鑰（公鑰和私鑰）。公鑰是公開的，任何人都可以獲得，私鑰則是保密的。

2. 甲方獲取乙方的公鑰，然後用它對信息加密。

3. 乙方得到加密後的信息，用私鑰解密。

以最典型的非對稱加密算法 --RSA 算法舉個例子：

想要徹底搞懂 RSA，需要了解數論的知識，全部推導過程 RSA 加密算法 [2]。本文簡單介紹思路：使用兩個超大質數以及其乘積作爲生成公鑰和私鑰的材料，想要從公鑰推算出私鑰是非常困難的（需要對超大數因式分解爲兩個很大質數的乘積）。目前被破解的最長 RSA 密鑰是 768 個二進制位。也就是說，長度超過 768 位的密鑰，還無法破解（至少沒人公開宣佈）。因此可以認爲，1024 位的 RSA 密鑰基本安全，2048 位的密鑰極其安全。

• 優點：強度高、安全性強於對稱加密算法、無需傳遞私鑰導致沒有密鑰泄露風險

• 缺點：計算量大、速度慢

• 適用場景：適用於需要密鑰交換的場景，如互聯網應用，無法事先約定密鑰。可以與對稱加密算法結合：

• 利用非對稱加密算法安全性較好的特點來傳遞對稱加密算法的密鑰。

• 利用對稱加密算法加解密速度快的特點，進行數據內容比較大的加密場景的加密。如 HTTPS。

如何選擇？

• 選擇對稱加密：HTTP 請求方使用對稱算法加密數據，那麼爲了接收方能夠解密，發送方還需要把密鑰一同傳遞到接收方。在傳遞密鑰的過程中還是可能遭到嗅探攻擊，攻擊者竊取密鑰後依然可以解密從而得到發送的數據，所以這種方案不可行

• 選擇非對稱加密：接收方保留私鑰，把公鑰傳遞給發送方。發送方用公鑰來加密數據。接收方使用私鑰解密數據。攻擊者雖然不能直接獲取這些數據（因爲沒有私鑰），但是可以通過攔截傳遞的公鑰，然後把自己的公鑰傳給發送方，再用自己的私鑰對發送方發送數據進行解密。整個過程通信雙方都不知道中間人的存在，但是中間人能夠獲得完整的數據信息

• 兩種混合：先使用非對稱加密算法加密並傳遞對稱加密的密鑰，然後雙方通過對稱加密方式加密要發送的數據。看起來沒什麼問題，但事實是這樣嗎？ 中間人依然可以攔截公鑰的傳遞，並以自己的公鑰作爲替換，治標不治本。

想要治本，就要找到一個第三方公證人來證明公鑰沒有被替換，因此就引出了 CA 的概念

III.CA

CA 就是 Certificate Authority，頒發數字證書的機構。作爲受信任的第三方，CA 承擔公鑰體系中公鑰的合法性檢驗的責任。證書就是源服務器向可信任的第三方機構申請的數據文件。這個證書除了表明這個域名是屬於誰的，頒發日期等，還包括了第三方證書的私鑰。服務器將公鑰放在數字證書中，只要證書是可信的，公鑰就是可信的。下圖是飛書域名的證書中部分內容的信息👇

數字簽名

• 摘要算法一般用哈希函數來實現，可以理解成一種定長的壓縮算法，它能把任意長度的數據壓縮到固定長度。這好比是給數據加了一把鎖，對數據有任何微小的改動都會使摘要變得截然不同。

• 通常情況下，數字證書的申請人（服務器）將生成由私鑰和公鑰以及證書請求文件（Certificate Signing Request，CSR）組成的密鑰對。CSR 是一個編碼的文本文件，其中包含公鑰和其他將包含在證書中的信息（例如域名，組織，電子郵件地址等）。密鑰對和 CSR 生成通常在將要安裝證書的服務器上完成，並且 CSR 中包含的信息類型取決於證書的驗證級別。與公鑰不同，申請人的私鑰是安全的，永遠不要向 CA（或其他任何人）展示。

• 生成 CSR 後，申請人將其發送給 CA，CA 會驗證其包含的信息是否正確，如果正確，則使用頒發的私鑰對證書進行數字簽名，然後將簽名放在證書內隨證書一起發送給申請人。

• 在 SSL 握手階段，瀏覽器在收到服務器的證書後，使用 CA 的公鑰進行解密，取出證書中的數據、數字簽名以及服務器的公鑰。如果解密成功，則可驗證服務器身份真實。之後瀏覽器再對數據做 Hash 運算，將結果與數字簽名作對比，如果一致則可以認爲內容沒有收到篡改。

• 對稱加密和非對稱加密是公鑰加密，私鑰解密， 而數字簽名正好相反，是私鑰加密（簽名），公鑰解密（驗證）

IV.HTTPS

《圖解 HTTP》書中提到 HTTPS 就是身披 SSL 外殼的 HTTP。

SSL 在 1999 年被更名爲 TLS

所以說，HTTPS 並不是一項新的應用層協議，只是 HTTP 通信接口部分由 SSL 和 TLS 替代而已。HTTP 會先直接和 TCP 進行通信。而 HTTPS 會演變爲先和 SSL 進行通信，然後再由 SSL 和 TCP 進行通信。SSL 是一個獨立的協議，不只有 HTTP 可以使用，其他應用層協議也可以使用，比如 FTP、SMTP 都可以使用 SSL 來加密。

HTTPS 請求全流程如下圖👇

1. 用戶在瀏覽器發起 HTTPS 請求，默認使用服務端的 443 端口進行連接；

2. HTTPS 需要使用一套 CA 數字證書，證書內會附帶一個服務器的公鑰 Pub，而與之對應的私鑰 Private 保留在服務端不公開；

3. 服務端收到請求，返回配置好的包含公鑰 Pub 的證書給客戶端；

4. 客戶端收到證書，校驗合法性，主要包括是否在有效期內、證書的域名與請求的域名是否匹配，上一級證書是否有效（遞歸判斷，直到判斷到系統內置或瀏覽器配置好的根證書），如果不通過，則顯示 HTTPS 警告信息，如果通過則繼續；

5. 客戶端生成一個用於對稱加密的隨機 Key，並用證書內的公鑰 Pub 進行加密，發送給服務端；

6. 服務端收到隨機 Key 的密文，使用與公鑰 Pub 配對的私鑰 Private 進行解密，得到客戶端真正想發送的隨機 Key；

7. 服務端使用客戶端發送過來的隨機 Key 對要傳輸的 HTTP 數據進行對稱加密，將密文返回客戶端；

8. 客戶端使用隨機 Key 對稱解密密文，得到 HTTP 數據明文；

9. 後續 HTTPS 請求使用之前交換好的隨機 Key 進行對稱加解密。

HTTPS 確實解決了 HTTP 的三個安全性問題：

（1） 保密性：結合非對稱加密和對稱加密實現保密性。用非對稱加密方式加密對稱加密的祕鑰，再用對稱加密方式加密數據

（2） 完整性：通過第三方 CA 的數字簽名解決完整性問題

（3） 身份校驗：通過第三方 CA 的數字證書驗證服務器的身份

最後我們總結一下 HTTPS 的優缺點👇

uQrv7e

可以看到，HTTPS 的確是當今安全傳輸 HTTP 的最優解，但他並不是完美的，仍會有漏洞

參考

• 《圖解 HTTP》

• RSA 算法原理 [3]

• HTTPS 升級指南 [4]

• SSL/TLS 協議運行機制的概述 [5]

參考資料

[1] 對稱加密: http://www.jsons.cn/textencrypt/

[2] RSA 加密算法: https://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html

[3] RSA 算法原理: https://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html

[4] HTTPS 升級指南: http://www.ruanyifeng.com/blog/2016/08/migrate-from-http-to-https.html

[5] SSL/TLS 協議運行機制的概述: https://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

歡迎關注公衆號 ELab 團隊 收穫大廠一手好文章~

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/mpoDKIsQbNdpuBNhnvvf-g