前言
之前說到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á)到完全理解的效果拢军。
本文也會(huì)同步到我的個(gè)人網(wǎng)站楞陷。
正文
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的流程。
參考文章
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/
