探祕HTTPS

今天給大家分享下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報文結構如下:point_down:

• HTTP發展歷程如下:point_down:

版本	產生時間	內容概括	發展現狀
HTTP/0.9	1991年	不涉及數據包傳輸，規定客户端和服務器之間通信格式，只能GET請求	非正式標準
HTTP/1.0	1996年	傳輸內容、格式、首部和數組大小不限制，增加POST、PUT、PATCH、HEAD、 OPTIONS、DELETE方式	正式標準，廣泛使用
HTTP/1.1	1997年	持久連接(長連接)、節約帶寬、HOST域、管道機制、分塊傳輸編碼	最為廣泛
HTTP/2	2015年	多路複用、服務器推送、頭信息壓縮、二進制協議等。必須搭配TLS，也就是默認使用HTTPS	逐漸興起

由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.加密方式

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

對稱加密

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

廣泛使用的對稱加密有：

DES(Data Encryption Standard)	數據加密標準，速度較快，適用於加密大量數據的場合。目前DES已經不是一種安全的加密方法，主要因為它使用的56位密鑰過短
3DES(Triple DES)	基於DES，對一塊數據用三個不同的密鑰進行三次加密，強度更高。可以解決因計算機運算能力的增強，DES容易被暴力破解的問題
AES(Advanced Encryption Standard)	高級加密標準，是下一代的加密算法標準，速度快，安全級別高，支持128、192、256、512位密鑰的加密

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

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

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

可以在線體驗:point_right: 對稱加密 ^[1]

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

非對稱加密

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

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

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

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

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

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

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

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

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

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

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

如何選擇？

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

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

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

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

III.CA

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

數字簽名

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

• 通常情況下，數字證書的申請人（服務器）將生成由私鑰和公鑰以及證書請求文件（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請求全流程如下圖:point_down:

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的優缺點:point_down:

HTTPS優點	HTTPS缺點
使用 HTTPS 協議可認證用户和服務器，確保數據發送到正確的客户機和服務器	HTTPS時間是HTTP的2-100倍，因為需要經歷SSL（TLS）握手，且非對稱加密速度較慢
安全可靠，防止數據在傳輸過程中被竊取、改變，確保數據的完整性	HTTPS 協議的安全是有範圍的，在黑客攻擊、拒絕服務攻擊和服務器劫持等方面幾乎起不到什麼作用
HTTPS 是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本	SSL 證書的信用鏈體系並不安全。特別是在某些國家可以控制 CA根證書的情況下，中間人攻擊一樣可行

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

參考

《圖解HTTP》

RSA算法原理 ^[3]

HTTPS升級指南 ^[4]

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

參考資料