HTTPS，在我的概念中就是更安全，需要服務器配置證書，但是到底什麼是HTTPS，爲什麼會更安全，整套流程又是如何實現的，在腦子裏沒有具體的概念。下文將爲大家介紹HTTPS整套加密機制是如何實現的，讓更多之前不清楚HTTPS加密到底是什麼的同學有一個入門的理解。
HTTP是什麼樣的？
HTTP是屬於應用層的協議，它是基於TCP/IP的，所以它只是規定一些要傳輸的內容，以及頭部信息，然後通過TCP協議進行傳輸，依靠IP協議進行尋址，通過一幅最簡單的圖來描述：
客戶端發出請求，服務端進行響應，就是這麼簡單。在整個過程中，沒有任何加密的東西，所以它是不安全的，中間人可以進行攔截，獲取傳輸和響應的數據，造成數據泄露。
加個密呢？
因爲上圖中數據是明文傳輸的，我們能想到最簡單的提高安全性的方法就是在傳輸前對數據進行加密，如下圖：
這種加密方式叫做：對稱加密。
加密和解密用同一個祕鑰的加密方式叫做對稱加密。
好了，我們對數據進行加密了，問題解決了嗎？
多個客戶端怎麼辦？
這是一個客戶端，但是在WWW上，是成千上萬的客戶端，情況會怎樣呢？
爲所有的客戶端都應用同一個祕鑰A，這種方式很顯然是不合理的，破解了一個用戶，所有的用戶信息都會被盜取。
想一想，是不是還有別的辦法呢？
相信大家都可以想到，如果對每一個客戶端都用不同的祕鑰進行傳輸是不是就解決這個問題了：
對稱加密祕鑰如何傳輸？
我們對每個客戶端應用不同的對稱加密祕鑰，那麼這個祕鑰客戶端或者服務端是如何知道的呢，只能是在一端生成一個祕鑰，然後通過HTTP傳輸給另一端：
那麼這個傳輸祕鑰的過程，又如何保證加密？如果被中間人攔截，祕鑰也會被獲取。也許你會說，對祕鑰再進行加密，那又如何保證對祕鑰加密的過程，是加密的呢？
非對稱加密
在對稱加密的路上走不通了，我們換個思路，還有一種加密方式叫非對稱加密，比如RSA。
非對稱加密會有一對祕鑰：公鑰和私鑰。
公鑰加密的內容，只有私鑰可以解開，私鑰加密的內容，所有的公鑰都可以解開（當然是指和祕鑰是一對的公鑰）。
私鑰只保存在服務器端，公鑰可以發送給所有的客戶端。
在傳輸公鑰的過程中，肯定也會有被中間人獲取的風險，但在目前的情況下，至少可以保證客戶端通過公鑰加密的內容，中間人是無法破解的，因爲私鑰只保存在服務器端，只有私鑰可以破解公鑰加密的內容。
現在我們還存在一個問題，如果公鑰被中間人拿到篡改呢：
MITM：Man-in-the-MiddleAttack
客戶端拿到的公鑰是假的，如何解決這個問題？
第三方認證
公鑰被掉包，是因爲客戶端無法分辨傳回公鑰的到底是中間人，還是服務器，這也是密碼學中的身份驗證問題。
在HTTPS中，使用證書 + 數字簽名來解決這個問題。
這裏假設加密方式是MD5，將網站的信息加密後通過第三方機構的私鑰再次進行加密，生成數字簽名。
數字證書 = 網站信息 + 數字簽名
假如中間人攔截後把服務器的公鑰替換爲自己的公鑰，因爲數字簽名的存在，會導致客戶端驗證簽名不匹配，這樣就防止了中間人替換公鑰的問題。
瀏覽器安裝後會內置一些權威第三方認證機構的公鑰，比如Comodo、Symantec以及GlobalSign等等，驗證簽名的時候直接就從本地拿到相應第三方機構的公鑰，對私鑰加密後的數字簽名進行解密得到真正的簽名，然後客戶端利用簽名生成規則進行簽名生成，看兩個簽名是否匹配，如果匹配認證通過，不匹配則獲取證書失敗。
爲什麼要有簽名？
大家可以想一下，爲什麼要有數字簽名這個東西呢？
第三方認證機構是一個開放的平臺，我們可以去申請，中間人也可以去申請呀：
如果沒有簽名，只對網站信息進行第三方機構私鑰加密的話，會存在下面的問題：
因爲沒有認證，所以中間人也向第三方認證機構進行申請，然後攔截後把所有的信息都替換成自己的，客戶端仍然可以解密，並且無法判斷這是服務器的還是中間人的，最後造成數據泄露。
對稱加密
在安全的拿到服務器的公鑰之後，客戶端會隨機生成一個對稱祕鑰，使用服務器公鑰加密，傳輸給服務端，此後，相關的Application Data就通過這個隨機生成的對稱祕鑰進行加密/解密，服務器也通過該對稱祕鑰進行解密/加密：
整體流程圖
HTTPS = HTTP + TLS/SSL
HTTPS中具體的內容還有很多，可以通過下圖做一個參考：
總結
HTTPS就是使用SSL/TLS協議進行加密傳輸，讓客戶端拿到服務器的公鑰，然後客戶端隨機生成一個對稱加密的祕鑰，使用公鑰加密，傳輸給服務端，後續的所有信息都通過該對稱祕鑰進行加密解密，完成整個HTTPS的流程。