徹底圖解 HTTPS

安全基礎

咱們先來看下數據在互聯網上數據傳遞可能會出現的三個比較有表明性的問題，其實後面提到的全部方法，都是圍繞解決這三個問題而提出來的。

竊聽

僞造

否定

對稱密鑰加密

假設 A 正在經過互聯網向 B 發送數據，若是不對數據進行加密，數據就可能被惡意的第三者 X 看到

所以，須要保密的數據須要進行加密再發送

• 用將數據進行加密，使其成爲密文
• 把密文發送給 B
• B 使用密鑰解密從 A 收到的密文，這樣就能獲得原始數據
• 由於是加密數據，即便它被惡意的第三方截獲也是安全的

「對稱密鑰加密」 一個很重要的特色就是使用相同的密鑰進行加密和解密

回到剛剛那個場景，假設 B 是沒有解密鑰匙的，因此 A 須要經過互聯網將鑰匙發送給 B

• 可是 X 也有可能看到這個鑰匙
• 所以，X 也能夠經過這個鑰匙來解密密文

上面這個場景就會引出一個新問題，這個問題被稱爲 「鑰匙交付問題」，那怎麼解決這個問題？

公開密鑰加密

爲了解決上面的 「鑰匙交付問題」，咱們這裏引入一個新的方法 —— "公開密鑰加密"，下圖是 「公開密鑰加密」 的主要特色

• 用於加密的密鑰被稱爲「公鑰」，用於解密的密鑰被稱爲「私鑰」
• 跟 「對稱密鑰加密」 相比，公開密鑰加密每每須要更多的時間用於加密和解密

咱們來看看 「公開密鑰加密」 的一整個過程

接收方 B 建立一個公鑰和一個私鑰，公鑰被髮送給 A

1. A 使用從 B 收到的公鑰加密數據，將密文發送給 B
2. B 使用私鑰解密從 A 接收到的密文，獲得原始數據

在這個過程當中

• 密文和公鑰也可能被惡意第三方 X 截獲
• 可是私鑰是 B 保存的，X 沒法獲取到，天然沒有辦法解密密文
• 這樣就很好的解決了 「鑰匙交付問題」

公開密鑰加密的問題

1. 加密和解密都須要耗費時間，有一種叫 「混合加密」 的方法能夠解決這個問題
2. 公開密鑰的可靠性

混合加密

混合密鑰加密分爲兩個步驟

1. 經過公開密鑰加密傳遞密鑰
2. 經過速度更快的對稱密鑰加密方法傳遞數據

中間人攻擊

爲了更好地理解公開密鑰加密的可靠性問題，咱們回到傳遞公鑰的場景

A 拿到的實際上是 X 發送給他的僞造公鑰，可是 A 沒法察覺

最後，X 用他本身的密鑰加密響應數據，併發送給 A，就這樣，雖然 A、B 雙方能順利完成通訊，可是惡意的第三方 X 能看到解密後的請求數據和響應數據，而 A、B 雙方則絕不知情。

這種經過祕密替換公鑰竊取數據的方法被稱爲「中間人攻擊」，問題的根源在於 A 沒法確認他們收到的公鑰是否由 B 方建立。怎麼避免中間人攻擊呢？咱們放到數字證書那節再探討，接下來再講解一點前置知識

消息鑑別碼

消息鑑別碼在英文中被稱爲 MAC，MAC 能夠理解爲密鑰和密文組成的字符串的哈希值

消息鑑別碼雖然能夠解決僞造問題，可是仍然沒法避免 否定 問題

數字簽名

爲了解決這個 否定 問題，咱們接下來看看 「數字簽名」 方法

數字證書

雖然上面的方法已經能避免 竊聽、僞造、否定 等問題，可是如今仍是沒辦法避免「中間人攻擊」，由於咱們仍是沒辦法驗證公鑰的全部者，所以咱們須要 「數字證書」 系統來驗證公鑰的全部者。

接下來，先看看數字證書申請的過程，咱們將數字證書認證機構（Certificate Authority）咱們稱之爲 CA

如今 B 已經申請到一個數字證書了，那麼怎麼使用數字證書來檢驗公鑰 PB 是屬於 B 呢

如今能夠驗證 PB 是屬於 B 的，可是怎麼驗證 PC 是屬於受信任的 CA 的呢

事實上，認證機構造成一個樹形結構，高級別的權威機構爲較低級別的機構建立證書，那就是說，若是要驗證的話，就是一級一級向上認證，信任鏈條的最終是Root CA，他採用自簽名，對他的簽名是無條件的信任。

HTTPS

徹底理解上面說的東西以後，就可以很容易理解 HTTPS，它採用的就是上面說的 「混合加密」 + 「數字證書」 兩種技術，來保證整個通訊過程的安全可靠。

HTTPS 作的事情其實就是在傳輸層跟應用層之間加了一層 SSL/TLS，用於對 TCP 傳輸內容的加密和解密

下圖咱們再看一下詳細的工做流程

用 Node 實現一箇中間人代理服務器

到此，咱們都知道了 HTTPS、數字證書等相關的知識，能夠動手實現一箇中間人代理服務了，這裏附上一個連接，有興趣的話能夠看下怎麼 用 Node 實現一箇中間人代理服務器