看圖學HTTPS

時間 2019-11-06

標籤看圖 https 简体版

原文原文鏈接

前言

以前說到HTTPS，在個人概念中就是更安全，須要服務器配置證書，可是到底什麼是HTTPS，爲何會更安全，整套流程又是如何實現的，在腦子裏沒有具體的概念。因此，我花了幾天的時間，經過參考一些文章，學習了HTTPS整套機制的實現，想要經過一篇文章把我學習到的東西總結出來，讓更多以前不清楚HTTPS究竟是什麼的同窗有一個入門的理解。html

我看過的不少文章都是經過大量的文字和協議圖來解釋，但每每會讓人感受有點枯燥，這篇文章我會經過一幅幅流程圖，形象的說明從HTTP到HTTPS的演變過程，讓你們能夠更容易理解一些。固然，這個只是入門級，若是想要學習更深刻的HTTPS的知識，仍是要深刻到一個個協議裏面，看一些大部頭，才能夠達到徹底理解的效果。瀏覽器

本文也會同步到個人我的網站。安全

正文

HTTP是什麼樣的？

HTTP是屬於應用層的協議，它是基於TCP/IP的，因此它只是規定一些要傳輸的內容，以及頭部信息，而後經過TCP協議進行傳輸，依靠IP協議進行尋址，經過一幅最簡單的圖來描述：服務器

客戶端發出請求，服務端進行響應，就是這麼簡單。在整個過程當中，沒有任何加密的東西，因此它是不安全的，中間人能夠進行攔截，獲取傳輸和響應的數據，形成數據泄露。微信

加個密呢？

由於上圖中數據是明文傳輸的，咱們能想到最簡單的提升安全性的方法就是在傳輸前對數據進行加密，以下圖：學習

這種加密方式叫作：對稱加密。
加密和解密用同一個祕鑰的加密方式叫作對稱加密。網站

好了，咱們對數據進行加密了，問題解決了嗎？加密

多個客戶端怎麼辦？

這是一個客戶端，可是在WWW上，是成千上萬的客戶端，狀況會怎樣呢？spa

爲全部的客戶端都應用同一個祕鑰A，這種方式很顯然是不合理的，破解了一個用戶，全部的用戶信息都會被盜取。3d

想想，是否是還有別的辦法呢？

相信你們均可以想到，若是對每個客戶端都用不一樣的祕鑰進行傳輸是否是就解決這個問題了：

對稱加密祕鑰如何傳輸？

咱們對每一個客戶端應用不一樣的對稱加密祕鑰，那麼這個祕鑰客戶端或者服務端是如何知道的呢，只能是在一端生成一個祕鑰，而後經過HTTP傳輸給另外一端：

那麼這個傳輸祕鑰的過程，又如何保證加密？若是被中間人攔截，祕鑰也會被獲取。也許你會說，對祕鑰再進行加密，那又如何保證對祕鑰加密的過程，是加密的呢？

好像咱們走入了 while(1)，出不來了。

非對稱加密

在對稱加密的路上走不通了，咱們換個思路，還有一種加密方式叫非對稱加密，好比RSA。
非對稱加密會有一對祕鑰：公鑰和私鑰。
公鑰加密的內容，只有私鑰能夠解開，私鑰加密的內容，全部的公鑰均可以解開（固然是指和祕鑰是一對的公鑰）。

私鑰只保存在服務器端，公鑰能夠發送給全部的客戶端。

在傳輸公鑰的過程當中，確定也會有被中間人獲取的風險，但在目前的狀況下，至少能夠保證客戶端經過公鑰加密的內容，中間人是沒法破解的，由於私鑰只保存在服務器端，只有私鑰能夠破解公鑰加密的內容。

如今咱們還存在一個問題，若是公鑰被中間人拿到篡改呢：

MITM：Man-in-the-MiddleAttack

客戶端拿到的公鑰是假的，如何解決這個問題？

第三方認證

公鑰被掉包，是由於客戶端沒法分辨傳回公鑰的究竟是中間人，仍是服務器，這也是密碼學中的身份驗證問題。

在HTTPS中，使用 證書 + 數字簽名 來解決這個問題。

這裏假設加密方式是MD5，將網站的信息加密後經過第三方機構的私鑰再次進行加密，生成數字簽名。

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

假如中間人攔截後把服務器的公鑰替換爲本身的公鑰，由於數字簽名的存在，會致使客戶端驗證簽名不匹配，這樣就防止了中間人替換公鑰的問題。

瀏覽器安裝後會內置一些權威第三方認證機構的公鑰，好比VeriSign、Symantec以及GlobalSign等等，驗證簽名的時候直接就從本地拿到相應第三方機構的公鑰，對私鑰加密後的數字簽名進行解密獲得真正的簽名，而後客戶端利用簽名生成規則進行簽名生成，看兩個簽名是否匹配，若是匹配認證經過，不匹配則獲取證書失敗。