大型網站HTTPS 實踐(一)| HTTPS 協議和原理

大型網站HTTPS 實踐(一)| HTTPS 協議和原理

作者 | 百度HTTPS技術支援團隊

百度已經上線了全站 HTTPS 的安全搜尋,預設會將 HTTP 請求跳轉成 HTTPS。本文就著重介紹了 HTTPS 協議涉及到的重要知識點和平時不太容易理解的盲區,希望能對大家理解 HTTPS 協議有幫助。百度 HTTPS 效能優化涉及到大量內容,從前端頁面、後端架構、協議特性、加密演算法、流量排程、架構和運維、安全等方面都做了大量工作。本系列的文章將對此一一進行介紹。

HTTPS 協議概述

HTTPS 可以認為是 HTTP TLS。HTTP 協議大家耳熟能詳了,目前大部分 WEB 應用和網站都是使用 HTTP 協議傳輸的。

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

HTTP 和 TLS 在協議層的位置以及 TLS 協議的組成如下圖:
這裡寫圖片描述

TLS 協議主要有五部分:應用資料層協議,握手協議,報警協議,加密訊息確認協議,心跳協議。 TLS 協議本身又是由 record 協議傳輸的,record 協議的格式如上圖最右所示。
目前常用的 HTTP 協議是 HTTP1.1,常用的 TLS 協議版本有如下幾個:TLS1.2, TLS1.1, TLS1.0 和 SSL3.0。其中 SSL3.0 由於 POODLE 攻擊已經被證明不安全,但統計發現依然有不到 1% 的瀏覽器使用 SSL3.0。TLS1.0 也存在部分安全漏洞,比如 RC4 和 BEAST 攻擊。

TLS1.2 和 TLS1.1 暫時沒有已知的安全漏洞,比較安全,同時有大量擴充套件提升速度和效能,推薦大家使用。

需要關注一點的就是 TLS1.3 將會是 TLS 協議一個非常重大的改革。不管是安全性還是使用者訪問速度都會有質的提升。不過目前沒有明確的釋出時間。

HTTPS 功能介紹

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

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

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

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

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

內容加密。瀏覽器到百度伺服器的內容都是以加密形式傳輸,中間者無法直接檢視原始內容。
身份認證。保證使用者訪問的是百度服務,即使被 DNS 劫持到了第三方站點,也會提醒使用者沒有訪問百度服務,有可能被劫持
資料完整性。防止內容被第三方冒充或者篡改。
那 HTTPS 是如何做到上述三點的呢?下面從原理角度介紹一下。

HTTPS 原理介紹

1. 內容加密

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

非對稱金鑰交換

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

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

常見的金鑰交換演算法有 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。非常消耗效能。

百度只支援 RSA 和 ECDH_RSA 金鑰交換演算法。原因是:

1.ECDHE 支援 ECC 加速,計算速度更快。支援 PFS,更加安全。支援 false start,使用者訪問速度更快。

2.目前還有至少 20% 以上的客戶端不支援 ECDHE,我們推薦使用 RSA 而不是 DH 或者 DHE,因為 DH 系列演算法非常消耗 CPU(相當於要做兩次 RSA 計算)。
這裡寫圖片描述
需要注意通常所說的 ECDHE 金鑰交換預設都是指 ECDHE_RSA,使用 ECDHE 生成 DH 演算法所需的公私鑰,然後使用 RSA 演算法進行簽名最後再計算得出對稱金鑰。

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

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

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

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

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

下面分別通俗地介紹一下 RSA 和 ECDHE 在金鑰交換過程中的應用。

RSA 在金鑰交換過程中的應用

RSA 演算法的原理是乘法不可逆或者大數因子很難分解。RSA 的推導實現涉及到了尤拉函式和費馬定理及模反元素的概念,有興趣的讀者可以自行百度。

RSA 演算法是統治世界的最重要演算法之一,而且從目前來看,RSA 也是 HTTPS 體系中最重要的演算法,沒有之一。

下面用一個簡單的示例介紹一下 RSA 的神奇妙用。

假設一個網站需要使用 HTTPS 協議,那麼它首先就得申請數字證書,申請證書之前需要生成一對公鑰和私鑰,為了方便說明問題,假設 server 的金鑰長度只有 8 位,事實上現在的伺服器證書至少是 2048 位長。

1.隨機挑選兩個質數 p, q,使得 p_q 接近 2 的 8 次方 = 256, 假設 p = 13, q = 19。n = p_q = 13*19 = 247。

2.挑選一個數 e,滿足 1< e < (p-1)(q-1) 並且 e 與 (p-1)(q-1) 互質,假設 e = 53。

3.計算 e 關於 n 的模反元素 , ed≡1 (mod φ(n)), d =
實際應用中,(n,e) 組成了公鑰對,(n,d)組成了私鑰對。公鑰一般都註冊到了證書裡,任何人都能直接檢視,比如百度證書的公鑰對如下圖,其中最末 6 個數字(010001)換算成 10 進位制就是 65537,也就是公鑰對中的 e, 取值比較小的原因有兩個:

4.減小 client 端的計算強度,特別是現在移動終端的計算能力比較弱,較小的公鑰使得 CPU 計算會更快。

5.加大 server 端的破解難度。e 比較小,d 必然會非常大。所以 d 的取值空間也會非常大。
這裡寫圖片描述

ECDHE 演算法在金鑰交換中的應用

ECDHE 演算法實現要複雜很多,依賴的數學原理主要是 ECC 橢圓曲線和離散對數。詳細概念不做說明,示例介紹一下。

對稱內容加密

非對稱金鑰交換過程結束之後就得出了本次會話需要使用的對稱金鑰。對稱加密又分為兩種模式:流式加密和分組加密。流式加密現在常用的就是 RC4,不過 RC4 已經不再安全,微軟也建議網站儘量不要使用 RC4 流式加密。

一種新的替代 RC4 的流式加密演算法叫 ChaCha20,它是 google 推出的速度更快,更安全的加密演算法。目前已經被 android 和 chrome 採用,也編譯進了 google 的開源 openssl 分支—boring ssl,並且 nginx 1.7.4 也支援編譯 boringssl。

分組加密以前常用的模式是 AES-CBC,但是 CBC 已經被證明容易遭受 BEAST 和 LUCKY13 攻擊。目前建議使用的分組加密模式是 AES-GCM,不過它的缺點是計算量大,效能和電量消耗都比較高,不適用於行動電話和平板電腦。

2. 資料完整性

這部分內容比較好理解,跟平時的 md5 簽名類似,只不過安全要求要高很多。openssl 現在使用的完整性校驗演算法有兩種:MD5 或者 SHA。由於 MD5 在實際應用中存在衝突的可能性比較大,所以儘量別採用 MD5 來驗證內容一致性。SHA 也不能使用 SHA0 和 SHA1,中國山東大學的王小云教授在 2005 年就宣佈破解了 SHA-1 完整版演算法。

微軟和 Google 都已經宣佈 16 年及 17 年之後不再支援 sha1 簽名證書。

身份認證

身份認證主要涉及到 PKI 和數字證書。數字證書有兩個作用:

身份授權。確保瀏覽器訪問的網站是經過 CA 驗證的可信任的網站。
分發公鑰。每個數字證書都包含了註冊者生成的公鑰。在 SSL 握手時會通過 certificate 訊息傳輸給客戶端。
這裡簡單介紹一下數字證書是如何驗證網站身份的,PKI 體系的具體知識不做詳細介紹。

證書申請者首先會生成一對金鑰,包含公鑰和金鑰,然後把公鑰及域名還有 CU 等資料製作成 CSR 格式的請求傳送給 RA,RA 驗證完這些內容之後(RA 會請獨立的第三方機構和律師團隊確認申請者的身份)再將 CSR 傳送給 CA,CA 然後製作 X.509 格式的證書。

申請者拿到 CA 的證書並部署在網站伺服器端,那瀏覽器發起握手接收到證書後,如何確認這個證書就是 CA 簽發的呢?怎樣避免第三方偽造這個證書?

答案就是數字簽名(digital signature)。數字簽名可以認為是一個證書的防偽標籤,目前使用最廣泛的 SHA-RSA 數字簽名的製作和驗證過程如下:

1、數字簽名的簽發。首先是使用雜湊函式對證書資料雜湊,生成訊息摘要,然後使用 CA 自己的私鑰對證書內容和訊息摘要進行加密。

2、數字簽名的校驗。使用 CA 的公鑰解密簽名,然後使用相同的簽名函式對證書內容進行簽名並和服務端的數字簽名裡的簽名內容進行比較,如果相同就認為校驗成功。
這裡有幾點需要說明:

1、數字簽名簽發和校驗使用的金鑰對是 CA 自己的公私金鑰,跟證書申請者提交的公鑰沒有關係。

2、數字簽名的簽發過程跟公鑰加密的過程剛好相反,即是用私鑰加密,公鑰解密。

3、現在大的 CA 都會有證書鏈,證書鏈的好處一是安全,保持根 CA 的私鑰離線使用。第二個好處是方便部署和撤銷,即如何證書出現問題,只需要撤銷相應級別的證書,根證書依然安全。

4、根 CA 證書都是自簽名,即用自己的公鑰和私鑰完成了簽名的製作和驗證。而證書鏈上的證書籤名都是使用上一級證書的金鑰對完成簽名和驗證的。

5、怎樣獲取根 CA 和多級 CA 的金鑰對?它們是否可信?當然可信,因為這些廠商跟瀏覽器和作業系統都有合作,它們的公鑰都預設裝到了瀏覽器或者作業系統環境裡。比如 firefox 就自己維護了一個可信任的 CA 列表,而 Chrome 和 IE 使用的是作業系統的 CA 列表。

HTTPS 使用成本

HTTPS 目前唯一的問題就是它還沒有得到大規模應用,受到的關注和研究都比較少。至於使用成本和額外開銷,完全不用太過擔心。

一般來講,使用 HTTPS 前大家可能會非常關注如下問題:

1.證書費用以及更新維護。大家覺得申請證書很麻煩,證書也很貴,可是證書其實一點都不貴,便宜的一年幾十塊錢,最多也就幾百。而且現在也有了免費的證書機構,比如著名的 mozilla 發起的免費證書專案:let’s encrypt就支援免費證書安裝和自動更新。這個專案將於今年中旬投入正式使用。

數字證書的費用其實也不高,對於中小網站可以使用便宜甚至免費的數字證書服務(可能存在安全隱患),像著名的 verisign 公司的證書一般也就幾千到幾萬塊一年不等。當然如果公司對證書的需求比較大,定製性要求高,可以建立自己的 CA 站點,比如 google,能夠隨意簽發 google 相關證書。

2.HTTPS 降低使用者訪問速度。HTTPS 對速度會有一定程度的降低,但是隻要經過合理優化和部署,HTTPS 對速度的影響完全可以接受。在很多場景下,HTTPS 速度完全不遜於 HTTP,如果使用 SPDY,HTTPS 的速度甚至還要比 HTTP 快。

大家現在使用百度 HTTPS 安全搜尋,有感覺到慢嗎?

3.HTTPS 消耗 CPU 資源,需要增加大量機器。前面介紹過非對稱金鑰交換,這是消耗 CPU 計算資源的大戶,此外,對稱加解密,也需要 CPU 的計算。

同樣地,只要合理優化,HTTPS 的機器成本也不會明顯增加。對於中小網站,完全不需要增加機器也能滿足效能需求。

後記

國外的大型網際網路公司很多已經啟用了全站 HTTPS,這也是未來網際網路的趨勢。國內的大型網際網路並沒有全站部署 HTTPS,只是在一些涉及賬戶或者交易的子頁面 / 子請求上啟用了 HTTPS。百度搜尋首次全站部署 HTTPS,對國內網際網路的全站 HTTPS 程序必將有著巨大的推動作用。

目前網際網路上關於 HTTPS 的中文資料比較少,本文就著重介紹了 HTTPS 協議涉及到的重要知識點和平時不太容易理解的盲區,希望能對大家理解 HTTPS 協議有幫助。百度 HTTPS 效能優化涉及到大量內容,從前端頁面、後端架構、協議特性、加密演算法、流量排程、架構和運維、安全等方面都做了大量工作。本系列的文章將一一進行介紹。

Brilliant Open Web

BOW(Brilliant Open Web)團隊,是一個專門的Web技術建設小組,致力於推動 Open Web 技術的發展,讓Web重新成為開發者的首選。

BOW 關注前端,關注Web;剖析技術、分享實踐;談談學習,也聊聊管理。

關注 OpenWeb開發者,回覆“加群”,讓我們一起推動 OpenWeb技術的發展!