什么是 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

具體的交互過程：

客戶端向服務器索取公鑰 PublicKey；

服務器將公鑰發給客戶端（這里沒有保密需求，因為公鑰是向所有人公開的）；

客戶端使用服務器的公鑰 PublicKey 把 Pre-Master-Key 加密成密文，傳送給服務器；

服務器用私鑰 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 就會確信領導已經審批同意你請假了

如果說人類簽名使用紙筆，那么計算機的數字化簽名怎么實現呢？

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

數字證書認證機構（Certificate Authority，簡稱 CA）生成一對公/私鑰；

服務器將自己的域名、公鑰等信息提交給 CA 審查；

CA 審查無誤，使用私鑰把服務器信息的摘要加密，生成的密文就是所謂簽名（Signature）；

CA 把服務器的信息、簽名、有效期等信息集合到一張證書上，頒發給服務器；

客戶端收到服務器發送的證書后，使用 CA 的公鑰解密簽名，獲得服務器信息的摘要，如果和證書上記錄的服務器信息的摘要一致，說明服務器信息是經過 CA 認可的

什么是信息摘要？
簡單來說，就是一段任意長的數據，經過信息摘要處理后，可以得到一段固定長度的數據，比如 32 字節，只要原始數據有任意變動，生成的信息摘要都不一樣

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

答案：與生俱來

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

以 Windows 系統為例：

系統信任的根證書

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

操作系統/瀏覽器 自帶了 CA 根證書；

客戶端因此可以驗證服務器發送的證書真實性，從而獲取到服務器的公鑰；

有了服務器的公鑰，客戶端就可以把 Pre-Master-Key 傳送給服務器；

服務器獲取到 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

總結

以上是生活随笔為你收集整理的看完你就知道什么是 HTTPS 了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。