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

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

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

HTTPS = HTTP + SSL 層

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

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

對稱加密

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

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

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

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

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

打住打住，上面這個操作想想都不可思議，如果最初的互聯網是這樣發展的話，那相信肯定活不久。

相信你也發現了，只有對稱加密，就會陷入密鑰安全問題的死循環里，這時候，就需要非對稱加密了。

非對稱加密

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

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

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

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

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

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

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

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

# bash

// 創建私鑰：

openssl genrsa -out httpsprivate.key 1024

// 根據私鑰獲取公鑰

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

HTTPS 證書

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

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

HTTPS 證書里面應該有以下內容：

公鑰：這是最重要的；

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

證書發布機構：看看你的戶口本上有沒有某某公安局的字樣？

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

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

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

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

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

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

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

openssl x509 -in httpscertificate.pem -noout -text

證書會顯示以下內容：

lssuer：證書頒發者；

Subject：證書頒發給誰；

Validity：證書期限；

Public-key：公鑰內容；

Sinature Algorithm：簽名算法

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

上述整個過程中，都有一個前提，CA 是可信的。但是，我們又怎么確定 CA 的公鑰就是對的呢？這就像有的人在偏遠農村搞了個假公安局一樣（應該沒人這么干吧），我們怎么知道公安局是不是假的呢？然后我們就會想到，我去縣公安局確認下當地公安局的信息不就好了。沒錯，CA 也是這么干的。

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

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

HTTPS 的工作模式

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

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

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

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

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

服務器給客戶端證書；

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

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

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

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

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

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

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

小結

加密分對稱加密和非對稱加密。對稱加密效率高，但存在密鑰傳輸的問題；非對稱加密可以解決密鑰傳輸的問題，但效率較低。

非對稱加密需要通過證書和權威機構來驗證公鑰的合法性。

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