HTTPS 協(xié)議到底比 HTTP 協(xié)議多些什么？

來源：公眾號(hào)【杰哥的IT之旅】
作者：阿拉斯加
ID：Jake_Internet

大家好，我是杰哥。最近卷了一篇 HTTP 協(xié)議的相關(guān)知識(shí)，大綱如下：

HTTP 簡介

HTTP 協(xié)議是 Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫，是用于從萬維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。

HTTP 是一個(gè)基于 TCP/IP 通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件，圖片文件，查詢結(jié)果等）。

HTTP 是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。它于 1990 年提出，經(jīng)過幾年的使用與發(fā)展，得到不斷地完善和擴(kuò)展。目前在 WWW 中使用的是 HTTP/1.0 的第六版，HTTP/1.1 的規(guī)范化工作正在進(jìn)行之中，而且 HTTP-NG(Next Generation of HTTP) 的建議已經(jīng)提出。

HTTP 協(xié)議工作于客戶端-服務(wù)端架構(gòu)為上，瀏覽器作為 HTTP 客戶端通過 URL 向 HTTP 服務(wù)端即 WEB 服務(wù)器發(fā)送所有請(qǐng)求，Web 服務(wù)器根據(jù)接收到的請(qǐng)求后，向客戶端發(fā)送響應(yīng)信息。

HTTP 特點(diǎn)：

• 簡單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有 GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于 HTTP 協(xié)議簡單，使得 HTTP 服務(wù)器的程序規(guī)模小，因而通信速度很快；

• 靈活：HTTP 允許傳輸任意類型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念愋陀?Content-Type 加以標(biāo)記；

• 無連接：無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間；

• 無狀態(tài)：HTTP 協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快；

• 支持 B/S 及 C/S 模式；

HTTP 有以上這么多的優(yōu)點(diǎn)，那么問題來了，HTTP 協(xié)議有什么弊端嗎? 答案是肯定的，原因也很簡單，如果HTTP 是完美的，還需要一個(gè)叫做 HTTPS 協(xié)議的安全協(xié)議干什么呢?

HTTP 弊端：

當(dāng)我們往服務(wù)器發(fā)送比較隱私的數(shù)據(jù)（比如說你的銀行卡，身份證）時(shí)，如果使用 http 進(jìn)行通信。那么安全性將得不到保障；

首先數(shù)據(jù)在傳輸?shù)倪^程中，數(shù)據(jù)可能被中間人抓包拿到，那么數(shù)據(jù)就會(huì)被中間人竊??；

其次數(shù)據(jù)被中間人拿到后，中間人可能對(duì)數(shù)據(jù)進(jìn)行修改或者替換，然后發(fā)往服務(wù)器；

最后服務(wù)器收到數(shù)據(jù)后，也無法確定數(shù)據(jù)有沒有被修改或替換，當(dāng)然，如果服務(wù)器也無法判斷數(shù)據(jù)就真的是來源于客戶端；

總結(jié)下來，HTTP 存在三個(gè)弊端：

• 無法保證消息的保密性；

• 無法保證消息的完整性和準(zhǔn)確性；

• 無法保證消息來源的可靠性；

HTTPS 簡介

如何解決 HTTP 弊端呢？HTTPS 就是為了解決上述問題應(yīng)運(yùn)而生的。

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的 HTTP 通道，簡單講是 HTTP 的安全版。

即 HTTP 下加入 SSL 層，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細(xì)內(nèi)容就需要 SSL。現(xiàn)在它被廣泛用于萬維網(wǎng)上安全敏感的通訊，例如交易支付方面。

HTTPS 通過非對(duì)稱加密算法可以使得我們傳的明文信息，無法通過逆推得出明文。接下來我們來看看在具體的工作流程是怎么樣的？

工作原理：

HTTPS 的建立過程

這里把 HTTPS 建立到斷開分為 6 個(gè)階段，12 過程。下面將對(duì) 12 個(gè)過程一一做解釋:

1、客戶端 — Hello：客戶端通過發(fā)送 Client Hello 報(bào)文開始 SSL 通信。報(bào)文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密匙長度等）；

2、服務(wù)器 — Hello：服務(wù)器可進(jìn)行 SSL 通信時(shí)，會(huì)以 Server Hello 報(bào)文作為應(yīng)答。和客戶端一樣，在報(bào)文中包含 SSL 版本以及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的；

3、服務(wù)器 — 發(fā)證書：服務(wù)器發(fā)送證書報(bào)文。報(bào)文中包含公開密匙證書；

4、服務(wù)器 — 我說完了：最后服務(wù)器發(fā)送 Server Hello Done 報(bào)文通知客戶端，最初階段的 SSL 握手協(xié)商部分結(jié)束；

5、客戶端 — 發(fā)送秘鑰：SSL 第一次握手結(jié)束之后，客戶端以 Client Key Exchange 報(bào)文作為回應(yīng)。報(bào)文包含通信加密中使用的一種被稱為 Pre-master secret 的隨機(jī)密碼串。該報(bào)文已用步驟 3 中的公開密匙進(jìn)行加密；

6、客戶端 — 就用這個(gè)秘鑰了：該報(bào)文會(huì)提示服務(wù)器，在此報(bào)文之后的通信會(huì)采用 Pre-master secret 密匙加密；

7、客戶端 — 我說完了：該報(bào)文包含連接至今全部報(bào)文的整體校驗(yàn)值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密該報(bào)文作為判定標(biāo)準(zhǔn)；

8、服務(wù)器 — 發(fā)送 c Change Cipher Spec 報(bào)文（我正在接收秘鑰）；

9、服務(wù)器 — 發(fā)送 d Finished 報(bào)文（我收完秘鑰了）；

10、客戶端 — 開始發(fā)送正文：服務(wù)器端發(fā)送 HTTP 請(qǐng)求，發(fā)送相關(guān)內(nèi)容；

11、服務(wù)器 — 開始接收正文：客戶端接收 HTTP 請(qǐng)求，并處理相關(guān)內(nèi)容；

12、客戶端 — 斷開鏈接：最后由客戶端斷開連接。斷開連接時(shí)，發(fā)送 close_notify 報(bào)文。上圖做了一些省略，這步之后再發(fā)送 TCP FIN 報(bào)文來關(guān)閉與 TCP 的通信；

另外，在以上流程圖中，應(yīng)用層發(fā)送數(shù)據(jù)時(shí)會(huì)附加一種叫做 MAC（MessageAuthentication Code）的報(bào)文摘要。MAC 能夠查知報(bào)文是否遭到篡改，從而保證報(bào)文的完整性；

下面再用圖解來形象的說明一下，此圖比上面數(shù)字證書的圖更加的詳細(xì)一些（圖片來源于《圖解 HTTP》）

在上面說明了 HTTPS 的建立以及通信中的過程。既然實(shí)際工作流程是這個(gè)樣子的，是怎樣的算法能實(shí)現(xiàn)這樣的功能，是怎樣的方式能做到非對(duì)稱加密？在數(shù)學(xué)角度是如何計(jì)算的？那么對(duì)應(yīng)的理論基礎(chǔ)是什么？是什么支撐的 HTTPS 使得他能進(jìn)行加密傳輸？

HTTPS 的理論原理：

HTTPS 采用了一些加解密，數(shù)字證書，數(shù)字簽名的技術(shù)來實(shí)現(xiàn)。下面先介紹一下這些技術(shù)的基本概念。

為了保證消息的保密性，就需要用到加密和解密。加解密算法目前主流的分為對(duì)稱加密和非對(duì)稱加密。

對(duì)稱加密（共享密匙加密）

客戶端和服務(wù)器公用一個(gè)密匙用來對(duì)消息加解密，這種方式稱為對(duì)稱加密?？蛻舳撕头?wù)器約定好一個(gè)加密的密匙?？蛻舳嗽诎l(fā)消息前用該密匙對(duì)消息加密，發(fā)送給服務(wù)器后，服務(wù)器再用該密匙進(jìn)行解密拿到消息。

圖示加密過程：

這里采用的對(duì)稱加密算法：

• M：明文，我們本意要傳輸?shù)膬?nèi)容；

• C：秘鑰，在對(duì)稱加密算法中需要用秘鑰加密，用秘鑰解密（加密算法可以很簡單，加減乘除，也可以很復(fù)雜）；

• N：密文，明文用秘鑰加密得到的內(nèi)容，被稱為密文，在網(wǎng)絡(luò)上傳輸?shù)囊彩敲芪模?/p>

比如客戶端向服務(wù)器傳輸 1（明文），1 + 3 （3 是秘鑰） = 4 得到密文，進(jìn)行傳輸，服務(wù)器得到 密文 4， 4-3（3 是秘鑰）=1 得到明文，使得客戶端和服務(wù)器端進(jìn)行通信，反之亦然；

對(duì)稱加密的優(yōu)點(diǎn)：

• 對(duì)稱加密解決了 HTTP 中消息保密性的問題；

對(duì)稱加密的缺點(diǎn)：

• 對(duì)稱加密雖然保證了消息保密性，但是因?yàn)榭蛻舳撕头?wù)器共享一個(gè)密匙，這樣就使得密匙特別容易泄露；

• 因?yàn)槊艹仔孤讹L(fēng)險(xiǎn)較高，所以很難保證消息來源的可靠性、消息的完整性和準(zhǔn)確性；

對(duì)稱加密秘鑰泄露風(fēng)險(xiǎn)很高，秘鑰固定，導(dǎo)致很容易被破解，那么有沒有更好的方式去進(jìn)行加密傳輸，比如說每次用的秘鑰都不相同，每次解密的秘鑰也都不相同，或者其他的情況來增加安全性呢？

非對(duì)稱加密（公有密匙加密）

既然對(duì)稱加密中，密匙那么容易泄露，那么我們可以采用一種非對(duì)稱加密的方式來解決。采用非對(duì)稱加密時(shí)，客戶端和服務(wù)端均擁有一個(gè)公有密匙和一個(gè)私有密匙。公有密匙可以對(duì)外暴露，而私有密匙只有自己可見。

使用公有密匙加密的消息，只有對(duì)應(yīng)的私有密匙才能解開。反過來，使用私有密匙加密的消息，只有公有密匙才能解開。這樣客戶端在發(fā)送消息前，先用服務(wù)器的公匙對(duì)消息進(jìn)行加密，服務(wù)器收到后再用自己的私匙進(jìn)行解密。

圖示加密過程：

解釋如下：

• M：指的是明文，我們本意要傳輸?shù)膬?nèi)容；

• D：指的是公鑰，在非對(duì)稱加密算法中需要用公鑰加密；

• E：指的是私鑰，在非對(duì)稱加密算法中需要用私鑰解密；

• N：指的是密文，明文用秘鑰加密得到的內(nèi)容，被稱為密文，在網(wǎng)絡(luò)上傳輸?shù)囊彩敲芪模?/p>

在服務(wù)器這一次生成公鑰 D 以及私鑰 E，私鑰自己留存。然后將公鑰 D 進(jìn)行對(duì)外公開，想與服務(wù)器端通信的客戶端用公鑰 D 進(jìn)行加密發(fā)送給具有私鑰 E 的服務(wù)器，服務(wù)器用私鑰 E 就可以進(jìn)行密文解密，最終拿到明文。

非對(duì)稱加密算法RSA簡介

RSA 是目前最有影響力的公鑰加密算法，它能夠抵抗到目前為止已知的絕大多數(shù)密碼攻擊，已被 ISO 推薦為公鑰數(shù)據(jù)加密標(biāo)準(zhǔn)。

今天只有短的 RSA 鑰匙才可能被強(qiáng)力方式解破。到 2008 年為止，世界上還沒有任何可靠的攻擊 RSA 算法的方式。只要其鑰匙的長度足夠長，用 RSA 加密的信息實(shí)際上是不能被解破的。但在分布式計(jì)算和量子計(jì)算機(jī)理論日趨成熟的今天，RSA 加密安全性受到了挑戰(zhàn)。

RSA 算法基于一個(gè)十分簡單的數(shù)論事實(shí) ：將兩個(gè)大質(zhì)數(shù)相乘十分容易，但是想要對(duì)其乘積進(jìn)行因式分解卻極其困難，因此可以將乘積公開作為加密密鑰。

HTTPS 加密、證書、簽名與握手

經(jīng)得住拷問的 HTTPS 原理解析

最深刻最通俗的 HTTPS 原理詳解，圖文并茂

為什么 https 比 http 更安全？

HTTPS 的安全性從何而來？

一文徹底搞懂 HTTPS 的工作原理！

你一定要知道，關(guān)于 https 的五大誤區(qū)