https工做原理

https工做原理

平時咱們常常說https安全，一旦提及http被劫持數據傳輸不安全問題，就直接上https。

可是https的工做原理是什麼? 它爲何安全? 不用https行不行?

帶着上面的疑問，咱們下面具體解答一下。

不用https行不行?

咱們知道http傳遞都是明文傳遞，直接傳輸確定是不行的，數據所有都暴露了。

那要不咱們加密一下?

1. 對稱加密

對數據進行對稱加密。

好比瀏覽器請求一個域名 ( http://www.xxx.com/api/post/ ),請求數據經過了"某個密鑰"進行了對稱加密，服務端接收到請求，再使用"這個密鑰"解密。

通常狀況下，這種方式確實能保證一些安全。可是對於"攻擊大佬"來講，沒用!

想一下，咱們上面說的"某個密鑰"是從哪兒來的?

確定是從服務端傳過來，那這個傳遞"密鑰"過程，攻擊大佬直接取到你的密鑰就完事了。

因此說，在"大佬"面前，對稱加密和明文傳遞沒啥區別。

out!!!

2. 非對稱加密

既然對稱加密不行，那咱們用非對稱加密怎麼樣?

瀏覽器再次請求上面的域名(http://www.xxx.com/api/post/),請求數據經過了"公鑰"進行了加密，服務端接收到請求，使用"私鑰"解密。

那這個"公鑰"怎麼來的?

仍是從服務端傳過來，不過這"公鑰"沒啥用，原本就是讓全世界知道的。(非對稱加密公鑰加密，私鑰解密)就算攻擊大佬取到了你公鑰加密後的數據，沒"私鑰"解密也沒啥用。

咦，那是否是咱們使用非對稱加密就行了，用啥的https。

訪問了半天發現： 訪問這麼慢，(非對稱加密速度很慢)這不行啊，平時我1s就能訪問到網站，如今得5s

非對稱加密的缺點：

1. 速度緩慢
複製代碼

還有一個問題:

瀏覽器能肯定給你發消息是咱們正確的服務器?

下面就是中間攻擊方作的一個攻擊處理

仍是不行啊，沒法解決中間方攻擊和加密緩慢的問題。

https是如何工做的?

上面有兩個問題:中間方攻擊和加密緩慢

中間方攻擊說白了就是咱們不能信任服務器發送的公鑰。

加密緩慢說白了就是咱們不能一直使用非對稱加密加密。

這其實也就是https要解決的問題

如何解決不信任公鑰問題?

這裏就須要引入一個概念：數字證書

數字證書 = 網站信息 + 數字簽名

網站信息我還能稍微理解一點,可能指的是網站域名啊這些信息。

數字簽名是個啥呢?

仍是先說一下網站信息吧，這個容易理解。

其實網站信息主要包含網站域名 網站公鑰(也就是上面咱們說的那個被中間方獲取的那個)，hash計算方式

好比咱們網站信息是:

域名:www.xxx.com
公鑰:xxxx
hash計算方式: md5(內部可能用的不是md5，僅做參考)

下面咱們說數字簽名：

數字簽名 = (網站域名+公鑰+其餘信息)進行hash計算，得到一個消息摘要，而後使用第三方認證機構私鑰加密生成。

這樣就能夠了嗎?

舉例:

咱們訪問域名(https://www.xxx.com),服務器首先會把數字證書發送咱們，若是此時中間方將這個證書修改了怎麼辦? (證書包含了數字簽名和網站信息，包含公鑰)

好像繞到了死循環，這個服務器返回的公鑰永遠不可靠。

那怎麼辦呢?

到了這裏就得靠咱們瀏覽器了，通常而言，咱們瀏覽器保存了大部分權威CA機構的公鑰。

這裏它們的驗證方案是這樣的：

咱們知道數字簽名是經過CA的私鑰加密的，那咱們用瀏覽器的知道的這個CA的公鑰解密，獲取到一個消息摘要。

而後咱們使用 hash計算方式(網站域名+公鑰+其餘信息)得到一個消息摘要。

若是這兩個消息摘要相同，則說明證書有效，公鑰也能夠安全獲取。

這裏咱們終於解決了公鑰安全問題。

如何解決非對稱加密加密緩慢問題

其實https並非每次都使用非對稱加密加密的。

那它是如何工做的?

https獲取到服務端的公鑰，此時瀏覽器生成隨機對稱密鑰，並使用服務端公鑰加密，服務端經過私鑰解密,發送一個完成的消息，客戶端驗證成功後，說明ssl通訊通道已經建好。

而後數據就能夠經過上面提到了隨機對稱密鑰對稱加密數據進行通訊。

其實這也就是https的工做原理，非對稱加密負責搭建ssl通道創建，對稱加密負責數據傳輸，這也就解決了都用非對稱加密緩慢的問題。

總結:

https工做原理:

1. 瀏覽器發送https請求
2. 服務端返回數字證書
3. 瀏覽器hash加密數字證書裏的網站信息，瀏覽器使用CA公鑰解密數字簽名，比較這二者是否相同，若是相同，請求成功，不然，證書失效。
4. 瀏覽器隨機生成對稱密鑰,使用服務端的公鑰加密
5. 服務器私鑰解密，發送消息
6. 客戶端驗證是否創建成功，成功，則說明ssl通道創建，不然通道創建失敗。
7. 使用上面瀏覽器生成的對稱密鑰對稱加密進行數據傳輸。