[[379186]]

前言

關(guān)于HTTPS的連接過程，也是老生常談的話題了。

其中涉及到的數(shù)字證書、電子簽名、SSL/TLS、對稱加密、非對稱加密的問題總是讓人摸不清頭腦，不知道怎么回答。

今天就和大家再熟悉熟悉這其中千絲萬縷的關(guān)系。

確實不安全!(HTTP協(xié)議傳輸)傳統(tǒng)的HTTP傳輸協(xié)議，是一種明文傳輸協(xié)議。也就是通信過程中都沒有對數(shù)據(jù)進行加密，很容易泄漏數(shù)據(jù)。

比如泄漏了重要的用戶信息、被偽造數(shù)據(jù)發(fā)送、都會造成不小的問題。

所以有的朋友就想到可以自己對數(shù)據(jù)進行加密，但是這種自己加密數(shù)據(jù)的方法也存在了很多問題，比如：

不夠安全。雖然數(shù)據(jù)加了密看似安全了，但是加密的密鑰怎么管理呢?這是個大問題，保存在客戶端?引入插件?感覺都不是什么比較好的辦法，都還是有可能被破解。

兼容問題。自己對數(shù)據(jù)加密，那么就要涉及到對加密算法的管理了，而加密算法是在不斷發(fā)展的，而這就要求客戶端和服務(wù)器端要對加密保持更新兼容，而且不能實時進行更新，需要線下更新代碼邏輯。所以這也是一個比較麻煩的問題。

性能問題。通過代碼去加密解密這個過程也是比較耗時的，會影響到性能。

所以，在原有的HTTP協(xié)議基礎(chǔ)之下就增加了一種協(xié)議——SSL/TLS協(xié)議，形成新的較安全的網(wǎng)絡(luò)協(xié)議——HTTPS。

對數(shù)據(jù)進行加密～(HTTPS傳輸數(shù)據(jù))在之前的網(wǎng)絡(luò)數(shù)據(jù)傳輸過程中我說過，對數(shù)據(jù)進行解析的一系列應(yīng)用層的工作都是交給了瀏覽器和操作系統(tǒng)的TCP協(xié)議棧。

所以HTTPS的加密解密工作自然也就是交給了瀏覽器，這樣就不存在上述的性能問題了。

具體怎么做的呢?用到了對稱加密算法：

客戶端用對稱密鑰對數(shù)據(jù)進行加密。

客戶端用對稱密鑰對數(shù)據(jù)進行解密。

有人就會問了，這不還是和剛才說到的一樣嗎?這個密鑰怎么管理呢?

這就需要在正式傳輸數(shù)據(jù)之前 想辦法 把這個對稱密鑰告訴對方了。而這個辦法就是——非對稱加密。

怎么告訴對方這個對稱密鑰?(非對稱加密)大家都知道非對稱加密是分私鑰和公鑰，也就是你通過公鑰加密數(shù)據(jù)，然后我用私鑰來解密。私鑰只有自己有，所以只有自己能解開這個數(shù)據(jù)，即使中間人拿到數(shù)據(jù)，也破解不了。

放到實際客戶端服務(wù)器通信中，就是服務(wù)器端將公鑰發(fā)給客戶端，然后客戶端那這個公鑰對 對稱密鑰進行加密，并發(fā)給客戶端，只有客戶端有私鑰可以解這個含有對稱加密的密文。用張圖表示：

但是，公鑰是明文傳輸?shù)难剑敲粗虚g人就可以利用這個公鑰偽造數(shù)據(jù)了:

所以怎么解決呢?就需要這個消息證明他是來自真正的服務(wù)器端，拿到真正的公鑰，而不是偽造的，這就需要電子簽名了。

我要證明我是我!(電子簽名)

電子簽名其實也是一種非對稱加密的用法。

它的使用方法是：

A使用私鑰對數(shù)據(jù)的哈希值進行加密，這個加密后的密文就叫做簽名，然后將這個密文和數(shù)據(jù)本身傳輸給B。

B拿到后，簽名用公鑰解密出來，然后和傳過來數(shù)據(jù)的哈希值做比較，如果一樣，就說明這個簽名確實是A簽的，而且只有A才可以簽，因為只有A有私鑰。

反應(yīng)實際情況就是：

服務(wù)器端將數(shù)據(jù)，也就是我們要傳的數(shù)據(jù)(公鑰)，用另外的私鑰簽名數(shù)據(jù)的哈希值，然后和數(shù)據(jù)(公鑰)一起傳過去。然后客戶端用另外的公鑰對簽名解密，如果解密數(shù)據(jù)和數(shù)據(jù)(公鑰)的哈希值一致，就能證明來源正確，不是被偽造的。

但是，這個用作簽名的另外的私鑰和另外的公鑰怎么來的呢?這就需要強大的CA來驗證了。

強大的后臺機構(gòu)～(數(shù)字證書)

證書頒發(fā)機構(gòu)(CA, Certificate Authority)即頒發(fā)數(shù)字證書的機構(gòu)。是負(fù)責(zé)發(fā)放和管理數(shù)字證書的權(quán)威機構(gòu)，并作為電子商務(wù)交易中受信任的第三方，承擔(dān)公鑰體系中公鑰的合法性檢驗的責(zé)任。”實際情況中，服務(wù)器會拿自己的公鑰以及服務(wù)器的一些信息傳給CA，然后CA會返回給服務(wù)器一個數(shù)字證書，這個證書里面包括：

• 服務(wù)器的公鑰
• 簽名算法
• 服務(wù)器的信息，包括主機名等。
• CA自己的私鑰對這個證書的簽名

然后服務(wù)器將這個證書在連接階段傳給客戶端，客戶端怎么驗證呢?

細(xì)心的小伙伴肯定知道，每個客戶端，不管是電腦、手機都有自帶的系統(tǒng)根證書，其中就會包括服務(wù)器數(shù)字證書的簽發(fā)機構(gòu)。所以系統(tǒng)的根證書會用他們的私鑰幫我們對數(shù)字證書的簽名進行解密，然后和證書里面的數(shù)據(jù)哈希值進行對比，如果一樣，則代表來源是正確的,數(shù)據(jù)是沒有被修改的。

當(dāng)然中間人也是可以通過CA申請證書的，但是證書中會有服務(wù)器的主機名，這個主機名(域名、IP)就可以驗證你的來源是來源自哪個主機。

擴展一下：

其實在服務(wù)器證書和根證書中間還有一層結(jié)構(gòu)：叫中級證書，我們可以任意點開一個網(wǎng)頁，點擊左上角的🔒按鈕就可以看到證書詳情：

可以看到一般完整的SSL/TLS證書有三層結(jié)構(gòu)：

• 第一層：根證書。也就是客戶端自帶的那些。
• 第二層：中級證書。一般根證書是不會直接頒發(fā)服務(wù)器證書的，因為這種行為比較危險，如果發(fā)現(xiàn)錯誤頒發(fā)就很麻煩，需要涉及到跟證書的修改。所以一般會引用中間證書，根證書對中間證書進行簽名，然后中間證書再對服務(wù)器證書進行簽名，一層套一層。
• 第三層：服務(wù)器證書。也就是跟我們服務(wù)器相關(guān)的這個證書了。

再來個圖總結(jié)下：

兢兢業(yè)業(yè)的好伙伴❤️(SSL/TLS)以上說的所有的工作都是HTTPS里面的S幫我們做的，也就是SSL/TLS協(xié)議。

SSL：(Secure Socket Layer，安全套接字層)，位于可靠的面向連接的網(wǎng)絡(luò)層協(xié)議和應(yīng)用層協(xié)議之間的一種協(xié)議層。SSL通過互相認(rèn)證、使用數(shù)字簽名確保完整性、使用加密確保私密性，以實現(xiàn)客戶端和服務(wù)器之間的安全通訊。”這個過程其實就是在傳統(tǒng)的傳輸層——HTTP層，拿到數(shù)據(jù)后交給SSL層，然后進行認(rèn)證、加密等操作。

而TLS是SSL的升級版，主要目標(biāo)是使SSL更安全，并使協(xié)議的規(guī)范更精確和完善。

今天要說的就這么多了。

其實只說了HTTPS連接過程中的一個步驟，即數(shù)字證書的發(fā)送。

完整的連接過程下周再說吧，來不起了哈哈。下周會出一個網(wǎng)絡(luò)問題全解的文章，期待一下～

參考https://wetest.qq.com/lab/view/110.html http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html https://www.zhihu.com/question/52790301

本文轉(zhuǎn)載自微信公眾號「碼上積木」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系碼上積木公眾號。