上過網(wǎng)的朋友都知道，網(wǎng)絡(luò)是非常不安全的。尤其是公共場所很多免費(fèi)的 WiFi，或許只是攻擊者的一個(gè)誘餌。還有大家平時(shí)喜歡用的萬能鑰匙，等等。

HTTP 存在的問題

那我們平時(shí)上網(wǎng)可能會存在哪些風(fēng)險(xiǎn)呢?

• 泄密，個(gè)人隱私、賬戶密碼等信息可能會被盜取。
• 篡改，收到的數(shù)據(jù)可能被第三方修改過，或被植入廣告等。
• 假冒，訪問的站點(diǎn)非目標(biāo)服務(wù)器站點(diǎn)。如域名欺騙、域名劫持、釣魚網(wǎng)站等。

可能住你隔壁穿人字拖、說話都略顯羞澀的小王，一到夜深人靜的時(shí)候就開始偷窺你的一舉一動!

??

為什么別人能獲取你上網(wǎng)的數(shù)據(jù)呢?有過一定網(wǎng)絡(luò)基礎(chǔ)的朋友多少都對 TCP/IP 有些了解，對各種握手揮手早已背得滾瓜爛熟，對 HTTP 協(xié)議也早了然于心。

HTTP 是應(yīng)用層的協(xié)議，位于 TCP/IP 參考模型的最上層。用戶數(shù)據(jù)經(jīng)過應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、鏈路層的層層封裝后經(jīng)過物理層發(fā)送到目標(biāo)機(jī)器。

在這幾層中，數(shù)據(jù)都沒有經(jīng)過加密處理，所以一旦別人獲取到你的數(shù)據(jù)包，就能輕易的獲取到數(shù)據(jù)的信息。

為了保護(hù)數(shù)據(jù)隱私，讓數(shù)據(jù)不再“裸奔”。對需要傳輸?shù)臄?shù)據(jù)進(jìn)行加密處理就很有必要了。

目前而言，加密算法可以分兩大類，一類是對稱加密算法，還有一類是非對稱加密算法。

對稱加密

對稱加密算法的加密和解密都是用同一個(gè)密鑰。在一定條件下，對稱加密可以解決數(shù)據(jù)傳輸安全性的問題。

比如我在登錄某個(gè)網(wǎng)站的時(shí)候，需要填寫賬戶名和密碼進(jìn)行登錄，客戶端把登錄的表單信息進(jìn)行對稱加密后再傳輸，這時(shí)候就算小王截獲數(shù)據(jù)包，他也無法獲取數(shù)據(jù)的內(nèi)容，因?yàn)閿?shù)據(jù)已經(jīng)被加密了。

但是服務(wù)器收到數(shù)據(jù)后也是一臉懵逼，你發(fā)來的加密的數(shù)據(jù)包服務(wù)器也不知道解密的密鑰!

??

那是不是客戶端與服務(wù)端在通信之前應(yīng)該先協(xié)商密鑰呢?客戶端可以通知服務(wù)器需要開啟數(shù)據(jù)傳輸了，然后服務(wù)器告訴客戶端，咱們以后用 xxxx 這個(gè)密鑰進(jìn)行加密解密吧!

??

這樣內(nèi)容是可以加密傳輸了，但是上圖中第一步協(xié)商密鑰的過程又同樣存在安全的問題!

萬一小王截獲了協(xié)商密鑰的數(shù)據(jù)，那后續(xù)加密傳輸?shù)臄?shù)據(jù)對小王來說無異于未加密!所以，對稱加密存在密鑰協(xié)商的問題!

非對稱加密

基于對稱加密存在的問題，又有了非對稱加密。非對稱加密算法需要一組密鑰對，分別是公鑰和私鑰，這兩個(gè)密鑰是成對出現(xiàn)的。

公鑰加密的內(nèi)容需要用私鑰解密，私鑰加密的內(nèi)容需要用公鑰解密!私鑰由服務(wù)器自己保存，公鑰發(fā)送給客戶端。

客戶端拿到公鑰后就可以對請求進(jìn)行加密后發(fā)送給服務(wù)端了，這時(shí)候就算被小王截獲，小王沒有私鑰也無法解密發(fā)送的內(nèi)容，這樣確保了客戶端發(fā)送到服務(wù)端數(shù)據(jù)的“安全”!

但是由于公鑰也需要通過網(wǎng)絡(luò)發(fā)送給客戶端，同樣能被小王截獲，這樣服務(wù)器私鑰加密后的內(nèi)容依然可以被小王截獲并解密，并且非對稱加密的效率很低。

對稱加密和非對稱加密都存在密鑰傳輸?shù)膯栴}，但是至少非對稱加密可以保證客戶端傳輸給服務(wù)端的內(nèi)容無法被“破解”，而對稱加密算法性能又比較好，那我們是不是可以這樣子呢。

第一次通信的時(shí)候服務(wù)端發(fā)送公鑰給客戶端，由客戶端產(chǎn)生一個(gè)對稱密鑰，通過服務(wù)端的公鑰加密后發(fā)送給服務(wù)端，后續(xù)的交互中都通過對稱密鑰進(jìn)行加密傳輸。

也就是說先通過非對稱密鑰加密對稱密鑰，通過對稱密鑰加密實(shí)際請求的內(nèi)容。

??

上面的方案看起來天衣無縫，小王拿到數(shù)據(jù)后貌似就無從下手了，但是真的就天衣無縫了嗎?

我們看看下圖：

??

也就是說小王可以偽裝成服務(wù)器，與客戶端進(jìn)行通信。類似于你與服務(wù)端之間多了一個(gè)中間商!也就是說協(xié)商密鑰的過程依然存在漏洞!

有點(diǎn)腦闊疼!還能不能讓我安全的上網(wǎng)了!就沒有更安全的機(jī)制了么? 在協(xié)商密鑰的過程中，客戶端怎么能確定對方是真正的目標(biāo)服務(wù)器呢?怎么證明服務(wù)器的身份呢?我們先了解一下數(shù)字證書!

數(shù)字證書

我們生活中有各種證，有能證明自己是個(gè)有身份的人的身份證，有能證明自己讀了幾年書的畢業(yè)證。

這些證都是由某些權(quán)威機(jī)關(guān)認(rèn)證、無法偽造的，能證明自己身份的憑據(jù)。

那服務(wù)器是不是也能有個(gè)類似身份證的東西，在與服務(wù)器進(jìn)行通信的時(shí)候證明自己確實(shí)是目標(biāo)服務(wù)器而不是小王偽造的呢?

在生活中這些證件都是實(shí)實(shí)在在能看得見摸得著的，而計(jì)算機(jī)中的證書是虛擬的，看得見但是摸不著，是數(shù)據(jù)形式記錄的，所以叫數(shù)字證書!

客戶端第一次與服務(wù)器進(jìn)行通信的時(shí)候，服務(wù)器需要出示自己的數(shù)字證書，證明自己的身份以及自己的公鑰，類似如下(實(shí)際上就是一堆數(shù)據(jù)，這里為了直觀)：

??

那這個(gè)數(shù)字證書怎么產(chǎn)生的呢?總不能是服務(wù)器自己造一個(gè)吧?上面說到了我們生活中的證書是由權(quán)威機(jī)構(gòu)頒發(fā)的、無法偽造的。

比如身份證就是由派出所發(fā)證、畢業(yè)證由教育部發(fā)證，如果需要驗(yàn)證真假，只需要上相關(guān)的系統(tǒng)輸入編號查詢就能查到了!那我們數(shù)字證書也應(yīng)該有這兩個(gè)特性，權(quán)威機(jī)構(gòu)頒發(fā)、防偽!

CA 機(jī)構(gòu)

CA 機(jī)構(gòu)就是數(shù)字證書頒發(fā)的權(quán)威機(jī)構(gòu)，負(fù)責(zé)頒發(fā)證書以及驗(yàn)證證書的合法性。

如果服務(wù)器需要做個(gè)有身份的服務(wù)器，就需要向 CA 機(jī)構(gòu)提交申請，當(dāng)然有錢才好辦事，交錢才能給你辦證……

服務(wù)器向 CA 機(jī)構(gòu)提交申請，需要提交站點(diǎn)的信息如域名、公司名稱、公鑰等等，CA 審批無誤之后就可以給服務(wù)器頒發(fā)證書了!

客戶端在拿到服務(wù)器的證書后，就需要驗(yàn)證證書編號是否能在對應(yīng)的 CA 機(jī)構(gòu)查到，并且核對證書的基本信息如證書上的域名是否與當(dāng)前訪問的域名一致等等，還可以拿到證書中服務(wù)器的公鑰信息用于協(xié)商對稱密鑰!

證書頒發(fā)了，可是又怎么防止偽造，怎么保證在傳輸過程中不被篡改呢?萬一小王截獲到數(shù)字證書，把公鑰改成自己的那不是依然無法保證安全了么?這就需要數(shù)字簽名了!

數(shù)字簽名

與公司簽過勞動合同的朋友應(yīng)該都知道，在合同信息的填寫中，是不能有涂改的，否則需要重新填寫!并且在最后需要甲方和乙方簽名并且蓋章。

一旦簽名蓋章后的合同就具有了法律的效力，合同就不能再修改。簽名和蓋章操作就是防止合同偽造，規(guī)定不能修改就防止了合同被篡改!

在實(shí)際生活中簽名、蓋章操作是實(shí)實(shí)在在的動作，作用在具體某個(gè)物體上的!

但是我們的數(shù)字證書本身就是虛擬的，怎么去給一個(gè)虛擬的證書簽名蓋章呢?數(shù)字簽名又是什么機(jī)制呢?

我們在做權(quán)限系統(tǒng)的時(shí)候，存儲用戶密碼的時(shí)候都會經(jīng)過 MD5 計(jì)算摘要后存儲，在登錄的時(shí)候計(jì)算用戶填寫的密碼的 MD5 摘要與數(shù)據(jù)庫存儲的摘要進(jìn)行對比，如果一致則密碼正確，否則登錄失敗!

MD5 是不可逆的，且不同的數(shù)據(jù)計(jì)算出來的摘要是不一樣的(當(dāng)然也有極小的概率會 Hash 碰撞)，基于這個(gè)特性，就有了數(shù)字簽名的思路。

服務(wù)器提交自己的基本信息向 CA 機(jī)構(gòu)提出申請，CA 機(jī)構(gòu)在給服務(wù)器頒發(fā)證書的時(shí)候，會連同數(shù)字證書以及根據(jù)證書計(jì)算的摘要一同發(fā)送給服務(wù)器，且這個(gè)摘要是需要經(jīng)過 CA 機(jī)構(gòu)自己的私鑰進(jìn)行加密的。

申請流程如下：

??

啥?不夠直觀?那我們再來個(gè)直觀點(diǎn)的!通過下圖我們能看到，CA 給服務(wù)器頒發(fā)的證書是有自己專屬的“公章”的。

??

哪些 CA 機(jī)構(gòu)對于客戶端來說是權(quán)威或者說是認(rèn)可的呢?我們打開 IE 瀏覽器能看到客戶端內(nèi)置的 CA 機(jī)構(gòu)的信息，包含了 CA 的公鑰、簽名算法、有效期等等...

??

服務(wù)器在與客戶端通信的時(shí)候，就會將數(shù)字證書和數(shù)字簽名出示給客戶端了。

客戶端拿到數(shù)字證書和數(shù)字簽名后，先通過操作系統(tǒng)或者瀏覽器內(nèi)置信任的 CA 機(jī)構(gòu)找到對應(yīng) CA 機(jī)構(gòu)的公鑰對數(shù)字簽名進(jìn)行解密，然后采用同樣的摘要算法計(jì)算數(shù)字證書的摘要。

如果自己計(jì)算的摘要與服務(wù)器發(fā)來的摘要一致，則證書是沒有被篡改過的!

這樣就防止了篡改!第三方拿不到 CA 機(jī)構(gòu)的私鑰，也就無法對摘要進(jìn)行加密，如果是第三方偽造的簽名自然在客戶端也就無法解密，這就防止了偽造!

所以數(shù)字簽名就是通過這種機(jī)制來保證數(shù)字證書被篡改和被偽造。具體流程如下：

??

啥?又不夠直觀?那我們繼續(xù)...

??

這里需要注意一點(diǎn)，一個(gè)是 CA 機(jī)構(gòu)的公鑰，內(nèi)置在客戶端，用來解密數(shù)字簽名!另一個(gè)是目標(biāo)服務(wù)器的公鑰，在數(shù)字證書內(nèi)容里，用來協(xié)商對稱密鑰!

HTTPS

本文的標(biāo)題是 HTTPS，但是到目前為止 HTTPS 只字未提!其實(shí) HTTPS=HTTP+SSL，在 HTTP 層和 TCP 之間加了一個(gè) SSL/TLS 層。

如下圖：

??

SSL(Secure Sockets Layer)中文叫“安全套接層”，后來由于廣泛應(yīng)用，SSL 標(biāo)準(zhǔn)化之后就改名為 TLS(Transport Layer Security)了。

HTTPS 就是通過上面說到的那些手段來解決網(wǎng)絡(luò)上可能存在的數(shù)據(jù)泄密、篡改、假冒的這些問題，保證網(wǎng)絡(luò)傳輸?shù)陌踩睦?

看到這里的你，對 HTTPS 的原理是否懂了呢，反正我奶奶看完已經(jīng)懂了!手動狗頭(*￣︶￣)

作者：蘇靜

簡介：有過多年大型互聯(lián)網(wǎng)項(xiàng)目的開發(fā)經(jīng)驗(yàn)，對高并發(fā)、分布式、以及微服務(wù)技術(shù)有深入的研究及相關(guān)實(shí)踐經(jīng)驗(yàn)。經(jīng)歷過自學(xué)，熱衷于技術(shù)研究與分享!格言：始終保持虛心學(xué)習(xí)的態(tài)度!

??