本篇將討論 HTTPS 的加解密原理，很多人都知道 RSA，以為 HTTPS=RSA，使用 RSA 加解密數(shù)據(jù)，實(shí)際上這是不對(duì)的。

[[279306]] 

圖片來(lái)自 Pexels

HTTPS 是使用 RSA 進(jìn)行身份驗(yàn)證和交換密鑰，然后再使用交換的密鑰進(jìn)行加解密數(shù)據(jù)。

身份驗(yàn)證是使用 RSA 的非對(duì)稱(chēng)加密，而數(shù)據(jù)傳輸是雙方使用相同的密鑰進(jìn)行的對(duì)稱(chēng)加密。那么，什么是對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密?

對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密

假設(shè)隔壁小王想要約小紅出來(lái)，但是他不想讓小明知道，于是他想用對(duì)稱(chēng)加密給小紅傳了個(gè)小紙條。

如下圖所示：

 

他想發(fā)送的數(shù)據(jù)是"Meet at 5:00 PM"(5 點(diǎn)見(jiàn)面，如果是中文的話(huà)可以使用 UTF-8 編碼)，加密方式是直接在 ASCII 表進(jìn)行左移或右移。

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

但是我們可以想一下，如果既然他可以截獲你的數(shù)據(jù)，自然也可以截獲你的密鑰，進(jìn)而進(jìn)行解密。

如下圖所示：

 

所以小王打算用非對(duì)稱(chēng)加密，非對(duì)稱(chēng)加密的特點(diǎn)是雙方都有自己的公鑰和私鑰對(duì)，其中公鑰發(fā)給對(duì)方，密鑰不交換自己保管不泄漏。

如下圖所示：

其中小紅的公鑰為：

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

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

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

這里注意公鑰和私鑰都是兩個(gè)數(shù)，N 通常是一個(gè)大整數(shù)，e 表示一個(gè)冪指數(shù)。現(xiàn)在小王想給小紅發(fā)消息，于是他用小紅的公鑰進(jìn)行加密，怎么加密呢?

他要發(fā)送的第一個(gè)字母為 t=“M”，“M”的 ASCII 編碼為 77，77 的加密過(guò)程如下計(jì)算：

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

把 77 做 e 次冪然后模以 N，便得到了 T=3123，然后把這個(gè)數(shù)發(fā)給小紅(其他字母按同樣方式處理)。

小紅收到 T 之后便用她的私鑰進(jìn)行解密，計(jì)算如下：

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

計(jì)算方法是一樣的，這樣便把 T 還原成了 t，只要公私鑰配對(duì)，便可通過(guò)一些數(shù)學(xué)公式證明上面的推算是成立的。這個(gè)就是 RSA 的加解密原理，如果無(wú)法知道私鑰便無(wú)法進(jìn)行正確解密。

反過(guò)來(lái)，使用私鑰進(jìn)行加密，公鑰進(jìn)行解密也是可行的。那么 HTTPS 是怎么利用 RSA 進(jìn)行加解密的呢，我們從 HTTPS 連接建立過(guò)程說(shuō)起。

HTTPS 連接建立過(guò)程

HTTPS 主要有以下作用：

• 驗(yàn)證服務(wù)方身份，如我訪(fǎng)問(wèn) google.com 的時(shí)候連的確實(shí)就是谷歌服務(wù)器
• 防止數(shù)據(jù)被劫持，例如有些運(yùn)營(yíng)商會(huì)給 http 的頁(yè)面插入廣告
• 防止敏感數(shù)據(jù)被竊取篡改等

正如 openssl 的注釋所說(shuō)，這是防止中間人攻擊的唯一方法：

我們以 MDN(https://developer.mozilla.org)的網(wǎng)站為例，然后用 wireshark 抓包，觀察 HTTPS 連接建立的過(guò)程。

如下圖所示：

首先是 TCP 三次握手，然后客戶(hù)端(瀏覽器)發(fā)起一個(gè) HTTPS 連接建立請(qǐng)求，客戶(hù)端先發(fā)一個(gè) Client Hello 的包，然后服務(wù)端響應(yīng)一個(gè) Server Hello。 

接著再給客戶(hù)端發(fā)送它的證書(shū)，然后雙方經(jīng)過(guò)密鑰交換，最后使用交換的密鑰加行加解密數(shù)據(jù)。

在 Client Hello 里面客戶(hù)端會(huì)告知服務(wù)端自己當(dāng)前的一些信息，如下圖所示：

 

包括客戶(hù)端要使用的 TLS 版本，支持的加密套裝，要訪(fǎng)問(wèn)的域名，給服務(wù)端生成的一個(gè)隨機(jī)數(shù)(Nonce)等。

需要提前告知服務(wù)器想要訪(fǎng)問(wèn)的域名以便服務(wù)器發(fā)送相應(yīng)的域名的證書(shū)過(guò)來(lái)，因?yàn)榇藭r(shí)還沒(méi)有發(fā)生 HTTP 請(qǐng)求。

服務(wù)端在 Server Hello 里面會(huì)做一些響應(yīng)：

 

服務(wù)端選中的加密套裝叫 TLSECDHERSAWITHAES128GCM_SHA256，這一串的意思是：

• 密鑰交換使用 ECDHE
• 證書(shū)簽名算法 RSA
• 數(shù)據(jù)加密使用 AES 128 GCM
• 簽名校驗(yàn)使用 SHA256

接著服務(wù)給客戶(hù)端發(fā)來(lái)了 4 個(gè)證書(shū)：

第一個(gè)證書(shū)的公用名(common name)就是我們當(dāng)前訪(fǎng)問(wèn)的域名 developer.mozilla.org。 

如果公用名是 *.mozilla.org 的話(huà)那么這個(gè)證書(shū)便能給 mozilla.org 的所有二級(jí)子域名使用。

第二個(gè)證書(shū)是第一個(gè)證書(shū)的簽發(fā)機(jī)構(gòu)(CA)的證書(shū)，它是 Amazon，也就是說(shuō) Amazon 會(huì)用它的私鑰給 developer.mozilla.org 進(jìn)行簽名。

依此類(lèi)推，第三個(gè)證書(shū)會(huì)給第二個(gè)證書(shū)簽名，第四個(gè)證書(shū)會(huì)給第三個(gè)證書(shū)簽名，并且我們可以看到第四個(gè)證書(shū)是一個(gè)根(Root)證書(shū)。

一個(gè)證書(shū)里面會(huì)有什么東西呢，我們可以展開(kāi)第一個(gè)證書(shū)看一下，如下圖所示：

證書(shū)包含三部分內(nèi)容： 

• tbsCertificate(to be signed certificate)待簽名證書(shū)內(nèi)容
• 證書(shū)簽名算法
• CA 給的簽名

也就是說(shuō) CA 會(huì)用它的私鑰對(duì) tbsCertificate 進(jìn)行簽名，并放在簽名部分。為什么證書(shū)要簽名呢?簽名是為了驗(yàn)證身份。

身份驗(yàn)證

我們先來(lái)看一下 tbsCertificate 里面有什么內(nèi)容，如下圖所示：

它里面包括了證書(shū)的公鑰、證書(shū)的適用公用名、證書(shū)的有效期還有它的簽發(fā)者等信息。 

Amazon 的證書(shū)也具備上述結(jié)構(gòu)，我們可以把 Amazon 證書(shū)的公鑰拷出來(lái)，如下圖所示：

 

中間有一些填充的數(shù)字，用灰色字表示。可以看到N通常是一個(gè)很大的整數(shù)(二進(jìn)制 2048 位)，而 e 通常為 65537。

然后我們用這個(gè) CA 的公鑰對(duì) mozilla.org 的證書(shū)簽名進(jìn)行解密，方法和上面的類(lèi)似：

 

取解密后的數(shù)字 decrypted 的十六進(jìn)制的末 64 位，即為二進(jìn)制 256 位的 SHA 哈希簽名。

接下來(lái)我們手動(dòng)計(jì)算一下 tbsCertificate 的 SHA256 哈希值，方法是在 wireshark 里面把 tbsCertificate 導(dǎo)出一個(gè)原始二進(jìn)制文件：

 

然后再使用 openssl 計(jì)算它的哈希值，如下所示：

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

我們發(fā)現(xiàn)手動(dòng)計(jì)算的哈希值和加密后的證書(shū)里的哈希值一致!說(shuō)明只有知道了 Amazon 私鑰的人才能正確地對(duì) mozilla.org 的證書(shū)簽名，因?yàn)楣借€是唯一匹配的。

因此我們驗(yàn)證了第一個(gè)證書(shū) mozilla.org 確實(shí)是由第二個(gè)證書(shū) Amazon 簽發(fā)的，使用同樣的方式，我們可以驗(yàn)證 Amazon 是由第三個(gè)簽發(fā)的，第三個(gè)是由第四個(gè)根證書(shū)簽發(fā)。

并且第四個(gè)證書(shū)是根證書(shū)，它是內(nèi)置于操作系統(tǒng)的(通過(guò) Mac 的 keychain 工具可以查看)：

 

假如 Hacker 通過(guò) DNS 欺騙之類(lèi)的方式把你訪(fǎng)問(wèn)的域名指向了他的機(jī)器，然后他再偽造一個(gè)證書(shū)。

但是由于根證書(shū)都是內(nèi)置于操作系統(tǒng)的，所以它改不了簽名的公鑰，并且它沒(méi)有正確的私鑰，只能用自己的私鑰，由于公私鑰不配對(duì)，很難保證加解密后的信息一致。

或者直接把瀏覽器拿到的證書(shū)搬到他自己的服務(wù)器?這樣再給瀏覽器發(fā)的證書(shū)便是一模一樣，但是由于他不知道證書(shū)的私鑰，所以無(wú)法進(jìn)行后續(xù)的操作，因此這樣是沒(méi)有意義的。

這個(gè)就是 HTTPS 能夠驗(yàn)證身份的原理。另外一個(gè)例子是 SSH，需要手動(dòng)驗(yàn)證簽名是否正確。

例如通過(guò)打電話(huà)或者發(fā)郵件等方式告知服務(wù)器的簽名，與自己算的證書(shū)的簽名是否一致，如果一致說(shuō)明證書(shū)沒(méi)有被篡改過(guò)(如證書(shū)的公鑰沒(méi)有被改為 Hacker 的公鑰)：

 

上面展示的便是自己手動(dòng)計(jì)算的值，拿這個(gè)值和之前的值進(jìn)行比較是否相等便可知發(fā)過(guò)來(lái)的證書(shū)是否被修改過(guò)。

那么，為什么不直接使用 RSA 的密鑰對(duì)進(jìn)行加密數(shù)據(jù)?因?yàn)?RSA 的密鑰對(duì)數(shù)值太大，不太合適頻繁地加解密數(shù)據(jù)，所以需要更小的密鑰。

另一個(gè)原因是服務(wù)端沒(méi)有瀏覽器或者客戶(hù)端的密鑰，無(wú)法向?yàn)g覽器發(fā)送加密的數(shù)據(jù)(不能用自己的私鑰加密，因?yàn)楣€是公開(kāi)的)。所以需要進(jìn)行密鑰交換。

密鑰交換

密鑰交換的方式有兩種：RSA 和 ECDHE，RSA 的方式比較簡(jiǎn)單，瀏覽器生成一把密鑰，然后使用證書(shū) RSA 的公鑰進(jìn)行加密發(fā)給服務(wù)端，服務(wù)再使用它的密鑰進(jìn)行解密得到密鑰，這樣就能夠共享密鑰了。

它的缺點(diǎn)是攻擊者雖然在發(fā)送的過(guò)程中無(wú)法破解，但是如果它保存了所有加密的數(shù)據(jù)，等到證書(shū)到期沒(méi)有被維護(hù)之類(lèi)的原因?qū)е滤借€泄露，那么它就可以使用這把私鑰去解密之前傳送過(guò)的所有數(shù)據(jù)。

而使用 ECDHE 是一種更安全的密鑰交換算法。如下圖所示，雙方通過(guò) ECDHE 進(jìn)行密鑰交換：

 

ECDHE 的全稱(chēng)是 Elliptic Curve Diffie–Hellman key Exchange 橢圓曲線(xiàn)迪非-赫爾曼密鑰交換，它是對(duì)迪非-赫爾曼密鑰交換算法的改進(jìn)。

這個(gè)算法的思想如下圖所示：

為了得到共享秘鑰 K，甲用它的私鑰計(jì)算一個(gè)數(shù) g^a，發(fā)送給乙，乙的私鑰為 b，乙便得到 K= g^a^b，同時(shí)發(fā)送 g^b 給甲，甲也得到了 K=g^b^a。 

這個(gè)應(yīng)該比較好理解，而引入橢圓曲線(xiàn)加密能夠提高破解難度。

橢圓曲線(xiàn)加密

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

 

我們上面討論的便是 RSA，破解 RSA 的難點(diǎn)在于無(wú)法對(duì)公鑰的 N 進(jìn)行質(zhì)數(shù)分解。

如果你能對(duì)證書(shū)的 N 拆成兩個(gè)質(zhì)數(shù)相乘，便可推算出證書(shū)的私鑰，但是在當(dāng)前的計(jì)算能力下是不可能的。而 ECC 的破解難點(diǎn)在于找到指定點(diǎn)的系數(shù)。

如下圖所示，有一條橢圓曲線(xiàn)方程：

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

 

給定一個(gè)起點(diǎn) G(x，y)，現(xiàn)在要計(jì)算點(diǎn) P=2G 的坐標(biāo)，其過(guò)程是在 G 點(diǎn)上做一條線(xiàn)與曲線(xiàn)相切于 -2G，做 -2G 相對(duì)于 x 軸的反射便得到 2G 點(diǎn)。

為了計(jì)算 3G 的坐標(biāo)，如下圖所示：

 

連接 2G 與 G 與曲線(xiàn)相郊于 -3G，再做反射得到 3G，同理計(jì)算 4G 便是連接 G 與 3G 再做反射。如果最后一個(gè)點(diǎn)和起點(diǎn)的連線(xiàn)垂直于 x 軸，說(shuō)明所有的點(diǎn)已用完。

EC 的難點(diǎn)在于給定起點(diǎn) G 和點(diǎn) K：

K = kG 

想要得到 K(K 足夠大)是一件很困難的事情。這個(gè) K 便是私鑰，而 K=kG 便是公鑰。ECC 是怎么加解密數(shù)據(jù)的呢?

假設(shè)要加密的數(shù)據(jù)為 m，把這個(gè)點(diǎn)當(dāng)作x坐標(biāo)得到在曲線(xiàn)上的一個(gè)點(diǎn) M，取定一個(gè)隨機(jī)數(shù) r，計(jì)算點(diǎn) C1=rG，C2=M+rK。

把這兩個(gè)點(diǎn)便是加密后的數(shù)據(jù)，發(fā)給對(duì)方，對(duì)方收到后使用私鑰 K 進(jìn)行解密，過(guò)程如下：

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

通過(guò)上面的計(jì)算便能還原得到 M，而不知道私鑰 K 的人是無(wú)法解密的。更多細(xì)節(jié)可見(jiàn) Medium 的這篇文章《ECC elliptic curve encryption》。這樣我們便理解了 ECC 的原理，那么怎么利用 ECC 進(jìn)行密鑰交換呢?

ECC 密鑰交換

原理很簡(jiǎn)單，如下圖所示：

 

之前交換的是兩個(gè)冪次方的數(shù)，現(xiàn)在變成交換兩個(gè)曲線(xiàn)上的點(diǎn)。

而曲線(xiàn)方程是規(guī)定好的，例如 Curve X25519 使用的曲線(xiàn)方程為：

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

在密鑰交換里面會(huì)指定所使用的曲線(xiàn)方程，如下圖所示：

 

mozilla.org 所使用的曲線(xiàn)方程為 secp256r1，這個(gè)也是比較流行的一個(gè)，它的參數(shù)比 Curve X25519 大很多。

密鑰交換也使用了證書(shū)的私鑰進(jìn)行簽名，保證交換的密鑰不會(huì)被人篡改，只是這里的私鑰是 mozilla 自己的私鑰。

也就是說(shuō)從連接建立到現(xiàn)在都是明文傳輸?shù)摹＝酉聛?lái)雙方發(fā)送 Change Cipher Spec 的包通知，接下來(lái)的包都按照之前約定好的方式進(jìn)行加密。至此整個(gè)安全連接建立完畢。

HTTPS 證書(shū)的應(yīng)用

那么是誰(shuí)在做 HTTPS 加密呢?服務(wù)端通常是 Nginx、Apache 這些反向代理服務(wù)器做的，而具體的業(yè)務(wù)服務(wù)器不需要處理，客戶(hù)端通常是瀏覽器等做的加解密，Chrome 是使用 boringSSL 這個(gè)庫(kù)，fork 自 openssl。

我們通過(guò) let’s encrypt 可以申請(qǐng)免費(fèi)的 TLS 證書(shū)，每 3 個(gè)月需要手動(dòng)續(xù)。

證書(shū)分為 3 種：DV、OV、EV，DV 適用于個(gè)人，OV 和 EV 需要身份審核，EV 最高端。

EV 證書(shū)會(huì)在瀏覽器的地址欄顯示證書(shū)的企業(yè)名稱(chēng)：

 

但是新版的 Chrome 似乎把這個(gè)去掉了，所以我們打開(kāi) medium 的控制臺(tái)可以看到一個(gè)提示：

As part of an experiment, Chrome temporarily shows only the lock icon in the address bar. Your SSL certificate with Extended Validation is still valid.

另外我們可以用 openssl 生成一個(gè)自簽名證書(shū)，執(zhí)行以下命令：

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

便會(huì)得到兩個(gè)文件，test.com.crt 是證書(shū)，test.com.key 是證書(shū)的私鑰，如下圖所示：

 

然后把這兩個(gè)文件給 Nginx 使用便能使用 HTTPS 訪(fǎng)問(wèn)，如下代碼所示：

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

可以把這個(gè)證書(shū)添加到系統(tǒng)證書(shū)里面，這樣瀏覽器等便能信任，或者直接使用 mkcert 工具一步到位。

客戶(hù)端證書(shū)

還有一種證書(shū)叫客戶(hù)端證書(shū)，同樣需要向 CA 機(jī)構(gòu)申請(qǐng)一個(gè)客戶(hù)端證書(shū)，和服務(wù)端 TLS 證書(shū)不一樣的地方是，服務(wù)端證書(shū)通常是和域名綁定的，而客戶(hù)端證書(shū)可以給本地的任意可執(zhí)行文件進(jìn)行簽名。

簽名驗(yàn)證算法和上文討論的 TLS 證書(shū)一致。為什么可執(zhí)行文件需要簽名呢，因?yàn)槿绻缓灻脑?huà)，系統(tǒng)會(huì)攔截安裝或者運(yùn)行，如 Mac 雙擊一個(gè)未簽名的 dmg 包的提示：

 

直接不讓你運(yùn)行了，而 Windows 也有類(lèi)似的提示，Windows 是會(huì)給一個(gè)警告：

 

而當(dāng)我們運(yùn)行一個(gè)已簽名的 exe 文件將會(huì)是正常的提示，如 Chrome 的提示：

 

綜上本文主要討論了對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密的原理，并介紹了如何利用 RSA 對(duì)證書(shū)簽名的檢驗(yàn)以驗(yàn)證連接服務(wù)器的身份，怎么利用 ECC 進(jìn)行數(shù)據(jù)加密和密鑰交換，介紹了下怎么生成和使用 HTTPS 證書(shū)，并介紹了下客戶(hù)端證書(shū)。

相信看完本篇，會(huì)對(duì) HTTPS 的加解密有一個(gè)較為全面的了解。