探討HTTP為什么要升級(jí) HTTPS協(xié)議

之前說(shuō)了 HTTP 協(xié)議的各種問(wèn)題，但是它還是陪伴著互聯(lián)網(wǎng)、陪伴著我們走過(guò)了將近二十年的風(fēng)風(fēng)雨雨?，F(xiàn)在有很多新的協(xié)議嘗試去取代它，來(lái)解決性能、效率等問(wèn)題，但它還還能靠著“多年的情分”活的滋潤(rùn)。然而，近些年，因?yàn)橹旅陌踩珕?wèn)題，它不得不升級(jí)成 HTTPS 了。

就拿我們叫外賣來(lái)說(shuō)，我們點(diǎn)外賣的數(shù)據(jù)包被黑客截獲，然后在服務(wù)器回復(fù)你之前給你回復(fù)一個(gè)假消息：“好啊，你該付款了，把銀行卡號(hào)、密碼拿來(lái)?！?，這時(shí)如果你真的把卡號(hào)和密碼發(fā)給他，那你的錢包就真的危險(xiǎn)了。

為了解決這些問(wèn)題，我們給 HTTP 引入了加密，變成了 HTTPS。大家千萬(wàn)不要以為 HTTPS 是個(gè)新的協(xié)議，它實(shí)際上就是：

HTTPS = HTTP + SSL 層

這里的 SSL 層的主要工作就是加密。加密方式一般分為兩種：對(duì)稱加密和非對(duì)稱加密。

這兩種加密算法，對(duì)稱加密要比非對(duì)稱加密的效率要高很多，性能也好很多，所以交互的場(chǎng)景下多用對(duì)稱加密。

對(duì)稱加密

在對(duì)稱加密算法中，加密和解密的密鑰是相同的。也就是說(shuō)，加密和解密使用的是同一個(gè)密鑰。因此，使用者一定要做好保密功能，不能讓第三方知道。

假設(shè)叫外賣的你和第三方約定了一個(gè)密鑰 A，你發(fā)送請(qǐng)求的時(shí)候用 A 進(jìn)行加密，外賣網(wǎng)站也用 A 進(jìn)行解密，這樣就算黑客截獲了你們的請(qǐng)求，但是沒(méi)有正確的密鑰，還是破解不了。

看起來(lái)很好的解決了黑客的問(wèn)題。但是這里又引入了一個(gè)問(wèn)題，你和外賣網(wǎng)站怎么來(lái)約定這個(gè)密鑰呢？如果這個(gè)密鑰在互聯(lián)網(wǎng)上傳輸，就必須還得用 B 密鑰來(lái)加密，否則被黑客獲取到 A，你們的交互還是不安全，而且，你們又怎么約定 B 呢？所以，只能通過(guò)線下傳輸。

線下傳輸?shù)脑?，看過(guò)《肖申克的救贖》的博友應(yīng)該知道，安迪越獄前給瑞德約定了一個(gè)地點(diǎn)，讓他去那里拿一個(gè)信封，里面寫著他的住處。

那我們和外賣網(wǎng)站也可以用這樣的騷操作，偷偷約定時(shí)間地點(diǎn)，它給你一個(gè)紙條，上面寫著你們兩個(gè)的密鑰，然后就用這個(gè)密鑰在互聯(lián)網(wǎng)定外賣。

打住打住，上面這個(gè)操作想想都不可思議，如果最初的互聯(lián)網(wǎng)是這樣發(fā)展的話，那相信肯定活不久。

相信你也發(fā)現(xiàn)了，只有對(duì)稱加密，就會(huì)陷入密鑰安全問(wèn)題的死循環(huán)里，這時(shí)候，就需要非對(duì)稱加密了。

非對(duì)稱加密

在非對(duì)稱加密中 ，加密和解密過(guò)程中使用兩個(gè)不相同的密鑰。一個(gè)是公開的公鑰，另一個(gè)是誰(shuí)都不給的私鑰。公鑰加密的信息，只有私鑰才能解密，而私鑰加密的信息，也只有公鑰才能解密。

放到外面上面的叫外賣過(guò)程中，非對(duì)稱加密的私鑰由外賣網(wǎng)站保存，不會(huì)再網(wǎng)上傳輸，這樣就保證了私鑰的私密性。與之對(duì)應(yīng)的公鑰是可以在互聯(lián)網(wǎng)上隨意傳播的，只要外賣網(wǎng)站把這個(gè)公鑰給你，你們就可以安全的互通了。

還是來(lái)看我們點(diǎn)外賣的過(guò)程。我們用公鑰加密，說(shuō)“我要豆?jié){加油條”。黑客在中間截獲了這個(gè)數(shù)據(jù)包，但是他沒(méi)有私鑰，沒(méi)法解密數(shù)據(jù)，因此可以順利到達(dá)外賣網(wǎng)站。而外賣網(wǎng)站用私鑰把這個(gè)報(bào)文解出來(lái)，然后回復(fù)，“我知道了，你付款吧，給我卡號(hào)和密碼”。

整個(gè)過(guò)程好像很安全，再也不怕黑客了。但是，先別太樂(lè)觀，你的銀行卡是安全了，但是外賣網(wǎng)站可還是有危險(xiǎn)的。黑客有外賣網(wǎng)站的公鑰，可以模擬發(fā)送“我要定外賣”這個(gè)信息。

為了解決這個(gè)問(wèn)題，看來(lái)一對(duì)公鑰私鑰是不夠的，客戶端也需要有自己的公鑰和私鑰，并且客戶端也要把自己的公鑰給外賣網(wǎng)站。

這樣，客戶端給外賣網(wǎng)站發(fā)送信息的時(shí)候，用外賣網(wǎng)站的公鑰加密，而外賣網(wǎng)站給客戶端發(fā)送消息的時(shí)候，使用客戶端的公鑰。這樣就算有黑客企圖模擬客戶端獲取一些信息，或者半路截獲回復(fù)信息，但是由于它沒(méi)有私鑰，這些信息它還是打不開。

說(shuō)了那么多，相信你也發(fā)現(xiàn)了，非對(duì)稱加密也會(huì)有同樣的問(wèn)題，如何將不對(duì)稱加密的公鑰給對(duì)方？這時(shí)有兩種可行方式，一種是放在一個(gè)公網(wǎng)的地址上，讓對(duì)方下載，另一種就是在建立連接的時(shí)候傳給對(duì)方。

這兩種方法也有相同的問(wèn)題。作為普通網(wǎng)民，你怎么鑒別別人給你的公鑰是對(duì)方的，而不是被黑客冒充的？要知道，每個(gè)人都是可以創(chuàng)建自己的公鑰和私鑰的，創(chuàng)建過(guò)程如下：

# bash

// 創(chuàng)建私鑰：

openssl genrsa -out httpsprivate.key 1024

// 根據(jù)私鑰獲取公鑰

openssl rsa -in httpsprivate.key -pubout -out httpspublic.pem

HTTPS 證書

可以看到，通過(guò)工具，我們可以很容易的創(chuàng)建公鑰和私鑰，那么黑客也是可以創(chuàng)建的，咱們?cè)趺粗劳赓u網(wǎng)站傳過(guò)來(lái)的公鑰是不是真的就是外賣網(wǎng)站的呢？這時(shí)候，就需要第三方機(jī)構(gòu)來(lái)當(dāng)這個(gè)中間人了。

這就像我們的戶口本一樣，每個(gè)人都可以打印出來(lái)，說(shuō)是真的戶口本，但是去使用的時(shí)候，人家就只認(rèn)有公安局蓋章的戶口本。這個(gè)由權(quán)威部門頒發(fā)的稱為**證書（Certificate）。

HTTPS 證書里面應(yīng)該有以下內(nèi)容：

公鑰：這是最重要的；

所有者：說(shuō)明證書是屬于誰(shuí)的，就像戶口本上的姓名和身份證號(hào)，來(lái)證明這個(gè)戶口本是你的；

證書發(fā)布機(jī)構(gòu)：看看你的戶口本上有沒(méi)有某某公安局的字樣？

證書有效時(shí)間：這個(gè)和咱們身份證有效期是一個(gè)意思。

說(shuō)完了證書的內(nèi)容，就到了下一步，怎么獲取證書？這就像家里添了個(gè)小公舉，去哪里上戶口呢？恐怕大家都知道去公安局。與之對(duì)應(yīng)的，HTTPS 也有專門負(fù)責(zé)派發(fā)證書的機(jī)構(gòu)，這個(gè)機(jī)構(gòu)我們稱為 CA（Certificate Authrity）。而證書則可以通過(guò)下面這個(gè)命令生成：

openssl req -key httpsprivate.key -new -out httpscertificate.req

將這個(gè)請(qǐng)求發(fā)給 CA，CA 會(huì)給這個(gè)證書“蓋”一個(gè)章，我們稱為簽名算法。這個(gè)簽名用到 CA 的私鑰進(jìn)行簽發(fā)，來(lái)保證簽名不被偽造。

簽名算法大概是這樣工作的：一般是對(duì)信息做一個(gè) Hash 計(jì)算，得到一個(gè) Hash 值，這個(gè)過(guò)程是不可逆的，也就是說(shuō)無(wú)法通過(guò) Hash 值還原回原來(lái)的信息內(nèi)容。再把信息發(fā)出時(shí)，把上面得到的 Hash 加密后，作為一個(gè)簽名和信息一起發(fā)出去。CA 給整數(shù)簽名的命令是：

openssl x509 -req -in httpscertificate.req -CA cacertificate-pem -CAkey caprivate.key

這個(gè)命令會(huì)返回 Signature ok，而 httpscertificate.pem 就是簽名過(guò)的整數(shù)。CA 用自己的私鑰給外賣網(wǎng)站的公鑰簽名，這就相當(dāng)于給外賣網(wǎng)站背書，形成了外賣網(wǎng)站的證書。我們可以通過(guò)下面這個(gè)命令查看證書內(nèi)容：

openssl x509 -in httpscertificate.pem -noout -text

證書會(huì)顯示以下內(nèi)容：

lssuer：證書頒發(fā)者；

Subject：證書頒發(fā)給誰(shuí)；

Validity：證書期限；

Public-key：公鑰內(nèi)容；

Sinature Algorithm：簽名算法

通過(guò)這種方式，我們?cè)L問(wèn)外賣網(wǎng)站時(shí)，得到的不再是一個(gè)公鑰，而是一個(gè)整數(shù)。這個(gè)證書里有發(fā)布機(jī)構(gòu) CA，你只要通過(guò)這個(gè) CA 的公鑰去解密外賣網(wǎng)站證書的簽名，解密成功，Hash 對(duì)的上，就說(shuō)明外賣網(wǎng)站的公鑰是真實(shí)可信的。

上述整個(gè)過(guò)程中，都有一個(gè)前提，CA 是可信的。但是，我們又怎么確定 CA 的公鑰就是對(duì)的呢？這就像有的人在偏遠(yuǎn)農(nóng)村搞了個(gè)假公安局一樣（應(yīng)該沒(méi)人這么干吧），我們?cè)趺粗拦簿质遣皇羌俚哪兀咳缓笪覀兙蜁?huì)想到，我去縣公安局確認(rèn)下當(dāng)?shù)毓簿值男畔⒉痪秃昧?。沒(méi)錯(cuò)，CA 也是這么干的。

CA 的公鑰也需要更牛的 CA 給它簽名，然后形成 CA 的公鑰。要想知道某個(gè) CA 的證書是否可靠，要看 CA 的上級(jí)證書的公鑰能不能解開這個(gè) CA 的簽名。這樣追根溯源，直到全球皆知的幾大著名 CA，我們稱為Root CA，做最后的背書。正是通過(guò)這種層層授信背書的形式，保證了非對(duì)稱加密模式的爭(zhēng)吵運(yùn)轉(zhuǎn)。

除此之外，還有一種證書， 稱為Self-Signed Certificate，就是自己給自己簽名。這個(gè)就給人一種“我就是我，不一樣的煙火，你愛(ài)信不信”的感覺(jué)，有興趣的博友可以自行搜索了解。

HTTPS 的工作模式

上面說(shuō)了對(duì)稱加密和非對(duì)稱加密的原理，我們知道了非對(duì)稱加密在性能上遠(yuǎn)不如對(duì)稱加密，那在 HTTP 中，能否將兩者結(jié)合起來(lái)呢？例如，公鑰私鑰主要用于傳輸對(duì)稱加密的密鑰，而真正的雙方大數(shù)據(jù)量的通信都是通過(guò)對(duì)稱加密進(jìn)行。

是的，HTTPS 協(xié)議的思路就是這樣的。如下圖：

圖比較長(zhǎng)，整個(gè)過(guò)程最后的目標(biāo)是生成在后續(xù)通信過(guò)程中使用的對(duì)稱密鑰，以及約定使用的加密算法。整體過(guò)程如下：

客戶端明文發(fā)送 TLS 版本信息、加密套件候選列表、壓縮算法候選列表等信息，另外還會(huì)發(fā)送一個(gè)隨機(jī)數(shù)，在協(xié)商對(duì)稱密鑰的時(shí)候使用（你好，我想定外賣，但你要保密我點(diǎn)了什么。這是我的加密套路列表，還有一個(gè)隨機(jī)數(shù) A，你留著）；

服務(wù)器返回 Server Hello 消息，告訴客戶端，服務(wù)器選擇使用的協(xié)議版本、加密套件、壓縮算法等，還有一個(gè)隨機(jī)數(shù) B，用于后續(xù)進(jìn)行密鑰協(xié)商（你好，保密沒(méi)問(wèn)題，就按套路 2 來(lái)吧，我也給你一個(gè)隨機(jī)數(shù) B，你留著）；

服務(wù)器給客戶端證書；

客戶端從自己信任的 CA 倉(cāng)庫(kù)中，拿 CA 的證書里面的公鑰去解密服務(wù)器傳來(lái)的證書。解密成功，說(shuō)明外賣網(wǎng)站是可信的。這個(gè)解密過(guò)程，客戶端可能胡不斷往上追溯 CA、CA 的 CA、CA 的 CA 的 CA，直到一個(gè)授信的 CA 為止；

證書驗(yàn)證可信后，客戶端會(huì)計(jì)算產(chǎn)生隨機(jī)數(shù)字 Pre-master，發(fā)送Client Key Exchange，用證書中的公鑰加密，再發(fā)給服務(wù)器；

到此時(shí)，無(wú)論是客戶端還是服務(wù)端，都有了三個(gè)隨機(jī)數(shù)，分別是：A、B、Pre-master。通過(guò)這三個(gè)隨機(jī)數(shù)，客戶端和服務(wù)端可以產(chǎn)生相同的對(duì)稱密鑰。

約定好對(duì)稱密鑰和加密算法，就可以用對(duì)稱加密的形式進(jìn)行加密通信了，后續(xù)的通信除了多了一步密鑰校驗(yàn)的過(guò)程，HTTP 協(xié)議里的那些過(guò)程都不會(huì)少。

不過(guò)上面的過(guò)程中只包含了 HTTPS 的單向認(rèn)證，也就是客戶端驗(yàn)證服務(wù)端的證書，這也是最常見的場(chǎng)景。不過(guò)在更加嚴(yán)格要求通信安全的情況下，也可以啟用雙向認(rèn)證，雙方互相驗(yàn)證證書。

通過(guò)上面的整個(gè)過(guò)程，我們可以看出，HTTPS 協(xié)議并不是一個(gè)新的協(xié)議，它只是 HTTP 協(xié)議與一些加密算法的組合，用來(lái)保證通信的安全。

雖然上面介紹的非對(duì)稱加密方式，在現(xiàn)在看來(lái)是完美不可解的，但未來(lái)誰(shuí)知道呢？正所謂“道高一尺魔高一丈”，加密安全路上永無(wú)盡頭。

小結(jié)

加密分對(duì)稱加密和非對(duì)稱加密。對(duì)稱加密效率高，但存在密鑰傳輸?shù)膯?wèn)題；非對(duì)稱加密可以解決密鑰傳輸?shù)膯?wèn)題，但效率較低。

非對(duì)稱加密需要通過(guò)證書和權(quán)威機(jī)構(gòu)來(lái)驗(yàn)證公鑰的合法性。

HTTPS 是綜合了對(duì)稱加密和非對(duì)稱加密算法的 HTTP 協(xié)議。既保證了傳輸安全，也保證了傳輸效率。
編輯：hfy