[[379186]]

前言

關于HTTPS的連接過程，也是老生常談的話題了。

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

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

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

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

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

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

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

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

所以，在原有的HTTP協議基礎之下就增加了一種協議——SSL/TLS協議，形成新的較安全的網絡協議——HTTPS。

對數據進行加密～(HTTPS傳輸數據)在之前的網絡數據傳輸過程中我說過，對數據進行解析的一系列應用層的工作都是交給了瀏覽器和操作系統的TCP協議棧。

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

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

客戶端用對稱密鑰對數據進行加密。

客戶端用對稱密鑰對數據進行解密。

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

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

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

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

但是，公鑰是明文傳輸的呀，那么中間人就可以利用這個公鑰偽造數據了:

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

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

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

它的使用方法是：

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

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

反應實際情況就是：

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

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

強大的后臺機構～(數字證書)

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

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

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

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

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

擴展一下：

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

可以看到一般完整的SSL/TLS證書有三層結構：

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

再來個圖總結下：

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

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

而TLS是SSL的升級版，主要目標是使SSL更安全，并使協議的規范更精確和完善。

今天要說的就這么多了。

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

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

參考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

本文轉載自微信公眾號「碼上積木」，可以通過以下二維碼關注。轉載本文請聯系碼上積木公眾號。