大型網(wǎng)站的HTTPS實(shí)踐（一）——HTTPS協(xié)議和原理-創(chuàng)新互聯(lián)

前言

十余年的臨河網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。網(wǎng)絡(luò)營(yíng)銷推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整臨河建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)建站從事“臨河網(wǎng)站設(shè)計(jì)”,“臨河網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

百度于2015年上線了全站HTTPS的安全搜索，默認(rèn)會(huì)將HTTP請(qǐng)求跳轉(zhuǎn)成HTTPS。從今天開始，我們將會(huì)分享多篇系列文章，為大家重點(diǎn)介紹和解析百度的HTTPS最佳實(shí)踐。

HTTPS協(xié)議概述

HTTPS可以認(rèn)為是HTTP+TLS。

HTTP協(xié)議大家耳熟能詳了，目前大部分WEB應(yīng)用和網(wǎng)站都是使用HTTP協(xié)議傳輸?shù)摹?/p>

TLS是傳輸層加密協(xié)議，它的前身是SSL協(xié)議，最早由Netscape公司于1995年發(fā)布，1999年經(jīng)過IETF討論和規(guī)范后，改名為TLS。如果沒有特別說明，SSL和TLS說的都是同一個(gè)協(xié)議。

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

圖1  TLS協(xié)議格式

TLS協(xié)議主要有五部分：應(yīng)用數(shù)據(jù)層協(xié)議，握手協(xié)議，報(bào)警協(xié)議，加密消息確認(rèn)協(xié)議，心跳協(xié)議。

TLS協(xié)議本身又是由Record協(xié)議傳輸?shù)?，Record協(xié)議的格式如上圖最右所示。

目前常用的HTTP協(xié)議是HTTP1.1，常用的TLS協(xié)議版本有如下幾個(gè)：TLS1.3，TLS1.2,TLS1.1,TLS1.0和SSL3.0。其中SSL3.0由于POODLE攻擊已經(jīng)被證明不安全，但統(tǒng)計(jì)發(fā)現(xiàn)依然有不到1%的瀏覽器使用SSL3.0。TLS1.0也存在部分安全漏洞，比如RC4和BEAST攻擊。過去由于主流Web瀏覽器和應(yīng)用程序中的TLS實(shí)現(xiàn)都支持降級(jí)協(xié)商過程，導(dǎo)致即使服務(wù)器支持最新版本，攻擊者也有機(jī)會(huì)利用較弱的協(xié)議實(shí)施攻擊。因此到2020年，所有主流Web瀏覽器都將取消TLS1.0和TLS1.1的支持。

TLS1.2暫時(shí)沒有已知的安全漏洞，比較安全，同時(shí)有大量擴(kuò)展提升速度和性能，當(dāng)前被較為普遍的使用。

需要關(guān)注一點(diǎn)的就是TLS1.3是TLS協(xié)議一個(gè)非常重大的改革。不管是安全性還是用戶訪問速度都會(huì)有質(zhì)的提升。TLS1.3協(xié)議的最終版本（RFC8446）已于2018年8月10日發(fā)布，各主流瀏覽器也逐漸支持TLS1.3。

同時(shí)HTTP2也于2015年5月正式定稿（RFC7540），這個(gè)由SPDY協(xié)議演化而來的協(xié)議相比HTTP1.1又是一個(gè)非常重大的變動(dòng)，能夠明顯提升應(yīng)用層數(shù)據(jù)的傳輸效率。

HTTPS功能介紹

百度使用HTTPS協(xié)議主要是為了保護(hù)用戶隱私，防止流量劫持。

HTTP本身是明文傳輸的，沒有經(jīng)過任何安全處理。例如用戶在百度搜索了一個(gè)關(guān)鍵字，比如“蘋果手機(jī)”，中間者完全能夠查看到這個(gè)信息，并且有可能打電話過來騷擾用戶。也有一些用戶投訴使用百度時(shí)，發(fā)現(xiàn)首頁或者結(jié)果頁面浮了一個(gè)很長(zhǎng)很大的廣告，這也肯定是中間者往頁面插的廣告內(nèi)容。如果劫持技術(shù)比較低劣的話，用戶甚至無法訪問百度。

這里提到的中間者主要指一些網(wǎng)絡(luò)節(jié)點(diǎn)，是用戶數(shù)據(jù)在瀏覽器和百度服務(wù)器中間傳輸必須要經(jīng)過的節(jié)點(diǎn)。比如WIFI熱點(diǎn)，路由器，防火墻，反向代理，緩存服務(wù)器等。

在HTTP協(xié)議下，中間者可以隨意嗅探用戶搜索內(nèi)容，竊取隱私甚至篡改網(wǎng)頁。不過HTTPS是這些劫持行為的克星，能夠完全有效地防御。

總體來說，HTTPS協(xié)議提供了三個(gè)強(qiáng)大的功能來對(duì)抗上述的劫持行為：

1. 內(nèi)容加密。瀏覽器到百度服務(wù)器的內(nèi)容都是以加密形式傳輸，中間者無法直接查看原始內(nèi)容；

2. 身份認(rèn)證。保證用戶訪問的是百度服務(wù)，即使被DNS劫持到了第三方站點(diǎn)，也會(huì)提醒用戶沒有訪問百度服務(wù)，有可能被劫持；

3. 數(shù)據(jù)完整性。防止內(nèi)容被第三方冒充或者篡改。

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

HTTPS原理介紹

1內(nèi)容加密

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

圖2  對(duì)稱加密

圖3  非對(duì)稱加密

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

非對(duì)稱加密主要用于密鑰交換（也叫密鑰協(xié)商），能夠很好地解決這個(gè)問題。瀏覽器和服務(wù)器每次新建會(huì)話時(shí)都使用非對(duì)稱密鑰交換算法協(xié)商出對(duì)稱密鑰，使用這些對(duì)稱密鑰完成應(yīng)用數(shù)據(jù)的加解密和驗(yàn)證，整個(gè)會(huì)話過程中的密鑰只在內(nèi)存中生成和保存，而且每個(gè)會(huì)話的對(duì)稱密鑰都不相同（除非會(huì)話復(fù)用），中間者無法竊取。

非對(duì)稱密鑰交換很安全，但同時(shí)也是HTTPS性能和速度嚴(yán)重降低的“罪魁禍?zhǔn)住?。想要知道HTTPS為什么影響速度，為什么消耗資源，就一定要理解非對(duì)稱密鑰交換的整個(gè)過程。

下面重點(diǎn)介紹一下非對(duì)稱密鑰交換的數(shù)學(xué)原理及在TLS握手過程中的應(yīng)用。

2非對(duì)稱秘鑰交換

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

密鑰交換算法本身非常復(fù)雜，密鑰交換過程涉及到隨機(jī)數(shù)生成，模指數(shù)運(yùn)算，空白補(bǔ)齊，加密，簽名等操作。

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

1. RSA：算法實(shí)現(xiàn)簡(jiǎn)單，誕生于1977年，歷史悠久，經(jīng)過了長(zhǎng)時(shí)間的破解測(cè)試，安全性高。缺點(diǎn)就是需要比較大的素?cái)?shù)（目前常用的是2048位）來保證安全強(qiáng)度，很消耗CPU運(yùn)算資源。RSA是目前唯一一個(gè)既能用于密鑰交換又能用于證書簽名的算法。

2. DH：Diffie-Hellman密鑰交換算法，誕生時(shí)間比較早（1977年），但是1999年才公開。缺點(diǎn)是比較消耗CPU性能。

3. ECDHE：使用橢圓曲線（ECC）的DH算法，優(yōu)點(diǎn)是能用較小的素?cái)?shù)（256位）實(shí)現(xiàn)RSA相同的安全等級(jí)。缺點(diǎn)是算法實(shí)現(xiàn)復(fù)雜，用于密鑰交換的歷史不長(zhǎng)，沒有經(jīng)過長(zhǎng)時(shí)間的安全攻擊測(cè)試。

4. ECDH：不支持PFS，安全性低，同時(shí)無法實(shí)現(xiàn)False Start。

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

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

1. ECDHE支持ECC加速，計(jì)算速度更快。支持PFS，更加安全。支持False Start，用戶訪問速度更快。

2. 目前還有至少20%以上的客戶端不支持ECDHE，我們推薦使用RSA而不是DH或者DHE，因?yàn)镈H系列算法非常消耗CPU（相當(dāng)于要做兩次RSA計(jì)算）。

圖4  百度HTTPS連接詳情

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

非對(duì)稱加密相比對(duì)稱加密更加安全，但也存在兩個(gè)明顯缺點(diǎn)：

1. CPU計(jì)算資源消耗非常大。一次完全TLS握手，密鑰交換時(shí)的非對(duì)稱解密計(jì)算量占整個(gè)握手過程的90%以上。而對(duì)稱加密的計(jì)算量只相當(dāng)于非對(duì)稱加密的0.1%，如果應(yīng)用層數(shù)據(jù)也使用非對(duì)稱加解密，性能開銷太大，無法承受。

2. 非對(duì)稱加密算法對(duì)加密內(nèi)容的長(zhǎng)度有限制，不能超過公鑰長(zhǎng)度。比如現(xiàn)在常用的公鑰長(zhǎng)度是2048位，意味著待加密內(nèi)容不能超過256個(gè)字節(jié)。

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

非對(duì)稱密鑰交換算法是整個(gè)HTTPS得以安全的基石，充分理解非對(duì)稱密鑰交換算法是理解HTTPS協(xié)議和功能的關(guān)鍵。

總  結(jié)

在接下來的文章中我們會(huì)繼續(xù)通俗地介紹一下RSA和ECDHE在密鑰交換過程中的應(yīng)用，敬請(qǐng)期待。

文章整理自百度HTTPS技術(shù)聯(lián)合團(tuán)隊(duì)

標(biāo)題名稱：大型網(wǎng)站的HTTPS實(shí)踐（一）——HTTPS協(xié)議和原理-創(chuàng)新互聯(lián)
分享路徑：http://muchs.cn/article46/dsjphg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、網(wǎng)站設(shè)計(jì)公司、服務(wù)器托管、ChatGPT、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)