看完你就知道什麼是 HTTPS 了

什麼是 HTTPS ?

不論是使用手機仍是電腦上網，都離不開數據的通信

如今互聯網上傳輸數據，廣泛使用的是超文本傳輸協議，即 HTTP (HyperText Transfer Protocol)

因此，咱們之前在上網的時候，會發現全部的網址都有一個 http:// 前綴：

HTTP 協議

簡單而言，HTTP 協議定義了一套規範，讓客戶端或瀏覽器能夠和服務器正常通訊，完成數據傳輸

可是，HTTP 使用明文傳輸，好比你輸入帳號/密碼提交登陸：

明文傳輸

頗有可能被中間人竊聽，從而形成數據泄露，因此說 HTTP 是不安全的，現代瀏覽器會在地址欄提示鏈接不安全：

火狐瀏覽器安全提示

爲了解決安全傳輸的問題，人們發明了 HTTPS，即 HTTP + Secure

爲何 HTTPS 是安全的？

只要把傳輸的數據加密，那麼通訊就是安全的，前提是除通訊雙方外，任何第三方沒法解密：

加密傳輸

在上圖示例中，通訊的數據通過加密，即便被中間人竊聽到了，它也沒法知道數據內容

火狐瀏覽器安全提示

HTTPS 是怎麼實現安全通訊的？

加密傳輸確實安全，可是客戶端把數據加密後，服務器怎麼解密呢？又怎樣保證中間人竊聽到密文後沒法解密呢？

答案是：使用對稱加密技術

什麼是對稱加密？
簡單而言，通訊雙方各有一把相同的鑰匙（所謂對稱），客戶端把數據加密鎖起來後，傳送給服務器，服務器再用鑰匙解密。同理，服務器加密後傳輸給客戶端的數據，客戶端也能夠用鑰匙解密

那麼，新的問題又出現了：怎樣在通訊以前，給雙方分配兩把同樣的鑰匙呢？

若是真的只有兩我的要通訊的話，能夠簡單的私下見個面分配好，之後要通訊的時候用就行。可是，實際通訊每每是一個服務器和成千上萬的客戶端之間，總不能讓每一個人都和服務器先私下見個面

另外，即便使用了對稱加密技術，若是一方保管不善的話，也有可能鑰匙被人偷了去複製一個，這樣就存在很大的安全隱患，最好是每一個客戶端每次和服務器通訊都用不一樣的密鑰

一個簡單的解決方案是：客戶端在每次請求通訊以前，先和服務器協商，經過某種辦法，產生只有雙方知道的對稱密鑰

這個過程就是所謂：密鑰交換(Key Exchange)

密鑰交換算法有不少種實現，常見的有：

• Deffie-Hellman 密鑰交換算法
• RSA 密鑰交換算法

本文以較簡單的 RSA 密鑰交換爲例

簡單而言，RSA 密鑰交換算法須要客戶端向服務器提供一個 Pre-Master-Key，而後通訊雙方再生成 Master-Key，最後根據 Master-Key 產生後續一系列所須要的密鑰，包括傳輸數據的時候使用的對稱密鑰

那麼，客戶端怎麼把 Pre-Master-Key 告訴服務器呢？直接明文傳輸麼？

咱們以前說過，沒加密的通訊都會被竊聽，是不安全的

彷佛進入死循環了：爲了加密通訊，須要先把 Pre-Master-Key 傳送給服務器，可是這個傳送又必需要加密

咱們引入一種新的加密技術：非對稱加密

什麼是非對稱加密？
簡單而言，服務器能夠生成一對不一樣的密鑰（所謂非對稱），一把私自保存，稱爲私鑰；一把向全部人公開，稱爲公鑰
這對密鑰有這樣的性質：公鑰加密後的數據只有私鑰能解密，私鑰加密後的數據只有公鑰能解密
非對稱加密的一種經典實現叫 RSA 算法，這種加密算法最先 1977 年由羅納德·李維斯特（Ron Rivest）、阿迪·薩莫爾（Adi Shamir）和倫納德·阿德曼（Leonard Adleman）一塊兒提出的，RSA 就是他們三人姓氏開頭字母拼在一塊兒組成的

有了非對稱加密的技術後，事情就好辦了：

客戶端把 Pre-Master-Key 用服務器的公鑰加密後，傳送給服務器

由於只有服務器纔有私鑰，因此只有服務器才能解密數據，獲取客戶端發送來的 Pre-Master-Key

具體的交互過程：

1. 客戶端向服務器索取公鑰 PublicKey；
2. 服務器將公鑰發給客戶端（這裏沒有保密需求，由於公鑰是向全部人公開的）；
3. 客戶端使用服務器的公鑰 PublicKey 把 Pre-Master-Key 加密成密文，傳送給服務器；
4. 服務器用私鑰 PrivateKey 解密密文，獲取到客戶端發送的 Pre-Master-Key;

看起來很完美，可是第 2 步驟又引起了一個新問題：

因爲互聯網是公開的，服務器發送給客戶端的公鑰可能在傳送過程當中被中間人截獲並篡改（所謂中間人攻擊 Man-in-the-middle attack，縮寫：MITM）

中間人攻擊

由於中間人也能夠生成一對非對稱密鑰，它會截獲服務器發送的公鑰，而後把它本身的公鑰 MiddleMan-PublicKey 發送給客戶端，進行欺騙

可憐咱們的客戶端，居然信覺得真！而後傻乎乎的把本身的 Pre-Master-Key 用 MiddleMan-PublicKey 加密後，發給中間人

怎麼解決這個問題？

問題等價於：客戶端怎麼肯定收到的公鑰，真的就是服務器的公鑰？

想想你乘高鐵、坐飛機的時候，怎麼向工做人員證實你是你

答案很簡單，到公安局（權威機構 英文名：Authority）出個身份證實（Certificate）

身份證上記載了你的號碼、姓名、年齡、照片、住址，還有簽發機關、有效期等

因此，服務器也想辦法到權威機構 (Authority) 辦一張證書 Certificate，上面記載了服務器的域名、公鑰、所屬單位，還有簽發機關、有效期等

當客戶端收到服務器發過來的證書後，只要證書不是僞造的，那麼上面記載的公鑰確定也就是真的！

證書長啥樣？
點擊 IE 瀏覽器上的小鎖就能夠查看服務器的證書

查看證書

不過，這裏又有個新問題：怎麼證實證書不是僞造的？

咱們介紹一種防僞手段：簽名（Signature）

什麼是簽名？
咱們在生活、工做過程當中，常常遇到須要簽名的狀況：刷信用卡、籤合同等，用來證實這是本人的行爲。簽名之因此可信，是由於理論上每一個人的簽名都有生理學基礎，別人是沒法僞造的，就像你的指紋同樣

因此，只要服務器發送的證書上有權威機構 Authority 的簽名，就能夠確信證書是頒發給服務器的，而不是誰僞造的

這就至關於，只要你的請假條上有領導的簽名，那麼 HR 就會確信領導已經審批贊成你請假了

若是說人類簽名使用紙筆，那麼計算機的數字化簽名怎麼實現呢？

答案是使用非對稱加密技術：

1. 數字證書認證機構（Certificate Authority，簡稱 CA）生成一對公/私鑰；
2. 服務器將本身的域名、公鑰等信息提交給 CA 審查；
3. CA 審查無誤，使用私鑰把服務器信息的摘要加密，生成的密文就是所謂簽名（Signature）；
4. CA 把服務器的信息、簽名、有效期等信息集合到一張證書上，頒發給服務器；
5. 客戶端收到服務器發送的證書後，使用 CA 的公鑰解密簽名，得到服務器信息的摘要，若是和證書上記錄的服務器信息的摘要一致，說明服務器信息是通過 CA 承認的

什麼是信息摘要？
簡單來講，就是一段任意長的數據，通過信息摘要處理後，能夠獲得一段固定長度的數據，好比 32 字節，只要原始數據有任意變更，生成的信息摘要都不同

可是，在第5步驟又有一個新問題：客戶端怎麼知道 CA 的公鑰？

答案：與生俱來

世界上的根 CA 就那麼幾家，瀏覽器或者操做系統在出廠的時候，已經內置了這些機構的自簽名證書，上面記錄他們的公鑰信息，你也能夠在須要的時候手動安裝 CA 證書

以 Windows 系統爲例：

系統信任的根證書

至此，HTTPS 通訊過程已經很明朗了：

1. 操做系統/瀏覽器 自帶了 CA 根證書；
2. 客戶端所以能夠驗證服務器發送的證書真實性，從而獲取到服務器的公鑰；
3. 有了服務器的公鑰，客戶端就能夠把 Pre-Master-Key 傳送給服務器；
4. 服務器獲取到 Pre-Master-Key 後，經過後續產生的對稱密鑰，就能夠和客戶端加密通訊了。

總結

本文簡述了 HTTPS 通信過程的基本原理，涉及到了對稱加密、非對稱加密、信息摘要、簽名、密鑰交換等技術基礎，以及發行機構、數字證書等概念

具體的 HTTPS 實現細節還要複雜得多，這裏並無展開講，可是並不影響對 HTTPS 不熟悉的讀者對原理有基本的認知

參考文獻

• 傳輸層安全協議規範 tools.ietf.org/html/rfc524…
• HTTPS 鏈接前的幾毫秒發生了什麼 www.moserware.com/2009/06/fir…
• 查看 Windows 系統根證書 technet.microsoft.com/zh-cn/libra…

還有問題？ 聯繫做者微博/微信 @Ceelog