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

原創?網絡通信/物聯網?作者：AIOps智能運維?時間：2018-11-09 15:07:39??349??0

前言

百度于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協議提供了三個強大的功能來對抗上述的劫持行為：

內容加密。瀏覽器到百度服務器的內容都是以加密形式傳輸，中間者無法直接查看原始內容；
身份認證。保證用戶訪問的是百度服務，即使被DNS劫持到了第三方站點，也會提醒用戶沒有訪問百度服務，有可能被劫持；
數據完整性。防止內容被第三方冒充或者篡改。

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

HTTPS原理介紹

1內容加密

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

圖2? 對稱加密

圖3? 非對稱加密

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

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

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

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

2非對稱秘鑰交換

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

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

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

RSA：算法實現簡單，誕生于1977年，歷史悠久，經過了長時間的破解測試，安全性高。缺點就是需要比較大的素數（目前常用的是2048位）來保證安全強度，很消耗CPU運算資源。RSA是目前唯一一個既能用于密鑰交換又能用于證書簽名的算法。
DH：Diffie-Hellman密鑰交換算法，誕生時間比較早（1977年），但是1999年才公開。缺點是比較消耗CPU性能。
ECDHE：使用橢圓曲線（ECC）的DH算法，優點是能用較小的素數（256位）實現RSA相同的安全等級。缺點是算法實現復雜，用于密鑰交換的歷史不長，沒有經過長時間的安全攻擊測試。
ECDH：不支持PFS，安全性低，同時無法實現False Start。
DHE：不支持ECC。非常消耗CPU資源。

建議優先支持RSA和ECDH_RSA密鑰交換算法。原因是：

ECDHE支持ECC加速，計算速度更快。支持PFS，更加安全。支持False Start，用戶訪問速度更快。
目前還有至少20%以上的客戶端不支持ECDHE，我們推薦使用RSA而不是DH或者DHE，因為DH系列算法非常消耗CPU（相當于要做兩次RSA計算）。

圖4? 百度HTTPS連接詳情

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

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

CPU計算資源消耗非常大。一次完全TLS握手，密鑰交換時的非對稱解密計算量占整個握手過程的90%以上。而對稱加密的計算量只相當于非對稱加密的0.1%，如果應用層數據也使用非對稱加解密，性能開銷太大，無法承受。
非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。比如現在常用的公鑰長度是2048位，意味著待加密內容不能超過256個字節。

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

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

總? 結

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