前言
之前說到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è)只是入門級瞪醋，如果想要學(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)行尋址锣吼，通過一幅最簡單的圖來描述：
客戶端發(fā)出請求，服務(wù)端進(jìn)行響應(yīng)蓝厌，就是這么簡單玄叠。在整個(gè)過程中，沒有任何加密的東西拓提，所以它是不安全的读恃，中間人可以進(jìn)行攔截，獲取傳輸和響應(yīng)的數(shù)據(jù)代态，造成數(shù)據(jù)泄露寺惫。
加個(gè)密呢？
因?yàn)樯蠄D中數(shù)據(jù)是明文傳輸?shù)谋囊桑覀兡芟氲阶詈唵蔚奶岣甙踩缘姆椒ň褪窃趥鬏斍皩?shù)據(jù)進(jìn)行加密西雀，如下圖：
這種加密方式叫做：對稱加密。 加密和解密用同一個(gè)秘鑰的加密方式叫做對稱加密必尼。
好了蒋搜，我們對數(shù)據(jù)進(jìn)行加密了，問題解決了嗎判莉？
多個(gè)客戶端怎么辦豆挽？
這是一個(gè)客戶端，但是在WWW上券盅，是成千上萬的客戶端帮哈，情況會(huì)怎樣呢？
為所有的客戶端都應(yīng)用同一個(gè)秘鑰A锰镀，這種方式很顯然是不合理的娘侍，破解了一個(gè)用戶，所有的用戶信息都會(huì)被盜取泳炉。
想一想憾筏，是不是還有別的辦法呢？
相信大家都可以想到花鹅，如果對每一個(gè)客戶端都用不同的秘鑰進(jìn)行傳輸是不是就解決這個(gè)問題了：
對稱加密秘鑰如何傳輸氧腰？
我們對每個(gè)客戶端應(yīng)用不同的對稱加密秘鑰，那么這個(gè)秘鑰客戶端或者服務(wù)端是如何知道的呢，只能是在一端生成一個(gè)秘鑰古拴，然后通過HTTP傳輸給另一端：
那么這個(gè)傳輸秘鑰的過程箩帚，又如何保證加密？如果被中間人攔截黄痪，秘鑰也會(huì)被獲取紧帕。也許你會(huì)說，對秘鑰再進(jìn)行加密桅打，那又如何保證對秘鑰加密的過程是嗜，是加密的呢？
好像我們走入了 while(1)油额，出不來了叠纷。
非對稱加密
在對稱加密的路上走不通了，我們換個(gè)思路潦嘶，還有一種加密方式叫非對稱加密涩嚣，比如RSA。
非對稱加密會(huì)有一對秘鑰：公鑰和私鑰掂僵。
公鑰加密的內(nèi)容航厚，只有私鑰可以解開，私鑰加密的內(nèi)容锰蓬，所有的公鑰都可以解開（當(dāng)然是指和秘鑰是一對的公鑰）幔睬。
私鑰只保存在服務(wù)器端，公鑰可以發(fā)送給所有的客戶端芹扭。
在傳輸公鑰的過程中麻顶，肯定也會(huì)有被中間人獲取的風(fēng)險(xiǎn)，但在目前的情況下舱卡，至少可以保證客戶端通過公鑰加密的內(nèi)容辅肾，中間人是無法破解的，因?yàn)樗借€只保存在服務(wù)器端轮锥，只有私鑰可以破解公鑰加密的內(nèi)容矫钓。
現(xiàn)在我們還存在一個(gè)問題，如果公鑰被中間人拿到篡改呢：
MITM：Man-in-the-MiddleAttack
客戶端拿到的公鑰是假的舍杜，如何解決這個(gè)問題新娜？
第三方認(rèn)證
公鑰被掉包，是因?yàn)榭蛻舳藷o法分辨?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)的公鑰箍铭，對私鑰加密后的數(shù)字簽名進(jìn)行解密得到真正的簽名泊柬，然后客戶端利用簽名生成規(guī)則進(jìn)行簽名生成，看兩個(gè)簽名是否匹配诈火，如果匹配認(rèn)證通過兽赁，不匹配則獲取證書失敗。
為什么要有簽名冷守？
大家可以想一下刀崖，為什么要有數(shù)字簽名這個(gè)東西呢？
第三方認(rèn)證機(jī)構(gòu)是一個(gè)開放的平臺(tái)拍摇，我們可以去申請亮钦，中間人也可以去申請呀：
如果沒有簽名，只對網(wǎng)站信息進(jìn)行第三方機(jī)構(gòu)私鑰加密的話充活，會(huì)存在下面的問題：
因?yàn)闆]有認(rèn)證蜂莉，所以中間人也向第三方認(rèn)證機(jī)構(gòu)進(jìn)行申請，然后攔截后把所有的信息都替換成自己的混卵，客戶端仍然可以解密映穗，并且無法判斷這是服務(wù)器的還是中間人的，最后造成數(shù)據(jù)泄露淮菠。
對稱加密
在安全的拿到服務(wù)器的公鑰之后男公，客戶端會(huì)隨機(jī)生成一個(gè)對稱秘鑰，使用服務(wù)器公鑰加密合陵，傳輸給服務(wù)端枢赔，此后，相關(guān)的 Application Data 就通過這個(gè)隨機(jī)生成的對稱秘鑰進(jìn)行加密/解密拥知，服務(wù)器也通過該對稱秘鑰進(jìn)行解密/加密：
整體流程圖
HTTPS = HTTP + TLS/SSL
HTTPS中具體的內(nèi)容還有很多踏拜，可以通過下圖做一個(gè)參考：
總結(jié)
HTTPS就是使用SSL/TLS協(xié)議進(jìn)行加密傳輸，讓客戶端拿到服務(wù)器的公鑰低剔，然后客戶端隨機(jī)生成一個(gè)對稱加密的秘鑰速梗，使用公鑰加密肮塞，傳輸給服務(wù)端，后續(xù)的所有信息都通過該對稱秘鑰進(jìn)行加密解密姻锁，完成整個(gè)HTTPS的流程枕赵。
