建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
HTTPS(超文本傳輸安全協(xié)議)，是以安全為目標(biāo)的 HTTP 通道，簡(jiǎn)單講是 HTTP 的安全版。本文，就來(lái)深入介紹下其原理。
為什么需要 HTTPS
使用 HTPPS 的原因其實(shí)很簡(jiǎn)單，就是因?yàn)?HTTP 的不安全。
當(dāng)我們往服務(wù)器發(fā)送比較隱私的數(shù)據(jù)時(shí)，如果使用 HTTP 進(jìn)行通信。那么安全性將得不到保障。
首先數(shù)據(jù)在傳輸?shù)倪^(guò)程中，數(shù)據(jù)可能被中間人抓包拿到，那么數(shù)據(jù)就會(huì)被中間人竊取。
其次數(shù)據(jù)被中間人拿到后，中間人可能對(duì)數(shù)據(jù)進(jìn)行修改或者替換，然后發(fā)往服務(wù)器。
服務(wù)器收到數(shù)據(jù)后，也無(wú)法確定數(shù)據(jù)有沒(méi)有被修改或替換，當(dāng)然，如果服務(wù)器也無(wú)法判斷數(shù)據(jù)就真的是來(lái)源于客戶(hù)端。
總結(jié)下來(lái)，HTTP 存在三個(gè)弊端：
- 無(wú)法保證消息的保密性
- 無(wú)法保證消息的完整性和準(zhǔn)確性
- 無(wú)法保證消息來(lái)源的可靠性
HTTPS 就是為了解決上述問(wèn)題應(yīng)運(yùn)而生的。
HTTPS 基本概念
為了解決 HTTP 中存在的問(wèn)題，HTTPS 采用了一些加解密，數(shù)字證書(shū)，數(shù)字簽名的技術(shù)來(lái)實(shí)現(xiàn)。下面先介紹一下這些技術(shù)的基本概念。
對(duì)稱(chēng)加密與非對(duì)稱(chēng)加密
為了保證消息的保密性，就需要用到加密和解密。加解密算法目前主流的分為對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密。
①對(duì)稱(chēng)加密(共享密匙加密)：客戶(hù)端和服務(wù)器公用一個(gè)密匙用來(lái)對(duì)消息加解密，這種方式稱(chēng)為對(duì)稱(chēng)加密。
客戶(hù)端和服務(wù)器約定好一個(gè)加密的密匙?？蛻?hù)端在發(fā)消息前用該密匙對(duì)消息加密，發(fā)送給服務(wù)器后，服務(wù)器再用該密匙進(jìn)行解密拿到消息。
對(duì)稱(chēng)加密的優(yōu)點(diǎn)：對(duì)稱(chēng)加密解決了 HTTP 中消息保密性的問(wèn)題。
對(duì)稱(chēng)加密的缺點(diǎn)：對(duì)稱(chēng)加密雖然保證了消息保密性，但是因?yàn)榭蛻?hù)端和服務(wù)器共享一個(gè)密匙，這樣就使得密匙特別容易泄露。因?yàn)槊艹仔孤讹L(fēng)險(xiǎn)較高，所以很難保證消息來(lái)源的可靠性、消息的完整性和準(zhǔn)確性。
②非對(duì)稱(chēng)加密(公有密匙加密)：既然對(duì)稱(chēng)加密中，密匙那么容易泄露，那么我們可以采用一種非對(duì)稱(chēng)加密的方式來(lái)解決。
采用非對(duì)稱(chēng)加密時(shí)，客戶(hù)端和服務(wù)端均擁有一個(gè)公有密匙和一個(gè)私有密匙。公有密匙可以對(duì)外暴露，而私有密匙只有自己可見(jiàn)。
使用公有密匙加密的消息，只有對(duì)應(yīng)的私有密匙才能解開(kāi)。反過(guò)來(lái)，使用私有密匙加密的消息，只有公有密匙才能解開(kāi)。
這樣客戶(hù)端在發(fā)送消息前，先用服務(wù)器的公匙對(duì)消息進(jìn)行加密，服務(wù)器收到后再用自己的私匙進(jìn)行解密。
非對(duì)稱(chēng)加密的優(yōu)點(diǎn)：
- 非對(duì)稱(chēng)加密采用公有密匙和私有密匙的方式，解決了 HTTP 中消息保密性問(wèn)題，而且使得私有密匙泄露的風(fēng)險(xiǎn)降低。
- 因?yàn)楣准用艿南⒅挥袑?duì)應(yīng)的私匙才能解開(kāi)，所以較大程度上保證了消息的來(lái)源性以及消息的準(zhǔn)確性和完整性。
非對(duì)稱(chēng)加密的缺點(diǎn)：
- 非對(duì)稱(chēng)加密時(shí)需要使用到接收方的公匙對(duì)消息進(jìn)行加密，但是公匙不是保密的，任何人都可以拿到，中間人也可以。
那么中間人可以做兩件事，一是中間人可以在客戶(hù)端與服務(wù)器交換公匙的時(shí)候，將客戶(hù)端的公匙替換成自己的。
這樣服務(wù)器拿到的公匙將不是客戶(hù)端的，而是服務(wù)器的。服務(wù)器也無(wú)法判斷公匙來(lái)源的正確性。
第二件是中間人可以不替換公匙，但是他可以截獲客戶(hù)端發(fā)來(lái)的消息，然后篡改，然后用服務(wù)器的公匙加密再發(fā)往服務(wù)器，服務(wù)器將收到錯(cuò)誤的消息。
- 非對(duì)稱(chēng)加密的性能相對(duì)對(duì)稱(chēng)加密來(lái)說(shuō)會(huì)慢上幾倍甚至幾百倍，比較消耗系統(tǒng)資源。正是因?yàn)槿绱耍琀TTPS 將兩種加密結(jié)合了起來(lái)。
數(shù)字證書(shū)與數(shù)字簽名
為了解決非對(duì)稱(chēng)加密中公匙來(lái)源的不安全性。我們可以使用數(shù)字證書(shū)和數(shù)字簽名來(lái)解決。
①數(shù)字證書(shū)的申請(qǐng)
在現(xiàn)實(shí)中，有一些專(zhuān)門(mén)的權(quán)威機(jī)構(gòu)用來(lái)頒發(fā)數(shù)字證書(shū)，我們稱(chēng)這些機(jī)構(gòu)為認(rèn)證中心(CA，Certificate Authority)。
我們(服務(wù)器)可以向這些 CA 來(lái)申請(qǐng)數(shù)字證書(shū)。申請(qǐng)的過(guò)程大致是：自己本地先生成一對(duì)密匙，然后拿著自己的公匙以及其他信息(比如說(shuō)企業(yè)名稱(chēng)啊什么的)去 CA 申請(qǐng)數(shù)字證書(shū)。
CA 在拿到這些信息后，會(huì)選擇一種單向 Hash 算法(比如說(shuō)常見(jiàn)的 MD5)對(duì)這些信息進(jìn)行加密，加密之后的東西我們稱(chēng)之為摘要。
單向 Hash 算法有一種特點(diǎn)就是單向不可逆的，只要原始內(nèi)容有一點(diǎn)變化，加密后的數(shù)據(jù)都將會(huì)是千差萬(wàn)別(當(dāng)然也有很小的可能性會(huì)重復(fù)，有興趣的小伙伴了解一下鴿巢原理)，這樣就防止了信息被篡改。
生成摘要后還不算完，CA 還會(huì)用自己的私匙對(duì)摘要進(jìn)行加密，摘要加密后的數(shù)據(jù)我們稱(chēng)之為數(shù)字簽名。
CA 將會(huì)把我們的申請(qǐng)信息(包含服務(wù)器的公匙)和數(shù)字簽名整合在一起，由此而生成數(shù)字證書(shū)。然后 CA 將數(shù)字證書(shū)傳遞給我們。
②數(shù)字證書(shū)怎么起作用
服務(wù)器在獲取到數(shù)字證書(shū)后，服務(wù)器會(huì)將數(shù)字證書(shū)發(fā)送給客戶(hù)端，客戶(hù)端就需要用 CA 的公匙解密數(shù)字證書(shū)并驗(yàn)證數(shù)字證書(shū)的合法性。
那我們?nèi)绾文苣玫?CA 的公匙呢?我們的電腦和瀏覽器中已經(jīng)內(nèi)置了一部分權(quán)威機(jī)構(gòu)的根證書(shū)，這些根證書(shū)中包含了 CA 的公匙。
之所以是根證書(shū)，是因?yàn)楝F(xiàn)實(shí)生活中，認(rèn)證中心是分層級(jí)的，也就是說(shuō)有認(rèn)證中心，也有下面的各個(gè)子級(jí)的認(rèn)證中心，是一個(gè)樹(shù)狀結(jié)構(gòu)，計(jì)算機(jī)中內(nèi)置的是機(jī)構(gòu)的根證書(shū)，不過(guò)不用擔(dān)心，根證書(shū)的公匙在子級(jí)也是適用的。
客戶(hù)端用 CA 的公匙解密數(shù)字證書(shū)，如果解密成功則說(shuō)明證書(shū)來(lái)源于合法的認(rèn)證機(jī)構(gòu)。解密成功后，客戶(hù)端就拿到了摘要。
此時(shí)，客戶(hù)端會(huì)按照和 CA 一樣的 Hash 算法將申請(qǐng)信息生成一份摘要，并和解密出來(lái)的那份做對(duì)比，如果相同則說(shuō)明內(nèi)容完整，沒(méi)有被篡改。
客戶(hù)端安全的從證書(shū)中拿到服務(wù)器的公匙就可以和服務(wù)器進(jìn)行安全的非對(duì)稱(chēng)加密通信了。服務(wù)器想獲得客戶(hù)端的公匙也可以通過(guò)相同方式。
下圖用圖解的方式說(shuō)明一般的證書(shū)申請(qǐng)及其使用過(guò)程：
HTTPS 原理
通過(guò)上面的學(xué)習(xí)，我們了解了對(duì)稱(chēng)加密與非對(duì)稱(chēng)加密的特點(diǎn)和優(yōu)缺點(diǎn)，以及數(shù)字證書(shū)的作用。
HTTPS 沒(méi)有采用單一的技術(shù)去實(shí)現(xiàn)，而是根據(jù)他們的特點(diǎn)，充分的將這些技術(shù)整合進(jìn)去，以達(dá)到性能與安全較大化。
這套整合的技術(shù)我們稱(chēng)之為 SSL(安全套接層)。所以 HTTPS 并非是一項(xiàng)新的協(xié)議，它只是在 HTTP 上披了一層加密的外殼。
HTTPS 的建立，先看一下流程圖：
這里把 HTTPS 建立到斷開(kāi)分為 6 個(gè)階段，12 個(gè)過(guò)程。下面將對(duì) 12 個(gè)過(guò)程一 一做解釋?zhuān)?/p>
- 客戶(hù)端通過(guò)發(fā)送 Client Hello 報(bào)文開(kāi)始 SSL 通信。報(bào)文中包含客戶(hù)端支持的 SSL 的指定版本、加密組件(Cipher Suite)列表(所使用的加密算法及密匙長(zhǎng)度等)。
- 服務(wù)器可進(jìn)行 SSL 通信時(shí)，會(huì)以 Server Hello 報(bào)文作為應(yīng)答。和客戶(hù)端一樣，在報(bào)文中包含 SSL 版本以及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶(hù)端加密組件內(nèi)篩選出來(lái)的。
- 服務(wù)器發(fā)送證書(shū)報(bào)文。報(bào)文中包含公開(kāi)密匙證書(shū)。
- 服務(wù)器發(fā)送 Server Hello Done 報(bào)文通知客戶(hù)端，最初階段的 SSL 握手協(xié)商部分結(jié)束。
- SSL 握手結(jié)束之后，客戶(hù)端以 Client Key Exchange 報(bào)文作為回應(yīng)。報(bào)文包含通信加密中使用的一種被稱(chēng)為 Pre-master secret 的隨機(jī)密碼串。該報(bào)文已用步驟 3 中的公開(kāi)密匙進(jìn)行加密。
- 接著客戶(hù)端繼續(xù)發(fā)送 Change Cipher Spec 報(bào)文。該報(bào)文會(huì)提示服務(wù)器，在此報(bào)文之后的通信會(huì)采用 Pre-master secret 密匙加密。
- 客戶(hù)端發(fā)送 Finished 報(bào)文。該報(bào)文包含連接至今全部報(bào)文的整體校驗(yàn)值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密該報(bào)文作為判定標(biāo)準(zhǔn)。
- 服務(wù)器同樣發(fā)送 Change Cipher Spec 報(bào)文。
- 服務(wù)器同樣發(fā)送 Finished 報(bào)文。
- 服務(wù)器和客戶(hù)端的 Finished 報(bào)文交換完畢之后，SSL 連接就算建立完成。當(dāng)然，通信會(huì)受到 SSL 的保護(hù)。從此處開(kāi)始進(jìn)行應(yīng)用層協(xié)議的通信，即發(fā)送 HTTP 請(qǐng)求。
- 應(yīng)用層協(xié)議通信，即發(fā)送 HTTP 響應(yīng)。
- 由客戶(hù)端斷開(kāi)連接。斷開(kāi)連接時(shí)，發(fā)送 close_notify 報(bào)文。上圖做了一些省略，這步之后再發(fā)送 TCP FIN 報(bào)文來(lái)關(guān)閉與 TCP 的通信。
另外，在以上流程圖中，應(yīng)用層發(fā)送數(shù)據(jù)時(shí)會(huì)附加一種叫做 MAC(Message Authentication Code)的報(bào)文摘要。MAC 能夠查知報(bào)文是否遭到篡改，從而保證報(bào)文的完整性。
下面再用圖解來(lái)形象的說(shuō)明一下，此圖比上面數(shù)字證書(shū)的圖更加的詳細(xì)一些(圖片來(lái)源于《圖解 HTTP》)：
經(jīng)過(guò)上面的介紹，我們可以看出 HTTPS 先是利用數(shù)字證書(shū)保證服務(wù)器端的公匙可以安全無(wú)誤的到達(dá)客戶(hù)端。
然后再用非對(duì)稱(chēng)加密安全的傳遞共享密匙，用共享密匙安全的交換數(shù)據(jù)。
HTTPS 的使用
HTTPS 那么的安全，是不是我們?cè)谑裁磮?chǎng)景下都要去使用 HTTPS 進(jìn)行通信呢?答案是否定的。
①HTTPS 雖然提供了消息安全傳輸?shù)耐ǖ溃敲看蜗⒌募咏饷苁趾臅r(shí)，消耗系統(tǒng)資源。
所以，除非在一些對(duì)安全性比較高的場(chǎng)景下，比如銀行系統(tǒng)，購(gòu)物系統(tǒng)中我們必須要使用HTTPS 進(jìn)行通信，其他一些對(duì)安全性要求不高的場(chǎng)景，我們其實(shí)沒(méi)必要使用 HTTPS。
②使用 HTTPS 需要使用到數(shù)字證書(shū)，但是一般權(quán)威機(jī)構(gòu)頒發(fā)的數(shù)字證書(shū)都是收費(fèi)的，而且價(jià)格也是不菲的。
所以對(duì)于一些個(gè)人網(wǎng)站來(lái)講，如果對(duì)安全性要求不高，也沒(méi)必要使用 HTTPS。
名稱(chēng)欄目：是時(shí)候理解下HTTPS及背后的加密原理了
文章源于：http://www.5511xx.com/article/ccdppoo.html
