HTTPS虐我千百遍，我卻待她如初戀！

本篇將討論 HTTPS 的加解密原理，很多人都知道 RSA，以為 HTTPS=RSA，使用 RSA 加解密資料，實際上這是不對的。

HTTPS 是使用 RSA 進行身份驗證和交換金鑰，然後再使用交換的金鑰進行加解密資料。

身份驗證是使用 RSA 的非對稱加密，而資料傳輸是雙方使用相同的金鑰進行的對稱加密。那麼，什麼是對稱加密和非對稱加密？

假設隔壁小王想要約小紅出來，但是他不想讓小明知道，於是他想用對稱加密給小紅傳了個小紙條。

他想傳送的資料是"Meet at 5:00 PM"（5 點見面，如果是中文的話可以使用 UTF-8 編碼），加密方式是直接在 ASCII 表進行左移或右移。

他的金鑰是 3，表示在 ASCII 表往後移 3 位，就會變成"Phhw#dw#8=33#SP"，這樣一般人如果截獲了不知道是什麼意思的。

但是我們可以想一下，如果既然他可以截獲你的資料，自然也可以截獲你的金鑰，進而進行解密。

所以小王打算用非對稱加密，非對稱加密的特點是雙方都有自己的公鑰和私鑰對，其中公鑰發給對方，金鑰不交換自己保管不洩漏。

public_key = (N, e) = (3233, 17)

她把公鑰發給了小明，她自己的私鑰為：

private_key = (N, e) = (3233, 2753)

他要傳送的第一個字母為 t=“M”，“M”的 ASCII 編碼為 77，77 的加密過程如下計算：

T = 77 ^ e  % N = 77 ^ 17 % 3233 = 3123

小紅收到 T 之後便用她的私鑰進行解密，計算如下：

t = T ^ e % N = 3123 ^ 2753 % 3233 = 77

• 驗證服務方身份，如我訪問 google.com 的時候連的確實就是谷歌伺服器

• 防止資料被劫持，例如有些運營商會給 http 的頁面插入廣告

• 防止敏感資料被竊取篡改等

正如 openssl 的註釋所說，這是防止中間人攻擊的唯一方法：

我們以 MDN（https://developer.mozilla.org）的網站為例，然後用 wireshark 抓包，觀察 HTTPS 連線建立的過程。

如下圖所示：

在 Client Hello 裡面客戶端會告知服務端自己當前的一些資訊，如下圖所示：

服務端在 Server Hello 裡面會做一些響應：

• 金鑰交換使用 ECDHE

• 證書籤名演算法 RSA

• 資料加密使用 AES 128 GCM

• 簽名校驗使用 SHA256

接著服務給客戶端發來了 4 個證書：

一個證書裡面會有什麼東西呢，我們可以展開第一個證書看一下，如下圖所示：

• tbsCertificate（to be signed certificate）待簽名證書內容

• 證書籤名演算法

• CA 給的簽名

我們先來看一下 tbsCertificate 裡面有什麼內容，如下圖所示：

Amazon 的證書也具備上述結構，我們可以把 Amazon 證書的公鑰拷出來，如下圖所示：

然後我們用這個 CA 的公鑰對 mozilla.org 的證書籤名進行解密，方法和上面的類似：

取解密後的數字 decrypted 的十六進位制的末 64 位，即為二進位制 256 位的 SHA 雜湊簽名。

接下來我們手動計算一下 tbsCertificate 的 SHA256 雜湊值，方法是在 wireshark 裡面把 tbsCertificate 匯出一個原始二進位制檔案：

然後再使用 openssl 計算它的雜湊值，如下所示：

liyinchengs-MBP:https liyincheng$ openssl dgst -sha256 ~/tbsCertificate.binSHA256(/Users/liyincheng/tbsCertificate.bin)= 5e300091593a10b944051512d39114d56909dc9a504e55cfa2e2984a883a827d

我們發現手動計算的雜湊值和加密後的證書裡的雜湊值一致！說明只有知道了 Amazon 私鑰的人才能正確地對 mozilla.org 的證書籤名，因為公私鑰是唯一匹配的。

並且第四個證書是根證書，它是內建於作業系統的（透過 Mac 的 keychain 工具可以檢視）：

假如 Hacker 透過 DNS 欺騙之類的方式把你訪問的域名指向了他的機器，然後他再偽造一個證書。

例如透過打電話或者發郵件等方式告知伺服器的簽名，與自己算的證書的簽名是否一致，如果一致說明證書沒有被篡改過（如證書的公鑰沒有被改為 Hacker 的公鑰）：

上面展示的便是自己手動計算的值，拿這個值和之前的值進行比較是否相等便可知發過來的證書是否被修改過。

而使用 ECDHE 是一種更安全的金鑰交換演算法。如下圖所示，雙方透過 ECDHE 進行金鑰交換：

ECDHE 的全稱是 Elliptic Curve Diffie–Hellman key Exchange 橢圓曲線迪非-赫爾曼金鑰交換，它是對迪非-赫爾曼金鑰交換演算法的改進。

這個演算法的思想如下圖所示：

現在的證書的簽名演算法有兩種：RSA 和新起的 EC。如下圖所示，google.com 便是使用的 ECC 證書：

如下圖所示，有一條橢圓曲線方程：

y ^ 3 = x ^ 2 + ax + b:

為了計算 3G 的座標，如下圖所示：

EC 的難點在於給定起點 G 和點 K：

K = kG

把這兩個點便是加密後的資料，發給對方，對方收到後使用私鑰 K 進行解密，過程如下：

M = C2 - rK = C2 - rkG = C2 - rkG = C2 - kC1

原理很簡單，如下圖所示：

而曲線方程是規定好的，例如 Curve X25519 使用的曲線方程為：

y^2 = x^3 + 486662x^2 + x

在金鑰交換裡面會指定所使用的曲線方程，如下圖所示：

mozilla.org 所使用的曲線方程為 secp256r1，這個也是比較流行的一個，它的引數比 Curve X25519 大很多。

EV 證書會在瀏覽器的位址列顯示證書的企業名稱：

但是新版的 Chrome 似乎把這個去掉了，所以我們開啟 medium 的控制檯可以看到一個提示：

另外我們可以用 openssl 生成一個自簽名證書，執行以下命令：

openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -keyout test.com.key -out test.com.crt

便會得到兩個檔案，test.com.crt 是證書，test.com.key 是證書的私鑰，如下圖所示：

然後把這兩個檔案給 Nginx 使用便能使用 HTTPS 訪問，如下程式碼所示：

    server {
        listen       443;
        server_name  test.com;
        ssl on;
        ssl_certificate    test.com.crt;
        ssl_certificate_key    test.com.key;
     }

可以把這個證書新增到系統證書裡面，這樣瀏覽器等便能信任，或者直接使用 mkcert 工具一步到位。

簽名驗證演算法和上文討論的 TLS 證書一致。為什麼可執行檔案需要簽名呢，因為如果不簽名的話，系統會攔截安裝或者執行，如 Mac 雙擊一個未簽名的 dmg 包的提示：

直接不讓你執行了，而 Windows 也有類似的提示，Windows 是會給一個警告：

而當我們執行一個已簽名的 exe 檔案將會是正常的提示，如 Chrome 的提示：

綜上本文主要討論了對稱加密和非對稱加密的原理，並介紹瞭如何利用 RSA 對證書籤名的檢驗以驗證連線伺服器的身份，怎麼利用 ECC 進行資料加密和金鑰交換，介紹了下怎麼生成和使用 HTTPS 證書，並介紹了下客戶端證書。

相信看完本篇，會對 HTTPS 的加解密有一個較為全面的瞭解。

來源：