大家好，我是小林。

看到一個(gè)賊好笑的網(wǎng)圖：

不開(kāi)玩笑，我來(lái)很認(rèn)真的回答這個(gè)問(wèn)題

這個(gè)問(wèn)題的答案，毫無(wú)疑問(wèn)是會(huì)影響性能。

由裸數(shù)據(jù)傳輸?shù)?HTTP 協(xié)議轉(zhuǎn)成加密數(shù)據(jù)傳輸?shù)?HTTPS 協(xié)議，給應(yīng)用數(shù)據(jù)套了個(gè)「保護(hù)傘」，提高安全性的同時(shí)也帶來(lái)了性能消耗。

因?yàn)?HTTPS 相比 HTTP 協(xié)議多一個(gè) TLS 協(xié)議握手過(guò)程，目的是為了通過(guò)非對(duì)稱(chēng)加密握手協(xié)商或者交換出對(duì)稱(chēng)加密密鑰，這個(gè)過(guò)程最長(zhǎng)可以花費(fèi)掉 2 RTT，接著后續(xù)傳輸?shù)膽?yīng)用數(shù)據(jù)都得使用對(duì)稱(chēng)加密密鑰來(lái)加密/解密。

現(xiàn)在大部分網(wǎng)址都已從 HTTP 遷移至 HTTPS 協(xié)議，所以我們需要考慮的問(wèn)題是：如何優(yōu)化 HTTPS？

這次，就從多個(gè)角度來(lái)優(yōu)化 HTTPS。

分析性能損耗

既然要對(duì) HTTPS 優(yōu)化，那得清楚哪些步驟會(huì)產(chǎn)生性能消耗，再對(duì)癥下藥。

產(chǎn)生性能消耗的兩個(gè)環(huán)節(jié)：

第一個(gè)環(huán)節(jié)， TLS 協(xié)議握手過(guò)程；

第二個(gè)環(huán)節(jié)，握手后的對(duì)稱(chēng)加密報(bào)文傳輸。

對(duì)于第二環(huán)節(jié)，現(xiàn)在主流的對(duì)稱(chēng)加密算法 AES、ChaCha20 性能都是不錯(cuò)的，而且一些 CPU 廠商還針對(duì)它們做了硬件級(jí)別的優(yōu)化，因此這個(gè)環(huán)節(jié)的性能消耗可以說(shuō)非常地小。

而第一個(gè)環(huán)節(jié)，TLS 協(xié)議握手過(guò)程不僅增加了網(wǎng)絡(luò)延時(shí)（最長(zhǎng)可以花費(fèi)掉 2 RTT），而且握手過(guò)程中的一些步驟也會(huì)產(chǎn)生性能損耗，比如：

對(duì)于 ECDHE 密鑰協(xié)商算法，握手過(guò)程中會(huì)客戶(hù)端和服務(wù)端都需要臨時(shí)生成橢圓曲線公私鑰；

客戶(hù)端驗(yàn)證證書(shū)時(shí)，會(huì)訪問(wèn) CA 獲取 CRL 或者 OCSP，目的是驗(yàn)證服務(wù)器的證書(shū)是否有被吊銷(xiāo)；

雙方計(jì)算 Pre-Master，也就是對(duì)稱(chēng)加密密鑰；

為了大家更清楚這些步驟在 TLS 協(xié)議握手的哪一個(gè)階段，我畫(huà)出了這幅圖：

硬件優(yōu)化

玩游戲時(shí)，如果我們?cè)趺炊紤?zhàn)勝不了對(duì)方，那么有一個(gè)最有效、最快的方式來(lái)變強(qiáng)，那就是「充錢(qián)」，如果還是不行，那說(shuō)明你充的錢(qián)還不夠多。

對(duì)于計(jì)算機(jī)里也是一樣，軟件都是跑在物理硬件上，硬件越牛逼，軟件跑的也越快，所以如果要優(yōu)化 HTTPS 優(yōu)化，最直接的方式就是花錢(qián)買(mǎi)性能參數(shù)更牛逼的硬件。

但是花錢(qián)也要花對(duì)方向，HTTPS 協(xié)議是計(jì)算密集型，而不是 I/O 密集型，所以不能把錢(qián)花在網(wǎng)卡、硬盤(pán)等地方，應(yīng)該花在 CPU 上。

一個(gè)好的 CPU，可以提高計(jì)算性能，因?yàn)?HTTPS 連接過(guò)程中就有大量需要計(jì)算密鑰的過(guò)程，所以這樣可以加速 TLS 握手過(guò)程。

另外，如果可以，應(yīng)該選擇可以支持 AES-NI 特性的 CPU，因?yàn)檫@種款式的 CPU 能在指令級(jí)別優(yōu)化了 AES 算法，這樣便加速了數(shù)據(jù)的加解密傳輸過(guò)程。

如果你的服務(wù)器是 Linux 系統(tǒng)，那么你可以使用下面這行命令查看 CPU 是否支持 AES-NI 指令集：

如果我們的 CPU 支持 AES-NI 特性，那么對(duì)于對(duì)稱(chēng)加密的算法應(yīng)該選擇 AES 算法。否則可以選擇 ChaCha20 對(duì)稱(chēng)加密算法，因?yàn)?ChaCha20 算法的運(yùn)算指令相比 AES 算法會(huì)對(duì) CPU 更友好一點(diǎn)。

軟件優(yōu)化

如果公司預(yù)算充足對(duì)于新的服務(wù)器是可以考慮購(gòu)買(mǎi)更好的 CPU，但是對(duì)于已經(jīng)在使用的服務(wù)器，硬件優(yōu)化的方式可能就不太適合了，于是就要從軟件的方向來(lái)優(yōu)化了。

軟件的優(yōu)化方向可以分層兩種，一個(gè)是軟件升級(jí)，一個(gè)是協(xié)議優(yōu)化。

先說(shuō)第一個(gè)軟件升級(jí)，軟件升級(jí)就是將正在使用的軟件升級(jí)到最新版本，因?yàn)?a href="http://m.1cnz.cn/article/zt/" target="_blank">最新版本不僅提供了最新的特性，也優(yōu)化了以前軟件的問(wèn)題或性能。比如：

將 Linux 內(nèi)核從 2.x 升級(jí)到 4.x；

將 OpenSSL 從 1.0.1 升級(jí)到 1.1.1；

...

看似簡(jiǎn)單的軟件升級(jí)，對(duì)于有成百上千服務(wù)器的公司來(lái)說(shuō)，軟件升級(jí)也跟硬件升級(jí)同樣是一個(gè)棘手的問(wèn)題，因?yàn)橐獙?shí)行軟件升級(jí)，會(huì)花費(fèi)時(shí)間和人力，同時(shí)也存在一定的風(fēng)險(xiǎn)，也可能會(huì)影響正常的線上服務(wù)。

既然如此，我們把目光放到協(xié)議優(yōu)化，也就是在現(xiàn)有的環(huán)節(jié)下，通過(guò)較小的改動(dòng)，來(lái)進(jìn)行優(yōu)化。

協(xié)議優(yōu)化

協(xié)議的優(yōu)化就是對(duì)「密鑰交換過(guò)程」進(jìn)行優(yōu)化。

密鑰交換算法優(yōu)化

TLS 1.2 版本如果使用的是 RSA 密鑰交換算法，那么需要 4 次握手，也就是要花費(fèi) 2 RTT，才可以進(jìn)行應(yīng)用數(shù)據(jù)的傳輸，而且 RSA 密鑰交換算法不具備前向安全性。

總之使用 RSA 密鑰交換算法的 TLS 握手過(guò)程，不僅慢，而且安全性也不高。

因此如果可以，盡量選用 ECDHE 密鑰交換算法替換 RSA 算法，因?yàn)樵撍惴ㄓ捎谥С帧窮alse Start」，它是“搶跑”的意思，客戶(hù)端可以在 TLS 協(xié)議的第 3 次握手后，第 4 次握手前，發(fā)送加密的應(yīng)用數(shù)據(jù)，以此將 TLS 握手的消息往返由 2 RTT 減少到 1 RTT，而且安全性也高，具備前向安全性。

ECDHE 算法是基于橢圓曲線實(shí)現(xiàn)的，不同的橢圓曲線性能也不同，應(yīng)該盡量選擇 x25519 曲線，該曲線是目前最快的橢圓曲線。

比如在 Nginx 上，可以使用 ssl_ecdh_curve 指令配置想使用的橢圓曲線，把優(yōu)先使用的放在前面：

對(duì)于對(duì)稱(chēng)加密算法方面，如果對(duì)安全性不是特別高的要求，可以選用 AES_128_GCM，它比 AES_256_GCM 快一些，因?yàn)槊荑€的長(zhǎng)度短一些。

比如在 Nginx 上，可以使用 ssl_ciphers 指令配置想使用的非對(duì)稱(chēng)加密算法和對(duì)稱(chēng)加密算法，也就是密鑰套件，而且把性能最快最安全的算法放在最前面：

TLS 升級(jí)

當(dāng)然，如果可以，直接把 TLS 1.2 升級(jí)成 TLS 1.3，TLS 1.3 大幅度簡(jiǎn)化了握手的步驟，完成 TLS 握手只要 1 RTT，而且安全性更高。

在 TLS 1.2 的握手中，一般是需要 4 次握手，先要通過(guò) Client Hello （第 1 次握手）和 Server Hello（第 2 次握手） 消息協(xié)商出后續(xù)使用的加密算法，再互相交換公鑰（第 3 和 第 4 次握手），然后計(jì)算出最終的會(huì)話密鑰，下圖的左邊部分就是 TLS 1.2 的握手過(guò)程：

上圖的右邊部分就是 TLS 1.3 的握手過(guò)程，可以發(fā)現(xiàn) TLS 1.3 把 Hello 和公鑰交換這兩個(gè)消息合并成了一個(gè)消息，于是這樣就減少到只需 1 RTT 就能完成 TLS 握手。

怎么合并的呢？具體的做法是，客戶(hù)端在 ?Client Hello 消息里帶上了支持的橢圓曲線，以及這些橢圓曲線對(duì)應(yīng)的公鑰。

服務(wù)端收到后，選定一個(gè)橢圓曲線等參數(shù)，然后返回消息時(shí)，帶上服務(wù)端這邊的公鑰。經(jīng)過(guò)這 1 個(gè) RTT，雙方手上已經(jīng)有生成會(huì)話密鑰的材料了，于是客戶(hù)端計(jì)算出會(huì)話密鑰，就可以進(jìn)行應(yīng)用數(shù)據(jù)的加密傳輸了。

而且，TLS1.3 對(duì)密碼套件進(jìn)行“減肥”了，對(duì)于密鑰交換算法，廢除了不支持前向安全性的 ?RSA 和 DH 算法，只支持 ECDHE 算法。

對(duì)于對(duì)稱(chēng)加密和簽名算法，只支持目前最安全的幾個(gè)密碼套件，比如 openssl 中僅支持下面 5 種密碼套件：

TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

TLS_AES_128_GCM_SHA256

TLS_AES_128_CCM_8_SHA256

TLS_AES_128_CCM_SHA256

之所以 TLS1.3 ? 僅支持這么少的密碼套件，是因?yàn)?TLS1.2 由于支持各種古老且不安全的密碼套件，中間人可以利用降級(jí)攻擊，偽造客戶(hù)端的 Client Hello 消息，替換客戶(hù)端支持的密碼套件為一些不安全的密碼套件，使得服務(wù)器被迫使用這個(gè)密碼套件進(jìn)行 HTTPS 連接，從而破解密文。

證書(shū)優(yōu)化

為了驗(yàn)證的服務(wù)器的身份，服務(wù)器會(huì)在 TLS 握手過(guò)程中，把自己的證書(shū)發(fā)給客戶(hù)端，以此證明自己身份是可信的。

對(duì)于證書(shū)的優(yōu)化，可以有兩個(gè)方向：

一個(gè)是證書(shū)傳輸，

一個(gè)是證書(shū)驗(yàn)證；

證書(shū)傳輸優(yōu)化

要讓證書(shū)更便于傳輸，那必然是減少證書(shū)的大小，這樣可以節(jié)約帶寬，也能減少客戶(hù)端的運(yùn)算量。所以，對(duì)于服務(wù)器的證書(shū)應(yīng)該選擇橢圓曲線（ECDSA）證書(shū)，而不是 RSA 證書(shū)，因?yàn)樵谙嗤踩珡?qiáng)度下， ECC 密鑰長(zhǎng)度比 RSA 短的多。

證書(shū)驗(yàn)證優(yōu)化

客戶(hù)端在驗(yàn)證證書(shū)時(shí)，是個(gè)復(fù)雜的過(guò)程，會(huì)走證書(shū)鏈逐級(jí)驗(yàn)證，驗(yàn)證的過(guò)程不僅需要「用 CA 公鑰解密證書(shū)」以及「用簽名算法驗(yàn)證證書(shū)的完整性」，而且為了知道證書(shū)是否被 CA 吊銷(xiāo)，客戶(hù)端有時(shí)還會(huì)再去訪問(wèn) CA， 下載 CRL 或者 OCSP 數(shù)據(jù)，以此確認(rèn)證書(shū)的有效性。

這個(gè)訪問(wèn)過(guò)程是 HTTP 訪問(wèn)，因此又會(huì)產(chǎn)生一系列網(wǎng)絡(luò)通信的開(kāi)銷(xiāo)，如 DNS 查詢(xún)、建立連接、收發(fā)數(shù)據(jù)等。

CRL

CRL 稱(chēng)為證書(shū)吊銷(xiāo)列表（Certificate Revocation List），這個(gè)列表是由 CA 定期更新，列表內(nèi)容都是被撤銷(xiāo)信任的證書(shū)序號(hào)，如果服務(wù)器的證書(shū)在此列表，就認(rèn)為證書(shū)已經(jīng)失效，不在的話，則認(rèn)為證書(shū)是有效的。

但是 CRL 存在兩個(gè)問(wèn)題：

第一個(gè)問(wèn)題，由于 CRL 列表是由 CA 維護(hù)的，定期更新，如果一個(gè)證書(shū)剛被吊銷(xiāo)后，客戶(hù)端在更新 CRL 之前還是會(huì)信任這個(gè)證書(shū)，實(shí)時(shí)性較差；

第二個(gè)問(wèn)題，隨著吊銷(xiāo)證書(shū)的增多，列表會(huì)越來(lái)越大，下載的速度就會(huì)越慢，下載完客戶(hù)端還得遍歷這么大的列表，那么就會(huì)導(dǎo)致客戶(hù)端在校驗(yàn)證書(shū)這一環(huán)節(jié)的延時(shí)很大，進(jìn)而拖慢了 HTTPS 連接。

OCSP

因此，現(xiàn)在基本都是使用 OCSP ，名為在線證書(shū)狀態(tài)協(xié)議（Online Certificate Status Protocol）來(lái)查詢(xún)證書(shū)的有效性，它的工作方式是向 CA 發(fā)送查詢(xún)請(qǐng)求，讓 CA 返回證書(shū)的有效狀態(tài)。

不必像 CRL 方式客戶(hù)端需要下載大大的列表，還要從列表查詢(xún)，同時(shí)因?yàn)榭梢詫?shí)時(shí)查詢(xún)每一張證書(shū)的有效性，解決了 CRL 的實(shí)時(shí)性問(wèn)題。

OCSP 需要向 ?CA 查詢(xún)，因此也是要發(fā)生網(wǎng)絡(luò)請(qǐng)求，而且還得看 ?CA 服務(wù)器的“臉色”，如果網(wǎng)絡(luò)狀態(tài)不好，或者 CA 服務(wù)器繁忙，也會(huì)導(dǎo)致客戶(hù)端在校驗(yàn)證書(shū)這一環(huán)節(jié)的延時(shí)變大。

OCSP Stapling

于是為了解決這一個(gè)網(wǎng)絡(luò)開(kāi)銷(xiāo)，就出現(xiàn)了 OCSP Stapling，其原理是：服務(wù)器向 CA 周期性地查詢(xún)證書(shū)狀態(tài)，獲得一個(gè)帶有時(shí)間戳和簽名的響應(yīng)結(jié)果并緩存它。

當(dāng)有客戶(hù)端發(fā)起連接請(qǐng)求時(shí)，服務(wù)器會(huì)把這個(gè)「響應(yīng)結(jié)果」在 TLS 握手過(guò)程中發(fā)給客戶(hù)端。由于有簽名的存在，服務(wù)器無(wú)法篡改，因此客戶(hù)端就能得知證書(shū)是否已被吊銷(xiāo)了，這樣客戶(hù)端就不需要再去查詢(xún)。

會(huì)話復(fù)用

TLS 握手的目的就是為了協(xié)商出會(huì)話密鑰，也就是對(duì)稱(chēng)加密密鑰，那我們?nèi)绻覀儼咽状?TLS 握手協(xié)商的對(duì)稱(chēng)加密密鑰緩存起來(lái)，待下次需要建立 HTTPS 連接時(shí)，直接「復(fù)用」這個(gè)密鑰，不就減少 TLS 握手的性能損耗了嗎？

這種方式就是會(huì)話復(fù)用（TLS session resumption），會(huì)話復(fù)用分兩種：

第一種叫 Session ID；

第二種叫 Session Ticket；

Session ID

Session ID 的工作原理是，客戶(hù)端和服務(wù)器首次 ?TLS 握手連接后，雙方會(huì)在內(nèi)存緩存會(huì)話密鑰，并用唯一的 Session ID 來(lái)標(biāo)識(shí)，Session ID 和會(huì)話密鑰相當(dāng)于 key-value 的關(guān)系。

當(dāng)客戶(hù)端再次連接時(shí)，hello 消息里會(huì)帶上 Session ID，服務(wù)器收到后就會(huì)從內(nèi)存找，如果找到就直接用該會(huì)話密鑰恢復(fù)會(huì)話狀態(tài)，跳過(guò)其余的過(guò)程，只用一個(gè)消息往返就可以建立安全通信。當(dāng)然為了安全性，內(nèi)存中的會(huì)話密鑰會(huì)定期失效。

但是它有兩個(gè)缺點(diǎn)：

服務(wù)器必須保持每一個(gè)客戶(hù)端的會(huì)話密鑰，隨著客戶(hù)端的增多，服務(wù)器的內(nèi)存壓力也會(huì)越大。

現(xiàn)在網(wǎng)站服務(wù)一般是由多臺(tái)服務(wù)器通過(guò)負(fù)載均衡提供服務(wù)的，客戶(hù)端再次連接不一定會(huì)命中上次訪問(wèn)過(guò)的服務(wù)器，于是還要走完整的 TLS 握手過(guò)程；

Session Ticket

為了解決 Session ID 的問(wèn)題，就出現(xiàn)了 Session Ticket，服務(wù)器不再緩存每個(gè)客戶(hù)端的會(huì)話密鑰，而是把緩存的工作交給了客戶(hù)端，類(lèi)似于 HTTP 的 Cookie。

客戶(hù)端與服務(wù)器首次建立連接時(shí)，服務(wù)器會(huì)加密「會(huì)話密鑰」作為 Ticket 發(fā)給客戶(hù)端，交給客戶(hù)端緩存該 Ticket。

客戶(hù)端再次連接服務(wù)器時(shí)，客戶(hù)端會(huì)發(fā)送 Ticket，服務(wù)器解密后就可以獲取上一次的會(huì)話密鑰，然后驗(yàn)證有效期，如果沒(méi)問(wèn)題，就可以恢復(fù)會(huì)話了，開(kāi)始加密通信。

對(duì)于集群服務(wù)器的話，要確保每臺(tái)服務(wù)器加密 「會(huì)話密鑰」的密鑰是一致的，這樣客戶(hù)端攜帶 Ticket 訪問(wèn)任意一臺(tái)服務(wù)器時(shí)，都能恢復(fù)會(huì)話。

Session ID 和 Session Ticket 都不具備前向安全性，因?yàn)橐坏┘用堋笗?huì)話密鑰」的密鑰被破解或者服務(wù)器泄漏「會(huì)話密鑰」，前面劫持的通信密文都會(huì)被破解。

同時(shí)應(yīng)對(duì)重放攻擊也很困難，這里簡(jiǎn)單介紹下重放攻擊工作的原理。

假設(shè) Alice 想向 Bob 證明自己的身份。Bob 要求 Alice 的密碼作為身份證明，愛(ài)麗絲應(yīng)盡全力提供（可能是在經(jīng)過(guò)如哈希函數(shù)的轉(zhuǎn)換之后）。與此同時(shí)，Eve 竊聽(tīng)了對(duì)話并保留了密碼（或哈希）。

交換結(jié)束后，Eve（冒充 Alice ）連接到 Bob。當(dāng)被要求提供身份證明時(shí)，Eve 發(fā)送從 Bob 接受的最后一個(gè)會(huì)話中讀取的 Alice 的密碼（或哈希），從而授予 Eve 訪問(wèn)權(quán)限。

重放攻擊的危險(xiǎn)之處在于，如果中間人截獲了某個(gè)客戶(hù)端的 Session ID 或 Session Ticket 以及 POST 報(bào)文，而一般 POST 請(qǐng)求會(huì)改變數(shù)據(jù)庫(kù)的數(shù)據(jù)，中間人就可以利用此截獲的報(bào)文，不斷向服務(wù)器發(fā)送該報(bào)文，這樣就會(huì)導(dǎo)致數(shù)據(jù)庫(kù)的數(shù)據(jù)被中間人改變了，而客戶(hù)是不知情的。

避免重放攻擊的方式就是需要對(duì)會(huì)話密鑰設(shè)定一個(gè)合理的過(guò)期時(shí)間。

Pre-shared Key

前面的 Session ID 和 Session Ticket 方式都需要在 1 RTT 才能恢復(fù)會(huì)話。

而 TLS1.3 ?更為牛逼，對(duì)于重連 TLS1.3 只需要 0 RTT，原理和 Ticket 類(lèi)似，只不過(guò)在重連時(shí)，客戶(hù)端會(huì)把 Ticket 和 HTTP 請(qǐng)求一同發(fā)送給服務(wù)端，這種方式叫 Pre-shared Key。

同樣的，Pre-shared Key 也有重放攻擊的危險(xiǎn)。

如上圖，假設(shè)中間人通過(guò)某種方式，截獲了客戶(hù)端使用會(huì)話重用技術(shù)的 POST 請(qǐng)求，通常 POST 請(qǐng)求是會(huì)改變數(shù)據(jù)庫(kù)的數(shù)據(jù)，然后中間人就可以把截獲的這個(gè)報(bào)文發(fā)送給服務(wù)器，服務(wù)器收到后，也認(rèn)為是合法的，于是就恢復(fù)會(huì)話，致使數(shù)據(jù)庫(kù)的數(shù)據(jù)又被更改，但是此時(shí)用戶(hù)是不知情的。

所以，應(yīng)對(duì)重放攻擊可以給會(huì)話密鑰設(shè)定一個(gè)合理的過(guò)期時(shí)間，以及只針對(duì)安全的 HTTP 請(qǐng)求如 GET/HEAD 使用會(huì)話重用。

總結(jié)

對(duì)于硬件優(yōu)化的方向，因?yàn)?HTTPS 是屬于計(jì)算密集型，應(yīng)該選擇計(jì)算力更強(qiáng)的 CPU，而且最好選擇支持 AES-NI 特性的 CPU，這個(gè)特性可以在硬件級(jí)別優(yōu)化 AES 對(duì)稱(chēng)加密算法，加快應(yīng)用數(shù)據(jù)的加解密。

對(duì)于軟件優(yōu)化的方向，如果可以，把軟件升級(jí)成較新的版本，比如將 Linux 內(nèi)核 2.X 升級(jí)成 4.X，將 openssl 1.0.1 升級(jí)到 1.1.1，因?yàn)樾掳姹镜能浖粌H會(huì)提供新的特性，而且還會(huì)修復(fù)老版本的問(wèn)題。

對(duì)于協(xié)議優(yōu)化的方向：

密鑰交換算法應(yīng)該選擇 ECDHE 算法，而不用 RSA 算法，因?yàn)?ECDHE 算法具備前向安全性，而且客戶(hù)端可以在第三次握手之后，就發(fā)送加密應(yīng)用數(shù)據(jù)，節(jié)省了 1 RTT。

將 TLS1.2 升級(jí) TLS1.3，因?yàn)?TLS1.3 的握手過(guò)程只需要 1 RTT，而且安全性更強(qiáng)。

對(duì)于證書(shū)優(yōu)化的方向：

服務(wù)器應(yīng)該選用 ECDSA 證書(shū)，而非 RSA 證書(shū)，因?yàn)樵谙嗤踩?jí)別下，ECC 的密鑰長(zhǎng)度比 RSA 短很多，這樣可以提高證書(shū)傳輸?shù)男剩?/p>

服務(wù)器應(yīng)該開(kāi)啟 OCSP Stapling 功能，由服務(wù)器預(yù)先獲得 OCSP 的響應(yīng)，并把響應(yīng)結(jié)果緩存起來(lái)，這樣 TLS 握手的時(shí)候就不用再訪問(wèn) CA 服務(wù)器，減少了網(wǎng)絡(luò)通信的開(kāi)銷(xiāo)，提高了證書(shū)驗(yàn)證的效率；

對(duì)于重連 HTTPS 時(shí)，我們可以使用一些技術(shù)讓客戶(hù)端和服務(wù)端使用上一次 HTTPS 連接使用的會(huì)話密鑰，直接恢復(fù)會(huì)話，而不用再重新走完整的 TLS 握手過(guò)程。

常見(jiàn)的會(huì)話重用技術(shù)有 Session ID 和 Session Ticket，用了會(huì)話重用技術(shù)，當(dāng)再次重連 HTTPS 時(shí)，只需要 1 RTT 就可以恢復(fù)會(huì)話。對(duì)于 TLS1.3 使用 Pre-shared Key 會(huì)話重用技術(shù)，只需要 0 RTT 就可以恢復(fù)會(huì)話。

這些會(huì)話重用技術(shù)雖然好用，但是存在一定的安全風(fēng)險(xiǎn)，它們不僅不具備前向安全，而且有重放攻擊的風(fēng)險(xiǎn)，所以應(yīng)當(dāng)對(duì)會(huì)話密鑰設(shè)定一個(gè)合理的過(guò)期時(shí)間。

參考資料：

http://www.doc88.com/p-8621583210895.html

https://zhuanlan.zhihu.com/p/33685085

https://en.wikipedia.org/wiki/Replay_attack

https://en.wikipedia.org/wiki/Downgrade_attack

https://www.cnblogs.com/racent-Z/p/14011056.html

http://www.guoyanbin.com/a-detailed-look-at-rfc-8446-a-k-a-tls-1-3/

https://www.thesslstore.com/blog/crl-explained-what-is-a-certificate-revocation-list/

編輯：黃飛

?