“ 本篇文章主要講解了TLS通訊協(xié)議，為什么要禁用會(huì)話協(xié)商和壓縮功能”

禁用TLS會(huì)話重協(xié)商和TLS壓縮功能的主要目的是為了提高安全性，防止?jié)撛诘陌踩┒幢焕谩?

01 禁用TLS會(huì)話重協(xié)商

1  禁用TLS會(huì)話重協(xié)商：

防止拒絕服務(wù)攻擊：會(huì)話重協(xié)商需要服務(wù)器端的非等比資源，這使其成為拒絕服務(wù)攻擊的潛在媒介。通過(guò)限制每十分鐘重新協(xié)商的次數(shù)為三次，可以降低這種風(fēng)險(xiǎn)。

防止中間人攻擊：客戶端發(fā)起的重協(xié)商攻擊允許攻擊者在已經(jīng)加密的連接上重新協(xié)商會(huì)話參數(shù)，從而可能插入非法數(shù)據(jù)到客戶端和服務(wù)器的安全連接中。完全禁用或嚴(yán)格控制重協(xié)商可以有效防止這種情況

重協(xié)商的安全漏洞原理

客戶端首先發(fā)出一個(gè)ClientHello1，客戶端期待進(jìn)行首次協(xié)商。(注意：客戶端認(rèn)為ClientHello1是首次協(xié)商)

中間人收到ClientHello1之后，按理說(shuō)它應(yīng)該將其轉(zhuǎn)發(fā)給服務(wù)器。但是中間人這時(shí)決定“作惡”，將ClientHello1緩存起來(lái)暫不轉(zhuǎn)發(fā)。中間人自己構(gòu)造一個(gè)ClientHello2，對(duì)服務(wù)器發(fā)起首次協(xié)商，協(xié)商好后中間人將精心偽造的數(shù)據(jù)發(fā)送給服務(wù)器。(注意：服務(wù)器認(rèn)為ClientHello2是首次協(xié)商)

服務(wù)器收到這些數(shù)據(jù)，會(huì)認(rèn)為這是正常的數(shù)據(jù)。因?yàn)榉?wù)器的APP程序通常需要處理粘包，所以中間人如果了解APP協(xié)議(如HTTPS)的話，則會(huì)精心構(gòu)造不完整的數(shù)據(jù)，讓服務(wù)器的APP程序認(rèn)為發(fā)生粘包，將數(shù)據(jù)暫緩不處理，繼續(xù)等待后續(xù)的數(shù)據(jù)上來(lái)。

這時(shí)，中間人調(diào)出之前暫緩的ClientHello1，將其在同一個(gè)SSL/TLS TCP連接中，發(fā)送給服務(wù)器。(注意：ClientHello1消息本身是加密的，因?yàn)槠涫窃贑lientHello2協(xié)商好后的加密SSL/TLS連接中傳輸)

服務(wù)器收到ClientHello1后，認(rèn)為這是一次重協(xié)商，協(xié)商好后，客戶端發(fā)送真正的數(shù)據(jù)給服務(wù)器。

服務(wù)器的APP程序，收到客戶端的真正數(shù)據(jù)后，將其與之前緩存的中間人精心構(gòu)造的數(shù)據(jù)粘合起來(lái)，進(jìn)行業(yè)務(wù)處理。

從而，中間人在不需要劫持、解密SSL/TLS連接的情況下，成功地將自己偽造的數(shù)據(jù)插入到用戶真正數(shù)據(jù)之前。這個(gè)安全漏洞可以讓心機(jī)卓絕的中間人做好多事情，比如偽造一個(gè)HTTP GET消息，然后用HTTP的IGNORE字段屏蔽掉真正數(shù)據(jù)的HTTP GET頭，但是卻保留了用戶的cookie信息，從而利用用戶的cookie去訪問(wèn)網(wǎng)站內(nèi)容，比如可能利用此法刪掉用戶之前發(fā)的帖子等。

這個(gè)漏洞成因在于，客戶端認(rèn)為的首次協(xié)商卻被服務(wù)器認(rèn)為是重協(xié)商，以及首次協(xié)商和重協(xié)商之間缺少關(guān)聯(lián)性。RFC 5746引入明確首次協(xié)商與重協(xié)商的方法，以及確認(rèn)首次協(xié)商和重協(xié)商的關(guān)聯(lián)性校驗(yàn)，從而確保中間人的攻擊行為可以被識(shí)別并拒絕，保證重協(xié)商安全。

客戶端發(fā)起ClientHello1。

中間人緩存ClientHello1，精心構(gòu)造ClientHello2，與服務(wù)器進(jìn)行首次協(xié)商。這里假設(shè)中間人在ClientHello2中不攜帶安全重協(xié)商標(biāo)識(shí)。

中間人與服務(wù)器協(xié)商成功，發(fā)送偽造的數(shù)據(jù)給服務(wù)器。

中間人將之前緩存的ClientHello1發(fā)送給服務(wù)器。

如果服務(wù)器禁止重協(xié)商，則這時(shí)看到ClientHello1，會(huì)認(rèn)為發(fā)生了重協(xié)商，不允許，所以中斷連接。

如果服務(wù)器禁止不安全的重協(xié)商、但允許安全的重協(xié)商，則因?yàn)橹爸虚g人構(gòu)造的首次協(xié)商消息ClientHello2中指示不支持安全重協(xié)商，所以現(xiàn)在收到ClientHello1認(rèn)為發(fā)生了不安全的重協(xié)商，所以中斷連接。

因此，這種情況以及各種子情景都沒(méi)有問(wèn)題，不會(huì)有安全漏洞。

客戶端發(fā)起ClientHello1。

中間人緩存ClientHello1，精心構(gòu)造ClientHello2，與服務(wù)器進(jìn)行首次協(xié)商。這里假設(shè)中間人在ClientHello2中攜帶支持安全重協(xié)商標(biāo)識(shí)。

中間人與服務(wù)器協(xié)商成功，發(fā)送偽造的數(shù)據(jù)給服務(wù)器。在這時(shí)，因?yàn)殡p方都支持安全重協(xié)商，所以服務(wù)器會(huì)要求中間人將服務(wù)器發(fā)送的Finish消息中的首次協(xié)商會(huì)話摘要信息記錄下來(lái)，以便重協(xié)商時(shí)再帶給服務(wù)器；當(dāng)然，服務(wù)器自己也會(huì)將這個(gè)首次協(xié)商會(huì)話摘要信息記錄到自己的內(nèi)存中)

中間人將之前緩存的ClientHello1發(fā)送給服務(wù)器。

如果服務(wù)器禁止不安全的重協(xié)商、但是允許安全的重協(xié)商，且如果ClientHello1中支持安全重協(xié)商，則按照RFC 5746是不合理的，只有首次協(xié)商ClientHello才允許帶有支持安全重協(xié)商標(biāo)識(shí)，重協(xié)商階段的ClientHello是不允許攜帶該標(biāo)識(shí)的。所以，服務(wù)器認(rèn)為可能是遇到攻擊，中斷連接。

如果服務(wù)器禁止不安全的重協(xié)商、但是允許安全的重協(xié)商，且如果ClientHello1中不攜帶支持安全重協(xié)商標(biāo)識(shí)，則服務(wù)器會(huì)認(rèn)為這是正常的重協(xié)商。然后，服務(wù)器會(huì)提取出前邊第3步中記錄的首次協(xié)商會(huì)話摘要信息，按照RFC 5746，ClientHello1中應(yīng)該帶有相同的這個(gè)首次協(xié)商會(huì)話摘要信息。但是，一方面客戶端的ClientHello1是不可能帶有這個(gè)信息的，所以服務(wù)器校驗(yàn)失敗；另一方面，如果中間人將這個(gè)信息插入給ClientHello1，那么雖然服務(wù)器現(xiàn)在校驗(yàn)成功，但是后續(xù)服務(wù)器校驗(yàn)協(xié)商會(huì)話完整性時(shí)還是會(huì)失敗。
總而言之，安全重協(xié)商機(jī)制會(huì)補(bǔ)上重協(xié)商的漏洞隱患，讓中間人攻擊無(wú)機(jī)可乘。

如何防止 SSL 重協(xié)商攻擊？

以下是阻止 SSL 重新協(xié)商攻擊對(duì)網(wǎng)站和訪客造成危害的五種方法：

1. 實(shí)施嚴(yán)格的 TLS 版本控制：配置服務(wù)器，使其只支持 TLS 協(xié)議的最新版本，如TLS 1.2 或 TLS 1.3。舊版本的 TLS 存在已知漏洞，攻擊者可加以利用。

2. 禁用 SSL 重新協(xié)商：完全禁用 SSL 重新協(xié)商或?qū)⑵涫褂梅秶拗圃谑苄湃蔚目蛻舳恕９粽呖梢詾E用它，注入有效載荷或破壞通信。禁用或嚴(yán)格控制重新談判可以降低這種風(fēng)險(xiǎn)。

3.使用完美前向保密 (PFS)：?jiǎn)⒂?“完美前向保密“功能，以確保用于加密的每個(gè)會(huì)話密鑰都是唯一的，并且不是從服務(wù)器的私人密鑰中提取的。即使攻擊者將來(lái)侵入了服務(wù)器的私鑰，也無(wú)法解密過(guò)去的通信。PFS 增加了一個(gè)額外的保護(hù)層，防止 SSL 重新協(xié)商攻擊。

4.實(shí)施速率限制和監(jiān)控：設(shè)置速率限制機(jī)制，以檢測(cè)和減少過(guò)多的 SSL 重新協(xié)商請(qǐng)求。監(jiān)控 TLS 流量，以發(fā)現(xiàn)表明攻擊正在進(jìn)行的異常情況和意外模式。您可以主動(dòng)監(jiān)控 SSL 重新協(xié)商活動(dòng)，實(shí)時(shí)識(shí)別并阻止?jié)撛谕{。

5.定期更新 SSL 庫(kù)并打補(bǔ)?。豪纾绻褂玫氖荗penSSL，請(qǐng)確保您運(yùn)行的是最新版本，如 OpenSSL 3.0，并應(yīng)用 OpenSSL 項(xiàng)目提供的補(bǔ)丁來(lái)解決任何已發(fā)現(xiàn)的漏洞。同樣，如果你的應(yīng)用程序依賴于特定的 SSL/TLS 庫(kù)（如 LibreSSL 或 BoringSSL），請(qǐng)定期檢查更新并應(yīng)用其各自維護(hù)者發(fā)布的補(bǔ)丁。

02 禁用TLS壓縮

1. 禁用TLS壓縮：

防止CRIME攻擊：TLS壓縮存在安全漏洞，可以通過(guò)CRIME攻擊竊取啟用數(shù)據(jù)壓縮特性的HTTPS或SPDY協(xié)議傳輸?shù)腸ookie。因此，在TLS 1.3中刪除了該特性以增強(qiáng)安全性。

TLS 1.3協(xié)議好在哪？

安全強(qiáng)化，TLS1.3依循極簡(jiǎn)主義的設(shè)計(jì)哲學(xué)，移除并修復(fù)了舊版本協(xié)議中的壞味道，將密鑰交換、對(duì)稱(chēng)加解密、壓縮等環(huán)節(jié)中可能存在的安全隱患剔除，防范于未然。
性能提升，TLS1.3在提高效率方面進(jìn)行了大量改進(jìn)，特別是對(duì)SSL握手過(guò)程進(jìn)行了重新設(shè)計(jì)，將握手交互延時(shí)從2-RTT降低至1-RTT甚至是0-RTT。在網(wǎng)絡(luò)環(huán)境較差或節(jié)點(diǎn)距離較遠(yuǎn)的情況下，這種優(yōu)化能節(jié)省幾百毫秒的時(shí)間。這幾百毫秒往往就能決定用戶下一步的行為是繼續(xù)瀏覽網(wǎng)頁(yè)還是關(guān)閉網(wǎng)頁(yè)。

TLS 1.2與TLS 1.3對(duì)比總結(jié)

相比TLSv1.2，TLSv1.3主要的優(yōu)勢(shì)如下：

性能提升：完全握手場(chǎng)景下，TLSv1.3握手消耗1-RTT；會(huì)話復(fù)用的場(chǎng)景，TLSv1.3握手消耗0-RTT；均比TLSv1.2少一個(gè)RTT。安全提升：TLSv1.3完全支持PFS（即完全前向安全）的密鑰交換算法；禁用有安全漏洞的加密套件；對(duì)ServerHello消息之后的握手信息加密。

防止信息泄露：?jiǎn)⒂肨LS壓縮可能導(dǎo)致敏感信息的泄露，而這些信息如果不進(jìn)行壓縮就不會(huì)泄露。禁用壓縮功能可以減少這種風(fēng)險(xiǎn)。

使用壓縮

壓縮可以使攻擊者在與攻擊者控制下的數(shù)據(jù)相同的上下文中對(duì)其進(jìn)行壓縮時(shí)恢復(fù)秘密數(shù)據(jù)。HTTP/2 可以壓縮頭字段；以下注意事項(xiàng)也適用于 HTTP 壓縮內(nèi)容編碼的使用([RFC7231])。

研究表明，壓縮攻擊利用了網(wǎng)絡(luò)的特征(例如 [BREACH])。攻擊者會(huì)誘使多個(gè)請(qǐng)求包含不同的明文，并觀察每個(gè)明文中得到的密文的長(zhǎng)度，當(dāng)對(duì)密文的猜測(cè)正確時(shí)，會(huì)暴露出較短的長(zhǎng)度。

在安全通道上進(jìn)行通信的實(shí)現(xiàn)方不得壓縮包含加密數(shù)據(jù)和攻擊者控制的數(shù)據(jù)的內(nèi)容，除非為每個(gè)數(shù)據(jù)源搭配使用單獨(dú)的壓縮字典。如果不能可靠地確定數(shù)據(jù)源，則不得使用壓縮。通用 stream 流壓縮(例如 TLS 提供的壓縮)不得與 HTTP/2 一起使用。在 [COMPRESSION] 中描述了有關(guān)頭字段壓縮的其他注意事項(xiàng)。

03 小結(jié)

禁用TLS會(huì)話重協(xié)商和TLS壓縮功能是為了防止各種類(lèi)型的攻擊，包括拒絕服務(wù)攻擊、中間人攻擊以及信息泄露，從而確保通信的安全性和可靠性。

因此，安全通信協(xié)議建議為 TLS1.2或以上版本，TLS1.3更有優(yōu)。