溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“HTTPS應用實例分析”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“HTTPS應用實例分析”文章能幫助大家解決問題。
在談論 HTTPS 協議之前，先來回顧一下 HTTP 協議的概念。
HTTP 協議是一種基于文本的傳輸協議，它位于 OSI 網絡模型中的應用層。
HTTP 協議是通過客戶端和服務器的請求應答來進行通訊，目前協議由之前的 RFC 2616 拆分成立六個單獨的協議說明（RFC 7230、RFC 7231、RFC 7232、RFC 7233、RFC 7234、RFC 7235），通訊報文如下：
POST http://www.baidu.com HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Content-Length: 7
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
wd=HTTP HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Thu, 14 Feb 2019 07:23:49 GMT
Transfer-Encoding: chunked
<html>...</html> HTTP 協議使用起來確實非常的方便，但是它存在一個致命的缺點：不安全。
我們知道 HTTP 協議中的報文都是以明文的方式進行傳輸，不做任何加密，這樣會導致什么問題呢？下面來舉個例子：
我愛JAVA：
我愛PHP
可以看到在 HTTP 傳輸過程中，中間人能看到并且修改 HTTP 通訊中所有的請求和響應內容，所以使用 HTTP 是非常的不安全的。
這個時候可能就有人想到了，既然內容是明文那我使用對稱加密的方式將報文加密這樣中間人不就看不到明文了嗎，于是如下改造：
這樣看似中間人獲取不到明文信息了，但其實在通訊過程中還是會以明文的方式暴露加密方式和秘鑰，如果第一次通信被攔截到了，那么秘鑰就會泄露給中間人，中間人仍然可以解密后續的通信：
那么對于這種情況，我們肯定就會考慮能不能將秘鑰進行加密不讓中間人看到呢？答案是有的，采用非對稱加密，我們可以通過 RSA 算法來實現。
在約定加密方式的時候由服務器生成一對公私鑰，服務器將公鑰返回給客戶端，客戶端本地生成一串秘鑰(AES_KEY)用于對稱加密，并通過服務器發送的公鑰進行加密得到(AES_KEY_SECRET)，之后返回給服務端，服務端通過私鑰將客戶端發送的AES_KEY_SECRET進行解密得到AEK_KEY,最后客戶端和服務器通過AEK_KEY進行報文的加密通訊，改造如下：
可以看到這種情況下中間人是竊取不到用于AES加密的秘鑰，所以對于后續的通訊是肯定無法進行解密了，那么這樣做就是絕對安全了嗎？
所謂道高一尺魔高一丈，中間人為了對應這種加密方法又想出了一個新的破解方案，既然拿不到AES_KEY，那我就把自己模擬成一個客戶端和服務器端的結合體，在用戶->中間人的過程中中間人模擬服務器的行為，這樣可以拿到用戶請求的明文，在中間人->服務器的過程中中間人模擬客戶端行為，這樣可以拿到服務器響應的明文，以此來進行中間人攻擊：
這一次通信再次被中間人截獲，中間人自己也偽造了一對公私鑰，并將公鑰發送給用戶以此來竊取客戶端生成的AES_KEY，在拿到AES_KEY之后就能輕松的進行解密了。
中間人這樣為所欲為，就沒有辦法制裁下嗎，當然有啊，接下來我們看看 HTTPS 是怎么解決通訊安全問題的。
HTTPS 其實是SSL+HTTP的簡稱,當然現在SSL基本已經被TLS取代了，不過接下來我們還是統一以SSL作為簡稱，SSL協議其實不止是應用在HTTP協議上，還在應用在各種應用層協議上，例如：FTP、WebSocket。
其實SSL協議大致就和上一節非對稱加密的性質一樣，握手的過程中主要也是為了交換秘鑰，然后再通訊過程中使用對稱加密進行通訊，大概流程如下：
這里我只是畫了個示意圖，其實真正的 SSL 握手會比這個復雜的多，但是性質還是差不多，而且我們這里需要關注的重點在于 HTTPS 是如何防止中間人攻擊的。
通過上圖可以觀察到，服務器是通過 SSL 證書來傳遞公鑰，客戶端會對 SSL 證書進行驗證，其中證書認證體系就是確保SSL安全的關鍵，接下來我們就來講解下CA 認證體系，看看它是如何防止中間人攻擊的。
上一節我們看到客戶端需要對服務器返回的 SSL 證書進行校驗，那么客戶端是如何校驗服務器 SSL 證書的安全性呢。
權威認證機構 在 CA 認證體系中，所有的證書都是由權威機構來頒發，而權威機構的 CA 證書都是已經在操作系統中內置的，我們把這些證書稱之為CA根證書：
簽發證書
我們的應用服務器如果想要使用 SSL 的話，需要通過權威認證機構來簽發
CA證書
我們將服務器生成的公鑰和站點相關信息發送給
CA簽發機構
再由
CA簽發機構
通過服務器發送的相關信息用
CA簽發機構
進行加簽，由此得到我們應用服務器的證書，證書會對應的生成證書內容的
簽名
并將該
簽名
使用
CA簽發機構
的私鑰進行加密得到
證書指紋
并且與上級證書生成關系鏈。
這里我們把百度的證書下載下來看看：
可以看到百度是受信于GlobalSign G2，同樣的GlobalSign G2是受信于GlobalSign R1，當客戶端(瀏覽器)做證書校驗時，會一級一級的向上做檢查，直到最后的根證書，如果沒有問題說明服務器證書是可以被信任的。
如何驗證服務器證書 那么客戶端(瀏覽器)又是如何對服務器證書做校驗的呢，首先會通過層級關系找到上級證書，通過上級證書里的公鑰來對服務器的證書指紋進行解密得到簽名(sign1)，再通過簽名算法算出服務器證書的簽名(sign2)，通過對比sign1和sign2，如果相等就說明證書是沒有被篡改也不是偽造的。
這里有趣的是，證書校驗用的 RSA 是通過私鑰加密證書簽名，公鑰解密來巧妙的驗證證書有效性。
這樣通過證書的認證體系，我們就可以避免了中間人竊取AES_KEY從而發起攔截和修改 HTTP 通訊的報文。
關于“HTTPS應用實例分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
