摘要：加密方式一般分為兩種對稱加密和非對稱加密。非對稱加密在非對稱加密中，加密和解密過程中使用兩個不相同的密鑰。這個由權(quán)威部門頒發(fā)的稱為證書。正是通過這種層層授信背書的形式，保證了非對稱加密模式的爭吵運轉(zhuǎn)。是的，協(xié)議的思路就是這樣的。

系列文章傳送門：

網(wǎng)絡(luò)協(xié)議 1 - 概述

網(wǎng)絡(luò)協(xié)議 2 - IP 是怎么來，又是怎么沒的？

網(wǎng)絡(luò)協(xié)議 3 - 從物理層到 MAC 層

網(wǎng)絡(luò)協(xié)議 4 - 交換機與 VLAN：辦公室太復(fù)雜，我要回學(xué)校

網(wǎng)絡(luò)協(xié)議 5 - ICMP 與 ping：投石問路的偵察兵

網(wǎng)絡(luò)協(xié)議 6 - 路由協(xié)議：敢問路在何方？

網(wǎng)絡(luò)協(xié)議 7 - UDP 協(xié)議：性善碰到城會玩

網(wǎng)絡(luò)協(xié)議 8 - TCP 協(xié)議（上）：性惡就要套路深

網(wǎng)絡(luò)協(xié)議 9 - TCP協(xié)議（下）：聰明反被聰明誤

網(wǎng)絡(luò)協(xié)議 10 - Socket 編程（上）：實踐是檢驗真理的唯一標(biāo)準(zhǔn)

網(wǎng)絡(luò)協(xié)議 11 - Socket 編程（下）：眼見為實耳聽為虛

網(wǎng)絡(luò)協(xié)議 12 - HTTP 協(xié)議：常用而不簡單

????之前說了 HTTP 協(xié)議的各種問題，但是它還是陪伴著互聯(lián)網(wǎng)、陪伴著我們走過了將近二十年的風(fēng)風(fēng)雨雨?，F(xiàn)在有很多新的協(xié)議嘗試去取代它，來解決性能、效率等問題，但它還還能靠著“多年的情分”活的滋潤。然而，近些年，因為致命的安全問題，它不得不升級成 HTTPS 了。

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

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

HTTPS = HTTP + SSL 層

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

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

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

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

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

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

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

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

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

????在非對稱加密中 ，加密和解密過程中使用兩個不相同的密鑰。一個是公開的公鑰，另一個是誰都不給的私鑰。公鑰加密的信息，只有私鑰才能解密，而私鑰加密的信息，也只有公鑰才能解密。

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

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

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

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

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

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

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

# bash
// 創(chuàng)建私鑰：
openssl genrsa -out httpsprivate.key 1024

// 根據(jù)私鑰獲取公鑰
openssl rsa -in httpsprivate.key -pubout -out httpspublic.pem

????可以看到，通過工具，我們可以很容易的創(chuàng)建公鑰和私鑰，那么黑客也是可以創(chuàng)建的，咱們怎么知道外賣網(wǎng)站傳過來的公鑰是不是真的就是外賣網(wǎng)站的呢？這時候，就需要第三方機構(gòu)來當(dāng)這個中間人了。

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

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

公鑰：這是最重要的；

所有者：說明證書是屬于誰的，就像戶口本上的姓名和身份證號，來證明這個戶口本是你的；

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

證書有效時間：這個和咱們身份證有效期是一個意思。

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

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

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

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

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

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

openssl x509 -in httpscertificate.pem -noout -text

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

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

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

Validity：證書期限；

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

Sinature Algorithm：簽名算法

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

????上述整個過程中，都有一個前提，CA 是可信的。但是，我們又怎么確定 CA 的公鑰就是對的呢？這就像有的人在偏遠(yuǎn)農(nóng)村搞了個假公安局一樣（應(yīng)該沒人這么干吧），我們怎么知道公安局是不是假的呢？然后我們就會想到，我去縣公安局確認(rèn)下當(dāng)?shù)毓簿值男畔⒉痪秃昧?。沒錯，CA 也是這么干的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

加密分對稱加密和非對稱加密。對稱加密效率高，但存在密鑰傳輸?shù)膯栴}；非對稱加密可以解決密鑰傳輸?shù)膯栴}，但效率較低。

非對稱加密需要通過證書和權(quán)威機構(gòu)來驗證公鑰的合法性。

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

參考：

百度百科 - htps 詞條；

劉超 - 趣談網(wǎng)絡(luò)協(xié)議系列課；