記住看小電影前一定要檢查網(wǎng)址是不是 HTTPS 的不然…

記住看小電影前一定要檢查網(wǎng)址是不是HTTPS的，不然…看小電影還是瀏覽正常網(wǎng)站，一定要檢查是不是HTTPS的，HTTP有可能被中間人攻擊和攔截，下面就是詳細的HTTPS原理，細思極恐1.HTTP協(xié)議

在談?wù)揌TTPS協(xié)議之前，先來回顧一下HTTP協(xié)議的概念。1.1HTTP協(xié)議介紹HTTP協(xié)議是一種基于文本的傳輸協(xié)議，它位于OSI網(wǎng)絡(luò)模型中的應(yīng)用層。HTTP協(xié)議是通過客戶端和服務(wù)器的請求應(yīng)答來進行通訊，目前協(xié)議由之前的RFC2616拆分成立六個單獨的協(xié)議說明（RFC7230、RFC7231、RFC7232、RFC7233、RFC7234、RFC7235），通訊報文如下：請求POSTHTTP/1.1Host:Connection:keep-aliveContent-Length:7User-Agent:Mozilla/5.0(WindowsNT10.0;Win64;x64)AppleWebKit/537.36(KHTML,likeGecko)Chrome/71.0.3578.98Safari/537.36wd=HTTP響應(yīng)HTTP/1.1200OKConnection:Keep-AliveContent-Encoding:gzipContent-Type:text/html;charset=utf-8Date:Thu,14Feb201907:23:49GMTTransfer-Encoding:chunked...1.2HTTP中間人攻擊HTTP協(xié)議使用起來確實非常的方便，但是它存在一個致命的缺點：不安全。搜索頂級架構(gòu)師公眾號回復(fù)“架構(gòu)”，送你一份驚喜禮包。我們知道HTTP協(xié)議中的報文都是以明文的方式進行傳輸，不做任何加密，這樣會導(dǎo)致什么問題呢？下面來舉個例子：小明在JAVA貼吧發(fā)帖，內(nèi)容為我愛JAVA：被中間人進行攻擊，內(nèi)容修改為我愛PHP小明被群嘲

可以看到在HTTP傳輸過程中，中間人能看到并且修改HTTP通訊中所有的請求和響應(yīng)內(nèi)容，所以使用HTTP是非常的不安全的。1.3防止中間人攻擊這個時候可能就有人想到了，既然內(nèi)容是明文那我使用對稱加密的方式將報文加密這樣中間人不就看不到明文了嗎，于是如下改造：雙方約定加密方式使用AES加密報文這樣看似中間人獲取不到明文信息了，但其實在通訊過程中還是會以明文的方式暴露加密方式和秘鑰，如果第一次通信被攔截到了，那么秘鑰就會泄露給中間人，中間人仍然可以解密后續(xù)的通信：那么對于這種情況，我們肯定就會考慮能不能將秘鑰進行加密不讓中間人看到呢？答案是有的，采用非對稱加密，我們可以通過RSA算法來實現(xiàn)。這個步驟實際操作也是比較簡單的。在約定加密方式的時候由服務(wù)器生成一對公私鑰，服務(wù)器將公鑰返回給客戶端，客戶端本地生成一串秘鑰(AES_KEY)用于對稱加密，并通過服務(wù)器發(fā)送的公鑰進行加密得到(AES_KEY_SECRET)，之后返回給服務(wù)端，服務(wù)端通過私鑰將客戶端發(fā)送的AES_KEY_SECRET進行解密得到AEK_KEY,最后客戶端和服務(wù)器通過AEK_KEY進行報文的加密通訊，改造如下：可以看到這種情況下中間人是竊取不到用于AES加密的秘鑰，所以對于后續(xù)的通訊是肯定無法進行解密了，那么這樣做就是絕對安全了嗎？所謂道高一尺魔高一丈，中間人為了對應(yīng)這種加密方法又想出了一個新的破解方案，既然拿不到AES_KEY，那我就把自己模擬成一個客戶端和服務(wù)器端的結(jié)合體，在用戶->中間人的過程中中間人模擬服務(wù)器的行為，這樣可以拿到用戶請求的明文，在中間人->服務(wù)器的過程中中間人模擬客戶端行為，這樣可以拿到服務(wù)器響應(yīng)的明文，以此來進行中間人攻擊：這一次通信再次被中間人截獲，中間人自己也偽造了一對公私鑰，并將公鑰發(fā)送給用戶以此來竊取客戶端生成的AES_KEY，在拿到AES_KEY之后就能輕松的進行解密了。中間人這樣為所欲為，就沒有辦法制裁下嗎，當(dāng)然有啊，接下來我們看看HTTPS是怎么解決通訊安全問題的。2.HTTPS協(xié)議2.1HTTPS簡介HTTPS其實是SSL+HTTP的簡稱,當(dāng)然現(xiàn)在SSL基本已經(jīng)被TLS取代了，不過接下來我們還是統(tǒng)一以SSL作為簡稱，SSL協(xié)議其實不止是應(yīng)用在HTTP協(xié)議上，還在應(yīng)用在各種應(yīng)用層協(xié)議上，例如：FTP、WebSocket。其實SSL協(xié)議大致就和上一節(jié)非對稱加密的性質(zhì)一樣，握手的過程中主要也是為了交換秘鑰，然后再通訊過程中使用對稱加密進行通訊，大概流程如下：這里我只是畫了個示意圖，其實真正的SSL握手會比這個復(fù)雜的多，但是性質(zhì)還是差不多，而且我們這里需要關(guān)注的重點在于HTTPS是如何防止中間人攻擊的。通過上圖可以觀察到，服務(wù)器是通過SSL證書來傳遞公鑰，客戶端會對SSL證書進行驗證，其中證書認證體系就是確保SSL安全的關(guān)鍵，接下來我們就來講解下CA認證體系，看看它是如何防止中間人攻擊的。2.2CA認證體系上一節(jié)我們看到客戶端需要對服務(wù)器返回的SSL證書進行校驗，那么客戶端是如何校驗服務(wù)器SSL證書的安全性呢。權(quán)威認證機構(gòu)在CA認證體系中，所有的證書都是由權(quán)威機構(gòu)來頒發(fā)，而權(quán)威機構(gòu)的CA證書都是已經(jīng)在操作系統(tǒng)中內(nèi)置的，我們把這些證書稱之為CA根證書：簽發(fā)證書我們的應(yīng)用服務(wù)器如果想要使用SSL的話，需要通過權(quán)威認證機構(gòu)來簽發(fā)CA證書，我們將服務(wù)器生成的公鑰和站點相關(guān)信息發(fā)送給CA簽發(fā)機構(gòu)，再由CA簽發(fā)機構(gòu)通過服務(wù)器發(fā)送的相關(guān)信息用CA簽發(fā)機構(gòu)進行加簽，由此得到我們應(yīng)用服務(wù)器的證書，證書會對應(yīng)的生成證書內(nèi)容的簽名，并將該簽名使用CA簽發(fā)機構(gòu)的私鑰進行加密得到證書指紋，并且與上級證書生成關(guān)系鏈。搜索后端架構(gòu)師公眾號回復(fù)“架構(gòu)整潔”，送你一份驚喜禮包。這里我們把百度的證書下載下來看看：可以看到百度是受信于GlobalSignG2，同樣的GlobalSignG2是受信于GlobalSignR1，當(dāng)客戶端(瀏覽器)做證書校驗時，會一級一級的向上做檢查，直到最后的根證書，如果沒有問題說明服務(wù)器證書是可以被信任的。如何驗證服務(wù)器證書那么客戶端(瀏覽器)又是如何對服務(wù)器證書做校驗的呢，首先會通過層級關(guān)系找到上級證書，通過上級證書里的公鑰來對服務(wù)器的證書指紋進行解密得到簽名(sign1)，再通過簽名算法算出服務(wù)器證書的簽名(sign2)，通過對比sign1和sign2，如果相等就說明證書是沒有被篡改也不是偽造的。這里有趣的是，證書校驗用的RSA是通過私鑰加密證書簽名，公鑰解密來巧妙的驗證證書有效性