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