大型網站的HTTPS實踐（一）——HTTPS協議和原理

前言

百度於2015年上線了全站HTTPS的安全搜尋，預設會將HTTP請求跳轉成HTTPS。從今天開始，我們將會分享多篇系列文章，為大家重點介紹和解析百度的HTTPS最佳實踐。

HTTPS協議概述

HTTPS可以認為是HTTP+TLS。

HTTP協議大家耳熟能詳了，目前大部分WEB應用和網站都是使用HTTP協議傳輸的。

TLS是傳輸層加密協議，它的前身是SSL協議，最早由Netscape公司於1995年釋出，1999年經過IETF討論和規範後，改名為TLS。如果沒有特別說明，SSL和TLS說的都是同一個協議。

HTTP和TLS在協議層的位置以及TLS協議的組成如下圖：

圖1  TLS協議格式

TLS協議主要有五部分：應用資料層協議，握手協議，報警協議，加密訊息確認協議，心跳協議。

TLS協議本身又是由Record協議傳輸的，Record協議的格式如上圖最右所示。

目前常用的HTTP協議是HTTP1.1，常用的TLS協議版本有如下幾個：TLS1.3，TLS1.2,TLS1.1,TLS1.0和SSL3.0。其中SSL3.0由於POODLE攻擊已經被證明不安全，但統計發現依然有不到1%的瀏覽器使用SSL3.0。TLS1.0也存在部分安全漏洞，比如RC4和BEAST攻擊。過去由於主流Web瀏覽器和應用程式中的TLS實現都支援降級協商過程，導致即使伺服器支援最新版本，攻擊者也有機會利用較弱的協議實施攻擊。因此到2020年，所有主流Web瀏覽器都將取消TLS1.0和TLS1.1的支援。

TLS1.2暫時沒有已知的安全漏洞，比較安全，同時有大量擴充套件提升速度和效能，當前被較為普遍的使用。

需要關注一點的就是TLS1.3是TLS協議一個非常重大的改革。不管是安全性還是使用者訪問速度都會有質的提升。TLS1.3協議的最終版本（RFC8446）已於2018年8月10日釋出，各主流瀏覽器也逐漸支援TLS1.3。

同時HTTP2也於2015年5月正式定稿（RFC7540），這個由SPDY協議演化而來的協議相比HTTP1.1又是一個非常重大的變動，能夠明顯提升應用層資料的傳輸效率。

HTTPS功能介紹

百度使用HTTPS協議主要是為了保護使用者隱私，防止流量劫持。

HTTP本身是明文傳輸的，沒有經過任何安全處理。例如使用者在百度搜尋了一個關鍵字，比如“蘋果手機”，中間者完全能夠檢視到這個資訊，並且有可能打電話過來騷擾使用者。也有一些使用者投訴使用百度時，發現首頁或者結果頁面浮了一個很長很大的廣告，這也肯定是中間者往頁面插的廣告內容。如果劫持技術比較低劣的話，使用者甚至無法訪問百度。

這裡提到的中間者主要指一些網路節點，是使用者資料在瀏覽器和百度伺服器中間傳輸必須要經過的節點。比如WIFI熱點，路由器，防火牆，反向代理，快取伺服器等。

在HTTP協議下，中間者可以隨意嗅探使用者搜尋內容，竊取隱私甚至篡改網頁。不過HTTPS是這些劫持行為的剋星，能夠完全有效地防禦。

總體來說，HTTPS協議提供了三個強大的功能來對抗上述的劫持行為：

1. 內容加密。瀏覽器到百度伺服器的內容都是以加密形式傳輸，中間者無法直接檢視原始內容；

2. 身份認證。保證使用者訪問的是百度服務，即使被DNS劫持到了第三方站點，也會提醒使用者沒有訪問百度服務，有可能被劫持；

3. 資料完整性。防止內容被第三方冒充或者篡改。

那HTTPS是如何做到上述三點的呢？下面從原理角度介紹一下。

HTTPS原理介紹

1內容加密

加密演算法一般分為兩種，對稱加密和非對稱加密。所謂對稱加密（也叫金鑰加密）就是指加密和解密使用的是相同的金鑰。而非對稱加密（也叫公鑰加密）就是指加密和解密使用了不同的金鑰。

圖2  對稱加密

圖3  非對稱加密

對稱內容加密強度非常高，一般破解不了。但存在一個很大的問題就是無法安全地生成和保管金鑰。假如客戶端軟體和伺服器之間每次會話都使用固定的、相同的金鑰加密和解密，肯定存在很大的安全隱患。如果有人從客戶端獲取到了對稱金鑰，整個內容就不存在安全性了，而且管理海量的客戶端金鑰也是一件很複雜的事情。

非對稱加密主要用於金鑰交換（也叫金鑰協商），能夠很好地解決這個問題。瀏覽器和伺服器每次新建會話時都使用非對稱金鑰交換演算法協商出對稱金鑰，使用這些對稱金鑰完成應用資料的加解密和驗證，整個會話過程中的金鑰只在記憶體中生成和儲存，而且每個會話的對稱金鑰都不相同（除非會話複用），中間者無法竊取。

非對稱金鑰交換很安全，但同時也是HTTPS效能和速度嚴重降低的“罪魁禍首”。想要知道HTTPS為什麼影響速度，為什麼消耗資源，就一定要理解非對稱金鑰交換的整個過程。

下面重點介紹一下非對稱金鑰交換的數學原理及在TLS握手過程中的應用。

2非對稱祕鑰交換

在非對稱金鑰交換演算法出現以前，對稱加密一個很大的問題就是不知道如何安全生成和保管金鑰。非對稱金鑰交換過程主要就是為了解決這個問題，使得對稱金鑰的生成和使用更加安全。

金鑰交換演算法本身非常複雜，金鑰交換過程涉及到隨機數生成，模指數運算，空白補齊，加密，簽名等操作。

常見的金鑰交換演算法有RSA，ECDHE，DH，DHE等演算法。它們的特性如下：

1. RSA：演算法實現簡單，誕生於1977年，歷史悠久，經過了長時間的破解測試，安全性高。缺點就是需要比較大的素數（目前常用的是2048位）來保證安全強度，很消耗CPU運算資源。RSA是目前唯一一個既能用於金鑰交換又能用於證書籤名的演算法。

2. DH：Diffie-Hellman金鑰交換演算法，誕生時間比較早（1977年），但是1999年才公開。缺點是比較消耗CPU效能。

3. ECDHE：使用橢圓曲線（ECC）的DH演算法，優點是能用較小的素數（256位）實現RSA相同的安全等級。缺點是演算法實現複雜，用於金鑰交換的歷史不長，沒有經過長時間的安全攻擊測試。

4. ECDH：不支援PFS，安全性低，同時無法實現False Start。

5. DHE：不支援ECC。非常消耗CPU資源。

建議優先支援RSA和ECDH_RSA金鑰交換演算法。原因是：

1. ECDHE支援ECC加速，計算速度更快。支援PFS，更加安全。支援False Start，使用者訪問速度更快。

2. 目前還有至少20%以上的客戶端不支援ECDHE，我們推薦使用RSA而不是DH或者DHE，因為DH系列演算法非常消耗CPU（相當於要做兩次RSA計算）。

圖4  百度HTTPS連線詳情

需要注意通常所說的ECDHE金鑰交換預設都是指ECDHE_RSA，使用ECDHE生成DH演算法所需的公私鑰，然後使用RSA演算法進行簽名最後再計算得出對稱金鑰。

非對稱加密相比對稱加密更加安全，但也存在兩個明顯缺點：

1. CPU計算資源消耗非常大。一次完全TLS握手，金鑰交換時的非對稱解密計算量佔整個握手過程的90%以上。而對稱加密的計算量只相當於非對稱加密的0.1%，如果應用層資料也使用非對稱加解密，效能開銷太大，無法承受。

2. 非對稱加密演算法對加密內容的長度有限制，不能超過公鑰長度。比如現在常用的公鑰長度是2048位，意味著待加密內容不能超過256個位元組。

所以公鑰加密目前只能用來作金鑰交換或者內容簽名，不適合用來做應用層傳輸內容的加解密。

非對稱金鑰交換演算法是整個HTTPS得以安全的基石，充分理解非對稱金鑰交換演算法是理解HTTPS協議和功能的關鍵。

總  結

在接下來的文章中我們會繼續通俗地介紹一下RSA和ECDHE在金鑰交換過程中的應用，敬請期待。

文章整理自百度HTTPS技術聯合團隊

↓↓↓ 點選"閱讀原文" 【瞭解更多精彩內容】