聊聊 HTTPS 那些事兒

分享一篇組里面小伙子的文章，歡迎關(guān)注他的公眾號(hào)：
前言

最近在做 CSB 網(wǎng)關(guān)的過(guò)程中，開(kāi)發(fā)了一個(gè)需求，支持 ”TLS 雙向認(rèn)證“。雙向認(rèn)證聽(tīng)起來(lái)比較高級(jí)，其實(shí)也不難，不過(guò)是單向認(rèn)證的“加強(qiáng)版”。單向認(rèn)證是客戶(hù)端認(rèn)證服務(wù)端，而雙向認(rèn)證則是在單向認(rèn)證的基礎(chǔ)上，增加了服務(wù)端認(rèn)證客戶(hù)端這一過(guò)程。

單說(shuō)單向認(rèn)證這個(gè)詞，你可能不是很熟悉，但是提到 HTTPS，應(yīng)該會(huì)恍然大悟吧，經(jīng)典的 HTTPS 協(xié)議中，其實(shí)就是用到了 TLS 單向認(rèn)證。正好借這個(gè)機(jī)會(huì)，我對(duì) HTTPS 也做了一次回顧，整理成一篇文章，供參考。

什么是 HTTPS ？一句話(huà)，HTTPS = HTTP + SSL。HTTPS 并不是一個(gè)全新的協(xié)議，而是在 HTTP 的基礎(chǔ)上，通過(guò) SSL 增加了一層加密協(xié)議，從而大大增加了 HTTP 協(xié)議的安全性。

所以在正式了解 HTTPS 之前，先了解下 HTTP。

1. HTTP

HTTP 全稱(chēng) 超文本傳輸協(xié)議（HyperText Transfer Protocol），是一種廣泛用于互聯(lián)網(wǎng)中瀏覽器與服務(wù)器之間的應(yīng)用層傳輸協(xié)議。簡(jiǎn)單來(lái)說(shuō)，瀏覽器向服務(wù)器發(fā)送 HTTP 請(qǐng)求，服務(wù)器向?yàn)g覽器返回 HTTP 響應(yīng)，兩者之間通過(guò)這種方式進(jìn)行“交流”，來(lái)使得我們的瀏覽器可以正常從服務(wù)器端獲取數(shù)據(jù)，并展示在用戶(hù)的電腦屏幕上。

以訪(fǎng)問(wèn) ?http://httpbin.org 一個(gè)典型的 HTTP 請(qǐng)求如下所示：

      
      GET / HTTP/1.1
Accept: text/html,...
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Host: httpbin.org
Pragma: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36

    

一個(gè)典型的 HTTP 響應(yīng)如下所示

      
      HTTP/1.1 200 OK
Date: Sat, 08 Apr 2023 16:28:43 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 9593
Connection: keep-alive
Server: gunicorn/19.9.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

body...

    

由于本文重點(diǎn)不在 HTTP，這里不詳細(xì)介紹。

2. 為什么需要 HTTPS

上面簡(jiǎn)單講了一下 HTTP。在正式講 HTTPS 之前，首先我們要搞清楚 HTTP 的缺點(diǎn)是什么，為什么需要 HTTPS。

在安全方面，HTTP 的缺點(diǎn)主要在兩個(gè)方面：

1. 明文傳輸。數(shù)據(jù)在傳輸過(guò)程中沒(méi)有任何加密，因此中間的任意一環(huán)都可以竊聽(tīng)到消息內(nèi)容，甚至可以篡改。

2. 客戶(hù)端與服務(wù)端之間沒(méi)有驗(yàn)證機(jī)制，即無(wú)法確認(rèn)對(duì)方的真實(shí)身份。也就是說(shuō)，你并不能確定與你通信的究竟是真正的對(duì)方，還是一個(gè)冒充對(duì)方的“中間人”。

HTTPS 的出現(xiàn)正是為了解決上面兩個(gè)問(wèn)題，其思想類(lèi)似于近代戰(zhàn)場(chǎng)上的電臺(tái)通信。我們知道，戰(zhàn)場(chǎng)上打仗時(shí)，部隊(duì)之間會(huì)通過(guò)電臺(tái)進(jìn)行交流。如果通過(guò)明文進(jìn)行交流，那么非常危險(xiǎn)，敵軍可以打開(kāi)電臺(tái)進(jìn)行竊聽(tīng)，偷取你的軍事情報(bào)，這樣的事也屢見(jiàn)不鮮了...那么他們是如何解決這個(gè)問(wèn)題的？?jī)蓚€(gè)部隊(duì)之間提前約定一個(gè)加密的方案，在傳數(shù)據(jù)之前，先把它進(jìn)行加密再傳輸，另一端收到數(shù)據(jù)之后，按照事先約定的方案進(jìn)行解密，然后讀取就可以了。這樣即使敵軍開(kāi)始竊聽(tīng)，也只能聽(tīng)到加密后的情報(bào)，如果無(wú)法對(duì)其破解的話(huà)，得不到任何有效信息。

沒(méi)錯(cuò)，這就是 HTTPS 的思想，瀏覽器在發(fā)送 HTTP 請(qǐng)求之前，先通過(guò)某種方式對(duì)其進(jìn)行加密，然后再進(jìn)行傳輸。服務(wù)器端收到數(shù)據(jù)之后，對(duì)其解密，讀取真實(shí)內(nèi)容，生成 HTTP 響應(yīng)，同樣對(duì)響應(yīng)進(jìn)行加密，然后傳回給瀏覽器，瀏覽器收到數(shù)據(jù)之后，對(duì)其進(jìn)行解密，得到真正的 HTTP 響應(yīng)。這樣就可以保證數(shù)據(jù)在傳輸過(guò)程中的安全性，無(wú)論是路由器還是運(yùn)營(yíng)商，都沒(méi)有辦法“竊聽(tīng)”數(shù)據(jù)了。

這就引出了 HTTPS 的一大作用，它可以保證數(shù)據(jù)在互聯(lián)網(wǎng)上傳輸?shù)陌踩?，避免中間節(jié)點(diǎn)進(jìn)行竊聽(tīng)和修改。

當(dāng)然，其中還會(huì)存在一些問(wèn)題，例如：

1. 戰(zhàn)場(chǎng)上軍隊(duì)之間是提前約定好加密方案的，但是咱們?nèi)我庖粋€(gè)瀏覽器都可以隨時(shí)訪(fǎng)問(wèn)網(wǎng)頁(yè)，沒(méi)有辦法提前約定加密方案呀，那要怎么做？

2. 戰(zhàn)場(chǎng)上經(jīng)常出現(xiàn)敵軍對(duì)另一方部隊(duì)之間的電臺(tái)加密進(jìn)行破解的事情，破解完成之后，還是能夠竊聽(tīng)到數(shù)據(jù)，那 HTTPS 的這個(gè)加密方案到底安全嗎，會(huì)被破解嗎？

這些問(wèn)題在后面解答。

3. HTTP + SSL = HTTPS ！

上面提到了對(duì) HTTP 進(jìn)行加密的思想。在 HTTPS 的具體實(shí)現(xiàn)中，這個(gè)加密方案即是 SSL（Secure Sockets Layer）。

定義：SSL（Secure Sockets Layer）是一種安全協(xié)議，用于在互聯(lián)網(wǎng)上保護(hù)數(shù)據(jù)的傳輸安全。它工作在傳輸層，主要功能是通過(guò)加密技術(shù)，保護(hù)不同計(jì)算機(jī)之間的數(shù)據(jù)傳輸過(guò)程，防止敏感數(shù)據(jù)被黑客竊取和篡改。SSL 協(xié)議可以用于保護(hù)網(wǎng)站的用戶(hù)登錄、信用卡支付、網(wǎng)上銀行等敏感信息的傳輸，以及企業(yè)之間的機(jī)密數(shù)據(jù)的傳輸。SSL 協(xié)議目前已經(jīng)被繼承為 TLS（Transport Layer Security），是一種安全性更高的傳輸層協(xié)議。所以，下面我將統(tǒng)一以 TLS 為名稱(chēng)進(jìn)行講解。

首先，劃重點(diǎn)，TLS 中有 Transport Layer，顧名思義，它一定是工作在傳輸層了。TLS 基于 TCP 協(xié)議，我們知道，TCP 協(xié)議里有三次握手，三次握手成功后連接才算建立，接下來(lái)才會(huì)真正開(kāi)始傳輸數(shù)據(jù)。傳統(tǒng)的 HTTP 協(xié)議中，三次握手成功之后，就會(huì)直接開(kāi)始明文傳輸 HTTP 數(shù)據(jù)了。

那么 TLS 是什么時(shí)候開(kāi)始發(fā)揮作用的呢？答案很簡(jiǎn)單，在三次握手之后，傳輸數(shù)據(jù)之前。也就是說(shuō)，在 TCP 協(xié)議中加入 TLS 之后，三次握手成功之后就不會(huì)再立刻開(kāi)始傳輸數(shù)據(jù)了，而是緊接著開(kāi)始 TLS 的建立過(guò)程，也被稱(chēng)為 TLS 握手。

TLS 的目的是什么？上面提到，在戰(zhàn)場(chǎng)上，兩個(gè)部隊(duì)之間會(huì)提前約定好加密的方案，例如面對(duì)面用紙互相寫(xiě)下加密方案，然后在一段時(shí)間之內(nèi)的電臺(tái)通信統(tǒng)一用這個(gè)加密方案，這樣能一定程度上保證電臺(tái)通信的安全性。但是 TLS 中我們并沒(méi)有這樣一個(gè)“面對(duì)面”的機(jī)會(huì)，咱們總不可能在訪(fǎng)問(wèn)網(wǎng)頁(yè)之前，人肉跑到服務(wù)器的維護(hù)者那邊去跟他約定加密方案吧。出于這個(gè)目的，TLS 握手便出現(xiàn)了。所以我們可以說(shuō)，TLS 握手的目的是給通信雙方約定一個(gè)安全的加密方案（可以理解為商量一個(gè)只有雙方知道的加密密鑰）。

知道了 TLS 握手的目的，接下來(lái)我們需要知道它具體是怎么做的。首先，我們肯定不能直接明文傳輸加密方案（密鑰），不然這個(gè)密鑰在傳輸過(guò)程中就直接被第三方獲取了，那么加密將沒(méi)有任何意義。也就是說(shuō)，TLS 握手需要做到：通信雙方可以約定一個(gè)共同的加密方案（密鑰），并且這個(gè)約定的過(guò)程（即 TLS 握手過(guò)程），即使被任何第三方竊聽(tīng)到，也無(wú)法解析出這個(gè)加密方案（密鑰）。

是不是聽(tīng)起來(lái)很神奇，到底是怎么做到？其實(shí)只要用到密碼學(xué)中非常經(jīng)典的兩個(gè)概念：對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密。

4. 對(duì)稱(chēng)加密，非對(duì)稱(chēng)加密

對(duì)稱(chēng)加密是 TLS 握手成功后，通信雙方之間采用的數(shù)據(jù)加密方案?，F(xiàn)在的主要問(wèn)題是：通信雙方如何安全的商量好這個(gè)對(duì)稱(chēng)密鑰，防止密鑰被其他人竊??？

這時(shí)就需要輪到非對(duì)稱(chēng)加密出場(chǎng)了。什么是非對(duì)稱(chēng)加密？與對(duì)稱(chēng)加密不同，非對(duì)稱(chēng)加密方案中，用戶(hù)手握兩把密鑰，一把稱(chēng)為公鑰，一把稱(chēng)為私鑰，其中公/私鑰都可以用來(lái)加密/解密數(shù)據(jù)，但是：用公鑰加密后的數(shù)據(jù)，只有用私鑰才能將其解開(kāi)；用私鑰加密后的數(shù)據(jù)，只有用公鑰才能將其解開(kāi)！

這里只介紹了非對(duì)稱(chēng)加密的特點(diǎn)，并沒(méi)有介紹其原理，因?yàn)檫@屬于密碼學(xué)的范疇了，展開(kāi)來(lái)講又是一篇文章。簡(jiǎn)單說(shuō)說(shuō)其思想吧，目前流行的非對(duì)稱(chēng)加密算法 RSA 基于的原理其實(shí)就一句話(huà)：我們目前還沒(méi)有很好的辦法對(duì)一個(gè)很大的數(shù)做因式分解，例如你在心里默默想一個(gè)很大的質(zhì)數(shù) p 和 質(zhì)數(shù) q，算出其乘積 n，那么向外公開(kāi) n 的話(huà)，外部人員是很難找出 p 和 q 的（只能暴力嘗試，而當(dāng)這樣的數(shù)夠大夠多的時(shí)候，以現(xiàn)在的計(jì)算機(jī)算力也需要幾百上千年的時(shí)間才能破解了，這也是加密的安全所在）。

有了非對(duì)稱(chēng)加密，事情就變得有意思起來(lái)了。見(jiàn)下圖，服務(wù)器端用非對(duì)稱(chēng)加密方案生成一對(duì)公/私鑰，私鑰掌握在自己手里，誰(shuí)也不告訴；在 TLS 握手的過(guò)程中，服務(wù)器將自己的公鑰交給瀏覽器端，瀏覽器端在心里默默想出一個(gè)對(duì)稱(chēng)加密的密鑰后，將這個(gè)密鑰用服務(wù)器端的公鑰進(jìn)行加密，然后再傳回給服務(wù)器端；服務(wù)器端收到這個(gè)數(shù)據(jù)之后，用自己的私鑰將其進(jìn)行解密，就能夠得到剛才瀏覽器心里默念的那個(gè)對(duì)稱(chēng)密鑰了。

這樣一來(lái)，這個(gè)問(wèn)題就完美的解決了，兩邊可以心有靈犀的拿到這個(gè)對(duì)稱(chēng)密鑰，而不用擔(dān)心被任何第三方竊取到了。

這就是 TLS 握手的過(guò)程嗎？不，當(dāng)然沒(méi)這么簡(jiǎn)單了，我們還沒(méi)有考慮一個(gè)非常巧妙的攻擊手段：中間人攻擊。

5. 中間人攻擊

什么是中間人攻擊？看下面這張圖

假設(shè)現(xiàn)在我們從電腦上訪(fǎng)問(wèn)百度，如果有一個(gè)中間人在我的路由器端，或者運(yùn)營(yíng)商端，或者任何一個(gè)中間節(jié)點(diǎn)上截取了我的請(qǐng)求，剛不是提到服務(wù)器端需要返回給我們公鑰嗎，中間人他自己也生成一套公/私鑰，然后將自己的公鑰返回給我，這樣我就與中間人之間建立了一條我以為“安全”的連接了，此時(shí)我以為我連接的是百度服務(wù)器，其實(shí)我連接的是中間人...那么此時(shí)中間人可以做任何事情了，如果他人品比較好的話(huà)，他可以默默當(dāng)一個(gè)代理，我要訪(fǎng)問(wèn)百度，他就去幫我訪(fǎng)問(wèn)百度，然后把結(jié)果返回給我，勤勤懇懇做一個(gè)“中間商”。當(dāng)然，我們知道做這種攻擊的人人品往往不會(huì)太好，所以他們可以做更壞的事情，例如偽造一個(gè)銀行網(wǎng)頁(yè)返回給我，讓我填寫(xiě)賬號(hào)和密碼，這樣的話(huà)...后果就不堪設(shè)想了。

那么如何防止中間人攻擊呢？其中的核心就是：我們需要保證我們?cè)L問(wèn)的就是目標(biāo)服務(wù)器，例如，當(dāng)我們?cè)L問(wèn)百度時(shí)，我們需要確保在 TLS 握手時(shí)，給我們公鑰的人就是百度，而不是任何其他人。

那么這個(gè)應(yīng)該如何去保證呢？這就不得不提到接下來(lái)的幾個(gè)概念了，數(shù)字證書(shū)，以及證書(shū)權(quán)威機(jī)構(gòu)（Certificate Authority，簡(jiǎn)稱(chēng) CA）。

6. 數(shù)字證書(shū)、CA

數(shù)字證書(shū)是由證書(shū)權(quán)威機(jī)構(gòu)（CA）頒發(fā)的一個(gè)用于證明身份的證書(shū)，當(dāng)然其中還包含了該用戶(hù)的公鑰等信息。例如還是以百度為例，假設(shè)百度需要給 www.baidu.com這個(gè)域名申請(qǐng)一個(gè)數(shù)字證書(shū)，他需要在生成公鑰/私鑰后，將自身的信息（包括域名、公司名稱(chēng)、公鑰信息等）發(fā)給某個(gè)證書(shū)權(quán)威機(jī)構(gòu)（CA），讓 CA 給自己頒發(fā)一個(gè)數(shù)字證書(shū)。CA 需要驗(yàn)證百度的真實(shí)身份，并且他確實(shí)擁有 www.baidu.com這個(gè)域名，一切都驗(yàn)證通過(guò)后，CA 才會(huì)給百度頒發(fā)這么一個(gè)數(shù)字證書(shū)。那么之后，不管是誰(shuí)用瀏覽器訪(fǎng)問(wèn) www.baidu.com的時(shí)候，百度都會(huì)將剛才那個(gè) CA 頒發(fā)的數(shù)字證書(shū)發(fā)送給用戶(hù)，既可以用來(lái)自證身份，同時(shí)還順便告訴了用戶(hù)自己的公鑰。

到這里又引出幾個(gè)問(wèn)題：

1. 數(shù)字證書(shū)如何保證不能偽造呢，難道中間人不能偽造一個(gè)數(shù)字證書(shū)發(fā)送給用戶(hù)嗎？

2. 即使數(shù)字證書(shū)不能被偽造，從概念上看他是公開(kāi)的，難道中間人不能直接把這個(gè)證書(shū)頒發(fā)給用戶(hù)嗎？

下面會(huì)一一回答這幾個(gè)問(wèn)題。正式回答之前，先來(lái)看看數(shù)字證書(shū)里究竟有哪些內(nèi)容。

既然上面提到百度，我們就以百度為例，我們使用瀏覽器訪(fǎng)問(wèn)百度，可以在地址欄左邊看到一個(gè)小鎖，點(diǎn)擊后，就可以查看百度的數(shù)字證書(shū)

image-20230428174323783

圖中可以看到該證書(shū)的一些基本信息：

• 頒發(fā)對(duì)象：這個(gè)證書(shū)是頒發(fā)給百度的，并且只對(duì)域名 (www.)baidu.com 有效

• 頒發(fā)者：這個(gè)證書(shū)是由 GlobalSign 頒發(fā)的。（GlobalSign是一家全球知名的證書(shū)權(quán)威機(jī)構(gòu)）

• 有效期：這個(gè)證書(shū)的有效期是從 2022 年 7 月到 2023 年 8 月。（一旦過(guò)期，證書(shū)將不被信任）

• 指紋：指紋是整張證書(shū)經(jīng)過(guò)哈希計(jì)算后得到的特征值，主要與后面會(huì)提到的簽名一起工作，起到防篡改的作用

當(dāng)然，一張數(shù)字證書(shū)的內(nèi)容遠(yuǎn)遠(yuǎn)不止于此，例如還包含了服務(wù)器的公鑰，可以在“詳細(xì)信息”中進(jìn)行查看。

下面我們?cè)谧C書(shū)詳細(xì)信息中點(diǎn)擊“導(dǎo)出”，將證書(shū)導(dǎo)出為 Base64 編碼的單一證書(shū)，然后使用 openssl 對(duì)其進(jìn)行解析和查看

      
      $?openssl?x509?-noout?-text?-in?baidu.com.cer
Certificate:
????Data:
????????Version:?3?(0x2)
????????Serial?Number:
????????????44:17:ce:86:ef:82:ec:69:21:cc:6f:68
????Signature?Algorithm:?sha256WithRSAEncryption
????????Issuer:?C=BE,?O=GlobalSign?nv-sa,?CN=GlobalSign?RSA?OV?SSL?CA?2018
????????Validity
????????????Not?Before:?Jul??5?05:16:02?2022?GMT
????????????Not?After?:?Aug??6?05:16:01?2023?GMT
????????Subject:?C=CN,?ST=beijing,?L=beijing,?OU=service?operation?department,?O=Beijing?Baidu?Netcom?Science?Technology?Co.,?Ltd,?CN=baidu.com
????????Subject?Public?Key?Info:
????????????Public?Key?Algorithm:?rsaEncryption
????????????????RSA?Public-Key:?(2048?bit)
????????????????Modulus:
????????????????????00:aa:2f:cc:41:8d:25:ae:83:e9:f4:27:c4:00:b3:
????????????????????39:6f:0e:98:2a:55:7d:07:e5:80:49:82:fa:d3:d3:
????????????????????85:98:b5:df:7b:6f:bb:02:dd:ed:78:e4:0c:07:2b:
????????????????????9e:1e:86:4b:f6:6a:86:58:d7:57:6f:21:59:11:d8:
????????????????????6f:96:6e:d2:de:36:28:f6:b4:e3:ce:95:32:29:00:
????????????????????c1:65:8e:69:b0:00:fe:52:37:f4:88:3f:8b:6d:0f:
????????????????????bb:f0:ec:c5:c0:31:ef:ad:b5:0c:06:66:ad:be:dc:
????????????????????43:13:c4:66:b0:5d:cf:56:53:e2:d1:96:82:1c:06:
????????????????????bb:9b:5f:ed:60:8d:d2:ed:f3:d2:50:ee:bb:cd:b2:
????????????????????36:97:c8:ce:7b:d2:4b:b7:5c:b4:88:ca:37:6e:8b:
????????????????????ce:f9:96:fd:b4:f5:47:b5:20:77:bb:fc:a8:9d:81:
????????????????????b2:6c:f8:c7:09:6a:dd:22:6e:83:3f:a7:53:df:f1:
????????????????????da:2f:29:6b:22:c3:e9:1d:65:e8:c5:a0:ba:13:4e:
????????????????????16:3f:03:93:f0:a5:59:8a:1a:80:e8:27:7d:49:23:
????????????????????df:d1:f9:4b:97:b7:01:c4:19:f5:f1:c5:ff:91:33:
????????????????????d0:a1:74:c6:ee:d4:cf:f6:38:0c:ed:bd:5e:aa:44:
????????????????????fb:88:f7:7b:99:70:76:34:55:7e:55:d2:0f:9e:bf:
????????????????????94:93
????????????????????
????...?(中間省略）
???
????Signature?Algorithm:?sha256WithRSAEncryption
?????????63:21:07:23:47:06:eb:b3:7c:77:6c:df:bc:55:12:b9:f1:5e:
?????????6a:04:60:16:be:d0:0b:18:9c:94:0c:a8:82:08:25:0d:26:fb:
?????????dd:cb:fc:8c:27:d9:0c:fa:4a:b6:31:b6:67:f0:26:2c:0d:96:
?????????96:39:65:3f:d9:a1:ee:de:9c:10:4d:54:e1:c8:d6:a9:0e:77:
?????????db:00:e2:37:e3:3f:b4:9c:31:4f:ac:74:d3:22:12:53:36:d0:
?????????ef:18:07:2d:8e:d0:e6:91:b2:6c:4a:5e:39:53:14:58:4e:d1:
?????????50:04:c9:83:7e:0d:7b:15:96:87:11:d7:5d:4a:17:ac:aa:9f:
?????????84:e3:a8:24:9d:d6:17:77:26:8c:9f:7a:7b:18:da:39:2f:77:
?????????f7:2b:c7:23:b8:97:6f:c3:d1:72:4c:7e:fc:c6:0d:cc:73:38:
?????????19:81:fb:e7:c1:7a:e8:b9:1d:3a:05:dc:36:04:9b:f1:f0:e1:
?????????a6:47:a0:30:4f:55:90:6c:da:cf:9e:b2:76:12:11:a1:5c:b6:
?????????61:8d:15:a4:68:65:9a:57:2f:7a:6e:a3:1f:f5:b4:92:5a:3c:
?????????df:71:0a:cd:57:d4:d0:15:36:7e:ba:d5:03:25:27:45:b4:60:
?????????cd:2e:02:c1:0f:0a:e7:41:6f:58:69:20:9e:ad:47:52:1a:b5:
?????????e6:e5:8d:1d

    

可以看到，除了上面 Chrome 里顯示的一些基本信息外，證書(shū)里還包含了幾個(gè)重要信息：

• 服務(wù)器端的公鑰，即上面 RSA Public-Key 下面的那一長(zhǎng)串?dāng)?shù)字，就是百度的公鑰了。

• 簽名，證明數(shù)字證書(shū)有效的關(guān)鍵信息。如果把數(shù)字證書(shū)類(lèi)比成一張合同的話(huà)，我們知道合同需要老板簽字才算有效，同樣，數(shù)字證書(shū)是需要 CA 簽名才算有效的，這里的一長(zhǎng)串字符就是 CA 對(duì)該證書(shū)的“簽名”了。

我們知道合同上的簽名是靠筆跡鑒定來(lái)確認(rèn)真?zhèn)蔚?，很明顯這一長(zhǎng)串字符里沒(méi)有筆跡，那它是如何保證該簽名是 CA 頒發(fā)的，而不是被其他人偽造的呢？

上面我們提到，每一張數(shù)字證書(shū)有一個(gè)指紋，是將整張證書(shū)經(jīng)過(guò)哈希運(yùn)算后得到的特征值。CA 作為權(quán)威機(jī)構(gòu)，其本身也是有一對(duì)公鑰/私鑰的，它在頒發(fā)數(shù)字證書(shū)的時(shí)候，會(huì)用自己的私鑰對(duì)證書(shū)的指紋進(jìn)行加密，生成的這段加密數(shù)據(jù)，就是該證書(shū)的簽名了！那么我們?yōu)g覽器是如何驗(yàn)證證書(shū)的真?zhèn)文?？我們只需要使?CA 的公鑰對(duì)簽名進(jìn)行解密，看看得到的值是不是跟證書(shū)的指紋是一樣的，這樣就 OK 了，只要是一樣，說(shuō)明這個(gè)證書(shū)一定是 CA 頒發(fā)的。

那么，又有問(wèn)題來(lái)了：我們?yōu)g覽器是從哪里拿到 CA 的公鑰呢？總不能還是通過(guò)網(wǎng)絡(luò)傳輸吧，這樣就有“套娃”的中間人攻擊風(fēng)險(xiǎn)了。所以，我們的瀏覽器或操作系統(tǒng)已經(jīng)內(nèi)置了世界權(quán)威的 CA 的數(shù)字證書(shū)（證書(shū)里就包含了其公鑰）了，點(diǎn)擊瀏覽器的 設(shè)置 -> 隱私設(shè)置和安全性 -> 安全 -> 管理設(shè)備證書(shū)，可以查看當(dāng)前系統(tǒng)內(nèi)置的所有 CA 證書(shū)。

上圖是我的電腦中內(nèi)置的 CA 證書(shū)。剛剛提到了百度的數(shù)字證書(shū)是由 GlobalSign 頒發(fā)的，這里也可以驗(yàn)證，GlobalSign 是被我們的操作系統(tǒng)所信任的 CA，并且我們已經(jīng)將它的證書(shū)內(nèi)置在操作系統(tǒng)中了。因此現(xiàn)在我們可以認(rèn)定說(shuō)，這個(gè)證書(shū)是值得信任的，與我們建立連接的就是百度，不是別人。

你可能會(huì)想，如果中間人將百度真實(shí)的數(shù)字證書(shū)返回給我呢？中間人是沒(méi)有百度的私鑰的，所以當(dāng)我們提取出證書(shū)中的公鑰，并對(duì)心里想的密鑰進(jìn)行加密后，中間人是解不開(kāi)這個(gè)密鑰的，所以中間人無(wú)論如何也無(wú)法與我們建立連接。

好了，數(shù)字證書(shū)的內(nèi)容已經(jīng)全部講述完畢了，最后回過(guò)頭來(lái)回答下前面提到的兩個(gè)問(wèn)題：

1. 數(shù)字證書(shū)如何保證自身不會(huì)被偽造？

數(shù)字證書(shū)中有一段簽名，該簽名是 CA 使用其私鑰對(duì)證書(shū)指紋進(jìn)行加密后得到的值，我們?yōu)g覽器使用 CA 的公鑰對(duì)該簽名進(jìn)行解密后，與該證書(shū)的指紋進(jìn)行對(duì)比，就可以知道證書(shū)是否被篡改或者偽造了。

當(dāng)然，這里要多提一嘴，我們作為客戶(hù)端，需要保證自己的電腦里保存的都是值得信任的 CA 根證書(shū)，因?yàn)樾湃文?CA 就代表信任了該 CA 頒發(fā)的所有數(shù)字證書(shū)，如果有人/軟件想在你的電腦里安裝來(lái)歷不明的 CA 證書(shū)，那你就要保持警惕了...

1. 如果中間人直接把真實(shí)的數(shù)字證書(shū)返回給我，它能夠成功與我建立連接嗎？

答案是不行的。這個(gè)問(wèn)題其實(shí)比較簡(jiǎn)單，剛剛提到，服務(wù)器端除了公鑰外，自身還保存有一份私鑰的，而中間人是拿不到這個(gè)私鑰的...那么如果中間人用服務(wù)器的證書(shū)返回給用戶(hù)，用戶(hù)采用服務(wù)器的公鑰對(duì)自身默念出來(lái)的對(duì)稱(chēng)密鑰進(jìn)行加密后，返回給中間人的時(shí)候，中間人就一臉懵逼了，因?yàn)檫@個(gè)密鑰它解不開(kāi)呀，它沒(méi)有私鑰的，所以這個(gè)問(wèn)題就完美解決了。

7. TLS 握手具體過(guò)程

最后，我們?cè)偻晖暾v一下 TLS 握手的具體流程。

上圖來(lái)自 www.ssl.com，展示了整個(gè)握手流程，用大白話(huà)解釋一下：

1. 客戶(hù)端向服務(wù)器發(fā)送 Client Hello 信息，告知自己想要建立一條 TLS 連接，并告知自己支持的加密算法。

2. 服務(wù)器向客戶(hù)端發(fā)送一個(gè) Server Hello 的回應(yīng)，并選擇一個(gè)加密算法，同時(shí)給客戶(hù)端發(fā)送自己的數(shù)字證書(shū)（包含服務(wù)器的公鑰）。

3. 客戶(hù)端驗(yàn)證服務(wù)器發(fā)來(lái)的數(shù)字證書(shū)，驗(yàn)證通過(guò)后，在心里默默想出一個(gè) pre-master 密鑰（預(yù)主密鑰），然后使用服務(wù)器的公鑰，將預(yù)主密鑰進(jìn)行加密后，發(fā)送給服務(wù)器。

4. 服務(wù)器用自己的私鑰進(jìn)行解密，得到預(yù)主密鑰。

5. 客戶(hù)端和服務(wù)器都通過(guò)預(yù)主密鑰，進(jìn)行相同的計(jì)算后，得到后續(xù)通信時(shí)使用的對(duì)稱(chēng)加密密鑰，稱(chēng)為 shared secret。

6. 客戶(hù)端和服務(wù)器端都分別用生成的 shared-secret 加密一段報(bào)文后，發(fā)送給對(duì)方，以驗(yàn)證對(duì)方能夠成功收到信息并解密。

7. 然后 TLS 就建立成功了，接下來(lái)雙方都用這個(gè) shared-secret 進(jìn)行加密通信。

總結(jié)一下，HTTPS 的加密過(guò)程中其實(shí)既用到了非對(duì)稱(chēng)加密也用到了對(duì)稱(chēng)加密，其中握手過(guò)程使用的是非對(duì)稱(chēng)加密，主要目的是雙方可以安全的協(xié)商一個(gè)統(tǒng)一的密鑰，而真正的數(shù)據(jù)傳輸過(guò)程則使用的是對(duì)稱(chēng)加密，對(duì)稱(chēng)加密使用握手過(guò)程中商量的密鑰。

那么為什么不全程使用非對(duì)稱(chēng)加密呢？因?yàn)閷?duì)稱(chēng)加密效率更高，尤其是在大量數(shù)據(jù)的時(shí)候，對(duì)稱(chēng)加密比非對(duì)稱(chēng)加密整整快幾個(gè)數(shù)量級(jí)，所以真正數(shù)據(jù)傳輸?shù)倪^(guò)程選用了對(duì)稱(chēng)加密。

到這里，HTTPS 的原理就已經(jīng)全部介紹完畢了。

8. 總結(jié)

總結(jié)一下，HTTPS 解決了兩個(gè)問(wèn)題：

1. 數(shù)據(jù)傳輸過(guò)程中的安全問(wèn)題，因?yàn)樗鼘?duì)數(shù)據(jù)進(jìn)行了加密，只有瀏覽器和服務(wù)器可以對(duì)其進(jìn)行解密。

2. 瀏覽器對(duì)服務(wù)器的信任問(wèn)題，數(shù)字證書(shū)以及其中的數(shù)字簽名，保證了我們?cè)L問(wèn)的就是我們想要訪(fǎng)問(wèn)的服務(wù)器，不可能被釣魚(yú)網(wǎng)站或者中間人所欺騙。

當(dāng)然，保證以上安全的前提是我們的電腦本身沒(méi)有被攻破，如果你的電腦被黑客攻擊，裝上了來(lái)歷不明的根證書(shū)，那么 HTTPS 也不能保障你的安全了。

- END -