面試官：爲何HTTPS是安全的

關注前端瓶子君，回覆「交流」

加入咱們一塊兒學習，每天進步html

來源：r6a.cn/efZ2

1. HTTP 協議

在談論 HTTPS 協議以前，先來回顧一下 HTTP 協議的概念。

1.1 HTTP 協議介紹

HTTP 協議是一種基於文本的傳輸協議，它位於 OSI 網絡模型中的 應用層 。

HTTP 協議是經過客戶端和服務器的請求應答來進行通信，目前協議由以前的 RFC 2616 拆分紅立六個單獨的協議說明（RFC 7230、RFC 723一、RFC 723二、RFC 723三、RFC 723四、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>

1.2 HTTP 中間人攻擊

HTTP 協議使用起來確實很是的方便，可是它存在一個致命的缺點： 不安全 。

咱們知道 HTTP 協議中的報文都是以明文的方式進行傳輸，不作任何加密，這樣會致使什麼問題呢？下面來舉個例子：

小明在 JAVA 貼吧發帖，內容爲 我愛JAVA ：
被中間人進行攻擊，內容修改成 我愛PHP
小明被羣嘲(手動狗頭)

能夠看到在 HTTP 傳輸過程當中，中間人能看到而且修改 HTTP 通信中全部的請求和響應內容，因此使用 HTTP 是很是的不安全的。

1.3 防止中間人攻擊

這個時候可能就有人想到了，既然內容是明文那我使用 對稱加密 的方式將報文加密這樣中間人不就看不到明文了嗎，因而以下改造：

雙方約定加密方式
使用 AES 加密報文

這樣看似中間人獲取不到明文信息了，但其實在通信過程當中仍是會以明文的方式暴露加密方式和祕鑰，若是第一次通訊被攔截到了，那麼祕鑰就會泄露給中間人，中間人仍然能夠解密後續的通訊：

那麼對於這種狀況，咱們確定就會考慮能不能將祕鑰進行加密不讓中間人看到呢？答案是有的，採用 非對稱加密 ，咱們能夠經過 RSA 算法來實現。

在約定加密方式的時候由服務器生成一對 公私鑰 ，服務器將 公鑰 返回給客戶端，客戶端本地生成一串祕鑰( AES_KEY )用於 對稱加密 ，並經過服務器發送的 公鑰 進行加密獲得( AES_KEY_SECRET )，以後返回給服務端，服務端經過 私鑰 將客戶端發送的 AES_KEY_SECRET 進行解密獲得 AEK_KEY ,最後客戶端和服務器經過 AEK_KEY 進行報文的加密通信，改造以下：

能夠看到這種狀況下中間人是竊取不到用於 AES加密 的祕鑰，因此對於後續的通信是確定沒法進行解密了，那麼這樣作就是絕對安全了嗎？

所謂道高一尺魔高一丈，中間人爲了對應這種加密方法又想出了一個新的破解方案，既然拿不到 AES_KEY ，那我就把本身模擬成一個客戶端和服務器端的結合體，在 用戶->中間人 的過程當中中間人模擬服務器的行爲，這樣能夠拿到用戶請求的明文，在 中間人->服務器 的過程當中中間人模擬客戶端行爲，這樣能夠拿到服務器響應的明文，以此來進行中間人攻擊：

這一次通訊再次被中間人截獲，中間人本身也僞造了一對公私鑰，並將公鑰發送給用戶以此來竊取客戶端生成的 AES_KEY ，在拿到 AES_KEY 以後就能輕鬆的進行解密了。

中間人這樣隨心所欲，就沒有辦法制裁下嗎，固然有啊，接下來咱們看看 HTTPS 是怎麼解決通信安全問題的。

2. HTTPS 協議

2.1 HTTPS 簡介

HTTPS 實際上是 SSL+HTTP 的簡稱,固然如今 SSL 基本已經被 TLS 取代了，不過接下來咱們仍是統一以 SSL 做爲簡稱， SSL 協議其實不止是應用在 HTTP 協議上，還在應用在各類應用層協議上，例如： FTP 、 WebSocket 。

其實 SSL 協議大體就和上一節 非對稱加密 的性質同樣，握手的過程當中主要也是爲了交換祕鑰，而後再通信過程當中使用 對稱加密 進行通信，大概流程以下：

這裏我只是畫了個示意圖，其實真正的 SSL 握手會比這個複雜的多，可是性質仍是差很少，並且咱們這裏須要關注的重點在於 HTTPS 是如何防止中間人攻擊的。

經過上圖能夠觀察到，服務器是經過 SSL 證書來傳遞 公鑰 ，客戶端會對 SSL 證書進行驗證，其中證書認證體系就是確保 SSL 安全的關鍵，接下來咱們就來說解下 CA 認證體系 ，看看它是如何防止中間人攻擊的。

2.2 CA 認證體系

上一節咱們看到客戶端須要對服務器返回的 SSL 證書進行校驗，那麼客戶端是如何校驗服務器 SSL 證書的安全性呢。

權威認證機構前端

在 CA 認證體系中，全部的證書都是由權威機構來頒發，而權威機構的 CA 證書都是已經在操做系統中內置的，咱們把這些證書稱之爲CA根證書：web
簽發證書面試

咱們的應用服務器若是想要使用 SSL 的話，須要經過權威認證機構來簽發CA證書，咱們將服務器生成的公鑰和站點相關信息發送給CA簽發機構，再由CA簽發機構經過服務器發送的相關信息用CA簽發機構進行加簽，由此獲得咱們應用服務器的證書，證書會對應的生成證書內容的簽名，並將該簽名使用CA簽發機構的私鑰進行加密獲得證書指紋，而且與上級證書生成關係鏈。算法

這裏咱們把百度的證書下載下來看看：瀏覽器

能夠看到百度是受信於 GlobalSign G2 ，一樣的 GlobalSign G2 是受信於 GlobalSign R1 ，當客戶端(瀏覽器)作證書校驗時，會一級一級的向上作檢查，直到最後的 根證書 ，若是沒有問題說明 服務器證書 是能夠被信任的。

如何驗證服務器證書安全

那麼客戶端(瀏覽器)又是如何對服務器證書作校驗的呢，首先會經過層級關係找到上級證書，經過上級證書裏的公鑰來對服務器的證書指紋進行解密獲得簽名(sign1)，再經過簽名算法算出服務器證書的簽名(sign2)，經過對比sign1和sign2，若是相等就說明證書是沒有被篡改也不是僞造的。服務器

這裏有趣的是，證書校驗用的 RSA 是經過私鑰加密證書籤名，公鑰解密來巧妙的驗證證書有效性。

這樣經過證書的認證體系，咱們就能夠避免了中間人竊取 AES_KEY 從而發起攔截和修改 HTTP 通信的報文。

總結

首先先經過對 HTTP 中間人攻擊的來了解到 HTTP 爲何是不安全的，而後再從安全攻防的技術演變一直到 HTTPS 的原理歸納，但願能讓你們對 HTTPS 有個更深入的瞭解。

最後

歡迎關注「前端瓶子君」，回覆「交流」加入前端交流羣！

歡迎關注「前端瓶子君」，回覆「算法」自動加入，從0到1構建完整的數據結構與算法體系！

另外，每週還有手寫源碼題，瓶子君也會解答喲！

》》面試官也在看的算法資料《《

「在看和轉發」就是最大的支持

本文分享自微信公衆號 - 前端瓶子君（pinzi_com）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。微信