[[379186]]

前言

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

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

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

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

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

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

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

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

性能問題。通過代碼去加密解密這個(gè)過程也是比較耗時(shí)的，會(huì)影響到性能。

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

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

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

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

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

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

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

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

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

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

但是，公鑰是明文傳輸?shù)难?，那么中間人就可以利用這個(gè)公鑰偽造數(shù)據(jù)了:

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

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

電子簽名其實(shí)也是一種非對(duì)稱加密的用法。

它的使用方法是：

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

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

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

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

但是，這個(gè)用作簽名的另外的私鑰和另外的公鑰怎么來的呢?這就需要強(qiáng)大的CA來驗(yàn)證了。

強(qiáng)大的后臺(tái)機(jī)構(gòu)～(數(shù)字證書)

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

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

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

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

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

擴(kuò)展一下：

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

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

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

再來個(gè)圖總結(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ù)字簽名確保完整性、使用加密確保私密性，以實(shí)現(xiàn)客戶端和服務(wù)器之間的安全通訊。”這個(gè)過程其實(shí)就是在傳統(tǒng)的傳輸層——HTTP層，拿到數(shù)據(jù)后交給SSL層，然后進(jìn)行認(rèn)證、加密等操作。

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

今天要說的就這么多了。

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

完整的連接過程下周再說吧，來不起了哈哈。下周會(huì)出一個(gè)網(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)載自微信公眾號(hào)「碼上積木」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系碼上積木公眾號(hào)。