前言
之前說到HTTPS，在我的概念中就是更安全，需要服務(wù)器配置證書，但是到底什么是HTTPS，為什么會(huì)更安全，整套流程又是如何實(shí)現(xiàn)的，在腦子里沒有具體的概念。所以，我花了幾天的時(shí)間，通過參考一些文章，學(xué)習(xí)了HTTPS整套機(jī)制的實(shí)現(xiàn)，想要通過一篇文章把我學(xué)習(xí)到的東西總結(jié)出來，讓更多之前不清楚HTTPS到底是什么的同學(xué)有一個(gè)入門的理解。
我看過的很多文章都是通過大量的文字和協(xié)議圖來解釋，但往往會(huì)讓人感覺有點(diǎn)枯燥，這篇文章我會(huì)通過一幅幅流程圖，形象的說明從HTTP到HTTPS的演變過程，讓大家可以更容易理解一些。當(dāng)然，這個(gè)只是入門級(jí)，如果想要學(xué)習(xí)更深入的HTTPS的知識(shí)，還是要深入到一個(gè)個(gè)協(xié)議里面，看一些大部頭，才可以達(dá)到完全理解的效果。
正文
HTTP是什么樣的？
HTTP是屬于應(yīng)用層的協(xié)議，它是基于TCP/IP的，所以它只是規(guī)定一些要傳輸?shù)膬?nèi)容，以及頭部信息，然后通過TCP協(xié)議進(jìn)行傳輸，依靠IP協(xié)議進(jìn)行尋址，通過一幅最簡(jiǎn)單的圖來描述：
客戶端發(fā)出請(qǐng)求，服務(wù)端進(jìn)行響應(yīng)，就是這么簡(jiǎn)單。在整個(gè)過程中，沒有任何加密的東西，所以它是不安全的，中間人可以進(jìn)行攔截，獲取傳輸和響應(yīng)的數(shù)據(jù)，造成數(shù)據(jù)泄露。
加個(gè)密呢？
因?yàn)樯蠄D中數(shù)據(jù)是明文傳輸?shù)?，我們能想到最?jiǎn)單的提高安全性的方法就是在傳輸前對(duì)數(shù)據(jù)進(jìn)行加密，如下圖：
這種加密方式叫做：對(duì)稱加密。 加密和解密用同一個(gè)秘鑰的加密方式叫做對(duì)稱加密。
好了，我們對(duì)數(shù)據(jù)進(jìn)行加密了，問題解決了嗎？
多個(gè)客戶端怎么辦？
這是一個(gè)客戶端，但是在WWW上，是成千上萬(wàn)的客戶端，情況會(huì)怎樣呢？
為所有的客戶端都應(yīng)用同一個(gè)秘鑰A，這種方式很顯然是不合理的，破解了一個(gè)用戶，所有的用戶信息都會(huì)被盜取。
想一想，是不是還有別的辦法呢？
相信大家都可以想到，如果對(duì)每一個(gè)客戶端都用不同的秘鑰進(jìn)行傳輸是不是就解決這個(gè)問題了：
對(duì)稱加密秘鑰如何傳輸？
我們對(duì)每個(gè)客戶端應(yīng)用不同的對(duì)稱加密秘鑰，那么這個(gè)秘鑰客戶端或者服務(wù)端是如何知道的呢，只能是在一端生成一個(gè)秘鑰，然后通過HTTP傳輸給另一端：
那么這個(gè)傳輸秘鑰的過程，又如何保證加密？如果被中間人攔截，秘鑰也會(huì)被獲取。也許你會(huì)說，對(duì)秘鑰再進(jìn)行加密，那又如何保證對(duì)秘鑰加密的過程，是加密的呢？
好像我們走入了 while(1)，出不來了。
非對(duì)稱加密
在對(duì)稱加密的路上走不通了，我們換個(gè)思路，還有一種加密方式叫非對(duì)稱加密，比如RSA。
非對(duì)稱加密會(huì)有一對(duì)秘鑰：公鑰和私鑰。
公鑰加密的內(nèi)容，只有私鑰可以解開，私鑰加密的內(nèi)容，所有的公鑰都可以解開（當(dāng)然是指和秘鑰是一對(duì)的公鑰）。
私鑰只保存在服務(wù)器端，公鑰可以發(fā)送給所有的客戶端。
在傳輸公鑰的過程中，肯定也會(huì)有被中間人獲取的風(fēng)險(xiǎn)，但在目前的情況下，至少可以保證客戶端通過公鑰加密的內(nèi)容，中間人是無(wú)法破解的，因?yàn)樗借€只保存在服務(wù)器端，只有私鑰可以破解公鑰加密的內(nèi)容。
現(xiàn)在我們還存在一個(gè)問題，如果公鑰被中間人拿到篡改呢：
MITM：Man-in-the-MiddleAttack
客戶端拿到的公鑰是假的，如何解決這個(gè)問題？
第三方認(rèn)證
公鑰被掉包，是因?yàn)榭蛻舳藷o(wú)法分辨?zhèn)骰毓€的到底是中間人，還是服務(wù)器，這也是密碼學(xué)中的身份驗(yàn)證問題。
在HTTPS中，使用 證書 + 數(shù)字簽名 來解決這個(gè)問題。
這里假設(shè)加密方式是MD5，將網(wǎng)站的信息加密后通過第三方機(jī)構(gòu)的私鑰再次進(jìn)行加密，生成數(shù)字簽名。
數(shù)字證書 = 網(wǎng)站信息 + 數(shù)字簽名
假如中間人攔截后把服務(wù)器的公鑰替換為自己的公鑰，因?yàn)閿?shù)字簽名的存在，會(huì)導(dǎo)致客戶端驗(yàn)證簽名不匹配，這樣就防止了中間人替換公鑰的問題。
瀏覽器安裝后會(huì)內(nèi)置一些權(quán)威第三方認(rèn)證機(jī)構(gòu)的公鑰，比如VeriSign、Symantec以及GlobalSign等等，驗(yàn)證簽名的時(shí)候直接就從本地拿到相應(yīng)第三方機(jī)構(gòu)的公鑰，對(duì)私鑰加密后的數(shù)字簽名進(jìn)行解密得到真正的簽名，然后客戶端利用簽名生成規(guī)則進(jìn)行簽名生成，看兩個(gè)簽名是否匹配，如果匹配認(rèn)證通過，不匹配則獲取證書失敗。
為什么要有簽名？
大家可以想一下，為什么要有數(shù)字簽名這個(gè)東西呢？
第三方認(rèn)證機(jī)構(gòu)是一個(gè)開放的平臺(tái)，我們可以去申請(qǐng)，中間人也可以去申請(qǐng)呀：
如果沒有簽名，只對(duì)網(wǎng)站信息進(jìn)行第三方機(jī)構(gòu)私鑰加密的話，會(huì)存在下面的問題：
因?yàn)闆]有認(rèn)證，所以中間人也向第三方認(rèn)證機(jī)構(gòu)進(jìn)行申請(qǐng)，然后攔截后把所有的信息都替換成自己的，客戶端仍然可以解密，并且無(wú)法判斷這是服務(wù)器的還是中間人的，最后造成數(shù)據(jù)泄露。
對(duì)稱加密
在安全的拿到服務(wù)器的公鑰之后，客戶端會(huì)隨機(jī)生成一個(gè)對(duì)稱秘鑰，使用服務(wù)器公鑰加密，傳輸給服務(wù)端，此后，相關(guān)的 Application Data 就通過這個(gè)隨機(jī)生成的對(duì)稱秘鑰進(jìn)行加密/解密，服務(wù)器也通過該對(duì)稱秘鑰進(jìn)行解密/加密：
整體流程圖
HTTPS = HTTP + TLS/SSL
HTTPS中具體的內(nèi)容還有很多，可以通過下圖做一個(gè)參考：
總結(jié)
HTTPS就是使用SSL/TLS協(xié)議進(jìn)行加密傳輸，讓客戶端拿到服務(wù)器的公鑰，然后客戶端隨機(jī)生成一個(gè)對(duì)稱加密的秘鑰，使用公鑰加密，傳輸給服務(wù)端，后續(xù)的所有信息都通過該對(duì)稱秘鑰進(jìn)行加密解密，完成整個(gè)HTTPS的流程。
