TLS概述

TLS（傳輸層安全性）協(xié)議基于SSL（安全套接字層）協(xié)議，該協(xié)議最初由Netscape開發(fā)，用于增強(qiáng)Internet上的電子商務(wù)安全性。SSL是在應(yīng)用程序級(jí)實(shí)現(xiàn)的，直接位于TCP（傳輸控制協(xié)議）之上，允許更高級(jí)別的協(xié)議（如HTTP或電子郵件協(xié)議）無(wú)需更改即可正常工作。如果正確配置了SSL，則第三方觀察者只能找到連接參數(shù)（例如，使用的加密類型），以及傳輸頻率和大概數(shù)據(jù)量，但無(wú)法讀取和更改它們。
Internet協(xié)議棧中TLS（SSL）的具體位置如圖所示：

在IETF（Internet工程任務(wù)組）標(biāo)準(zhǔn)化SSL協(xié)議后，它被重命名為TLS。因此，盡管名稱SSL和TLS是可互換的，但它們?nèi)匀徊煌?#xff0c;因?yàn)槊總€(gè)描述了協(xié)議的不同版本。

該協(xié)議的第一個(gè)發(fā)布版本稱為SSL 2.0，但由于發(fā)現(xiàn)了漏洞，因此很快被SSL 3.0取代。如前所述，SSL是由Netscape開發(fā)的，因此在1999年1月，IETF以TLS 1.0的名稱公開標(biāo)準(zhǔn)化。然后在2006年4月，發(fā)布了一個(gè)版本的TLS 1.1，它擴(kuò)展了協(xié)議的原始功能并涵蓋了已知的漏洞。目前的協(xié)議版本是TLS 1.2，于2008年8月發(fā)布。

如前所述，TLS旨在用于TCP，但是為了使用UDP（用戶數(shù)據(jù)報(bào)協(xié)議）等數(shù)據(jù)報(bào)協(xié)議，開發(fā)了一種特殊版本的TLS，稱為DTLS（數(shù)據(jù)報(bào)傳輸層安全性）。

加密，身份驗(yàn)證和完整性

TLS協(xié)議旨在為所有正在使用它的應(yīng)用程序提供三種服務(wù)，即：加密，身份驗(yàn)證和完整性。從技術(shù)上講，并非所有三種都可以使用，但在實(shí)踐中，為了確保安全，通常使用所有三種：

• 加密 - 隱藏從一臺(tái)計(jì)算機(jī)傳輸?shù)搅硪慌_(tái)計(jì)算機(jī)的信息;
• 身份驗(yàn)證 - 驗(yàn)證傳輸信息的作者身份;
• 誠(chéng)信 - 檢測(cè)信息的偽造。

為了建立加密安全數(shù)據(jù)通道，連接節(jié)點(diǎn)必須就所使用的加密方法和密鑰達(dá)成一致。TLS協(xié)議唯一標(biāo)識(shí)此過(guò)程，更多內(nèi)容在TLS Handshake中進(jìn)行了討論。應(yīng)當(dāng)注意，TLS使用公鑰加密，其允許節(jié)點(diǎn)在沒有彼此任何先驗(yàn)知識(shí)的情況下建立共享秘密加密密鑰。

同樣在TLS握手過(guò)程的框架中，可以建立客戶端和服務(wù)器的身份的真實(shí)性。例如，客戶可以確定向他提供有關(guān)銀行帳戶信息的服務(wù)器實(shí)際上是銀行服務(wù)器。反之亦然：公司的服務(wù)器可以確定連接到它的客戶是公司的員工，而不是局外人（這種機(jī)制稱為信任鏈，將在相應(yīng)的部分討論）。

最后，TLS提供每個(gè)消息的發(fā)送MAC（消息認(rèn)證碼）代碼，其創(chuàng)建算法是單向加密散列函數(shù)（實(shí)際上是校驗(yàn)和），其密鑰對(duì)于兩個(gè)通信參與者都是已知的。每次發(fā)送消息時(shí)，都會(huì)生成其MAC值，該值也可以由接收方生成，這可以確保信息的完整性并防止其替換。

因此，簡(jiǎn)要考慮了TLS協(xié)議的加密安全性的所有三種機(jī)制。

握手

在通過(guò)TLS開始數(shù)據(jù)交換之前，客戶端和服務(wù)器必須就連接參數(shù)達(dá)成一致，即：所使用協(xié)議的版本，數(shù)據(jù)加密方法，并在必要時(shí)檢查證書。啟動(dòng)連接的方案稱為TLS Handshake，如圖所示：

讓我們更詳細(xì)地分析此過(guò)程的每個(gè)步驟：

由于TLS正在使用TCP，因此首先在客戶端和服務(wù)器之間建立TCP連接。

安裝TCP后，客戶端以明文形式將規(guī)范發(fā)送到服務(wù)器（即，它要使用的協(xié)議版本，支持的加密方法等）。

服務(wù)器批準(zhǔn)所使用協(xié)議的版本，從提供的列表中選擇加密方法，附加其證書并向客戶端發(fā)送響應(yīng)（如果需要，服務(wù)器也可以請(qǐng)求客戶端證書）。

此時(shí)的協(xié)議版本和加密方法被視為已批準(zhǔn)，客戶端檢查發(fā)送的證書并啟動(dòng)RSA或Diffie-Hellman密鑰交換，具體取決于所設(shè)置的參數(shù)。

服務(wù)器處理客戶端發(fā)送的消息，驗(yàn)證MAC，并以加密形式向客戶端發(fā)送最終（“完成”）消息。

客戶端解密收到的消息，檢查MAC，如果一切正常，則認(rèn)為連接已建立，應(yīng)用程序數(shù)據(jù)交換開始。

顯然，建立TLS連接通常是一個(gè)漫長(zhǎng)而耗時(shí)的過(guò)程，因此TLS標(biāo)準(zhǔn)中有幾個(gè)優(yōu)化。特別是，有一個(gè)稱為“縮寫握手”的過(guò)程，它允許您使用先前商定的參數(shù)重新連接（當(dāng)然，如果客戶端和服務(wù)器過(guò)去已經(jīng)建立了TLS連接）。在“恢復(fù)會(huì)話”項(xiàng)中更詳細(xì)地討論了該過(guò)程。

握手過(guò)程還有一個(gè)額外的擴(kuò)展，稱為TLS False Start。此擴(kuò)展允許客戶端和服務(wù)器在加密方法建立后立即開始交換加密數(shù)據(jù)，這減少了一次迭代消息的連接建立。這在“TLS False Start”中有更詳細(xì)的討論。

TLS密鑰交換

=由于各種歷史和商業(yè)原因，TLS使用RSA算法最常使用密鑰交換：客戶端生成對(duì)稱密鑰，使用服務(wù)器的公鑰對(duì)其進(jìn)行簽名，然后將其發(fā)送到服務(wù)器。反過(guò)來(lái)，使用私鑰解密服務(wù)器上的客戶端密鑰。在此之后，密鑰交換被宣布完成。該算法有一個(gè)缺點(diǎn)：同一對(duì)公鑰和私鑰也用于服務(wù)器認(rèn)證。因此，如果攻擊者獲得對(duì)服務(wù)器私鑰的訪問(wèn)權(quán)，他就可以解密整個(gè)通信會(huì)話。此外，攻擊者可以簡(jiǎn)單地以加密版本記錄整個(gè)通信會(huì)話，并在以后可以獲得服務(wù)器的私鑰時(shí)進(jìn)行解密。與此同時(shí)，Diffie-Hellman密鑰交換似乎更安全，因?yàn)榘惭b的對(duì)稱密鑰永遠(yuǎn)不會(huì)離開客戶端或服務(wù)器，因此，即使他知道服務(wù)器的私鑰，也不會(huì)被入侵者截獲。降低過(guò)去通信會(huì)話危害的風(fēng)險(xiǎn)的服務(wù)基于：對(duì)于每個(gè)新的通信會(huì)話，創(chuàng)建新的所謂的“臨時(shí)”對(duì)稱密鑰。因此，即使在最壞的情況下（如果攻擊者知道服務(wù)器的私鑰），攻擊者也只能從未來(lái)的會(huì)話中獲取密鑰，而不能解密先前記錄的密鑰。所謂的“臨時(shí)”對(duì)稱密鑰。因此，即使在最壞的情況下（如果攻擊者知道服務(wù)器的私鑰），攻擊者也只能從未來(lái)的會(huì)話中獲取密鑰，而不能解密先前記錄的密鑰。所謂的“臨時(shí)”對(duì)稱密鑰。因此，即使在最壞的情況下（如果攻擊者知道服務(wù)器的私鑰），攻擊者也只能從未來(lái)的會(huì)話中獲取密鑰，而不能解密先前記錄的密鑰。

目前，所有瀏覽器在建立TLS連接時(shí)，更喜歡Diffie-Hellman算法的組合和臨時(shí)密鑰的使用，以提高連接的安全性。

應(yīng)該再次注意，公鑰加密僅在初始連接建立期間的TLS握手過(guò)程中使用。配置隧道后，對(duì)稱加密開始起作用，并使用指定的對(duì)稱密鑰加密當(dāng)前會(huì)話中的通信。這對(duì)于提高性能是必要的，因?yàn)楣€加密需要更多的計(jì)算能力。

恢復(fù)TLS會(huì)話

如前所述，完整的TLS握手過(guò)程在計(jì)算成本方面非常冗長(zhǎng)且昂貴。因此，開發(fā)了一個(gè)過(guò)程，允許您根據(jù)已配置的數(shù)據(jù)恢復(fù)先前中斷的連接。

從協(xié)議的第一個(gè)公共版本（SSL 2.0）開始，TLS握手內(nèi)的服務(wù)器（即，初始ServerHello消息）可以生成并發(fā)送32字節(jié)的會(huì)話標(biāo)識(shí)符。當(dāng)然，在這種情況下，服務(wù)器為每個(gè)客戶端存儲(chǔ)生成的標(biāo)識(shí)符和會(huì)話參數(shù)的緩存。反過(guò)來(lái)，客戶端存儲(chǔ)發(fā)送的ID，并在初始ClientHello消息中包含它（當(dāng)然，如果存在）。如果客戶端和服務(wù)器都具有相同的會(huì)話標(biāo)識(shí)符，則使用圖中所示的簡(jiǎn)化算法建立公共連接。如果沒有，則需要完整版的TLS握手。

會(huì)話續(xù)訂過(guò)程允許您跳過(guò)對(duì)稱密鑰的生成，這會(huì)顯著增加連接建立時(shí)間，但不會(huì)影響其安全性，因?yàn)槭褂昧讼惹皶?huì)話中先前未妥協(xié)的數(shù)據(jù)。

然而，存在實(shí)際限制：由于服務(wù)器必須存儲(chǔ)關(guān)于所有打開會(huì)話的數(shù)據(jù)，這導(dǎo)致數(shù)千和數(shù)百萬(wàn)客戶同時(shí)請(qǐng)求的流行資源的問(wèn)題。

為了避免這個(gè)問(wèn)題，開發(fā)了一個(gè)“會(huì)話票證”機(jī)制，它消除了在服務(wù)器上存儲(chǔ)每個(gè)客戶端數(shù)據(jù)的需要。如果客戶端在初始連接建立期間表明它支持該技術(shù)，則TLS握手期間服務(wù)器向客戶端發(fā)送所謂的會(huì)話票證 - 使用服務(wù)器私鑰加密的會(huì)話參數(shù)。下次會(huì)話恢復(fù)時(shí)，客戶端會(huì)發(fā)送會(huì)話票證和ClientHello。因此，服務(wù)器不需要存儲(chǔ)關(guān)于每個(gè)連接的數(shù)據(jù)，但是連接仍然是安全的，因?yàn)闀?huì)話票證使用僅在服務(wù)器上已知的密鑰加密。

TLS錯(cuò)誤啟動(dòng)

會(huì)話恢復(fù)技術(shù)無(wú)疑會(huì)提高協(xié)議性能并降低計(jì)算成本，但是，它不適用于與服務(wù)器的初始連接，或者在前一個(gè)會(huì)話已經(jīng)過(guò)期的情況下。

為了獲得更好的性能，開發(fā)了TLS False Start技術(shù)，這是一個(gè)可選的協(xié)議擴(kuò)展，允許您在TLS握手僅部分完成時(shí)發(fā)送數(shù)據(jù)。詳細(xì)的TLS False Start方案如圖所示：

重要的是要注意TLS False Start不會(huì)改變TLS握手過(guò)程。它基于這樣的假設(shè)：在客戶端和服務(wù)器已經(jīng)知道連接參數(shù)和對(duì)稱密鑰的那一刻，可以已經(jīng)發(fā)送應(yīng)用程序數(shù)據(jù)，并且可以并行執(zhí)行所有必要的檢查。因此，連接已準(zhǔn)備好使用之前的一個(gè)消息傳遞迭代。

TLS信任鏈

身份驗(yàn)證是每個(gè)TLS連接的組成部分?？紤]Alice和Bob之間最簡(jiǎn)單的身份驗(yàn)證過(guò)程：

Alice和Bob都生成自己的公鑰和私鑰。

Alice和Bob交換公鑰。

Alice生成一條消息，用她的私鑰對(duì)其進(jìn)行加密，并將其發(fā)送給Bob。

Bob使用從Alice接收的密鑰來(lái)解密消息，從而驗(yàn)證所接收消息的真實(shí)性。

顯然，這個(gè)方案建立在Alice和Bob之間的信任基礎(chǔ)上。假設(shè)公鑰的交換發(fā)生在例如個(gè)人會(huì)議期間，因此Alice確信她直接從Bob接收到密鑰，而Bob又確信她收到了Alice的公鑰。

現(xiàn)在讓愛麗絲收到查理的消息，她不熟悉，但聲稱自己是鮑勃的朋友。為了證明這一點(diǎn)，Charlie要求他提前用Bob的私鑰簽署他自己的公鑰，然后將這個(gè)簽名附加到給Alice的消息上。Alice首先檢查Bob在Chalie的密鑰上的簽名（她能夠做到這一點(diǎn)，因?yàn)锽ob的公鑰已經(jīng)知道），確保Charlie真的是Bob的朋友，接受他的消息并執(zhí)行已知的完整性檢查，確保消息來(lái)自Charlie ：

前一段中描述的是創(chuàng)建“信任鏈”（或“信任鏈”，如果是英語(yǔ)）。
在TLS協(xié)議中，信任鏈數(shù)據(jù)基于由特殊機(jī)構(gòu)提供的真實(shí)性證書，稱為證書頒發(fā)機(jī)構(gòu)（CA）。證書頒發(fā)機(jī)構(gòu)進(jìn)行檢查，如果頒發(fā)的證書被泄露，則該證書將被撤銷。

從頒發(fā)的證書形成已經(jīng)被認(rèn)為是一個(gè)信任鏈。它的根源是所謂的“根CA證書” - 由大型中心簽署的證書，其可信度是無(wú)可爭(zhēng)辯的。通常，信任鏈看起來(lái)像這樣：

當(dāng)然，有些情況下必須撤銷或撤銷已頒發(fā)的證書（例如，證書的私鑰被泄露，或整個(gè)認(rèn)證程序受到損害）。為此，真品證書包含有關(guān)檢查其相關(guān)性的特殊說(shuō)明。因此，在構(gòu)建信任鏈時(shí)，有必要檢查每個(gè)信任節(jié)點(diǎn)的相關(guān)性。

這種檢查的機(jī)制很簡(jiǎn)單，它基于所謂的。“證書撤銷清單”（CRL）。每個(gè)證書頒發(fā)機(jī)構(gòu)都有此列表，這是一個(gè)簡(jiǎn)單的已撤銷證書序列號(hào)列表。因此，任何想要驗(yàn)證證書真實(shí)性的人只需下載該列表并搜索要檢查的證書號(hào)。如果找到該號(hào)碼 - 則表示該證書已被撤銷。

顯然存在一些技術(shù)上的不合理性：要僅檢查一個(gè)證書，需要請(qǐng)求整個(gè)撤銷證書列表，這會(huì)導(dǎo)致速度變慢。為了解決這個(gè)問(wèn)題，開發(fā)了一種稱為證書證書狀態(tài)協(xié)議（OCSP）的機(jī)制。它允許您動(dòng)態(tài)檢查證書狀態(tài)。當(dāng)然，這減少了網(wǎng)絡(luò)帶寬的負(fù)擔(dān)，但同時(shí)也產(chǎn)生了幾個(gè)問(wèn)題：

• CA必須處理實(shí)時(shí)工作負(fù)載;
• 證書頒發(fā)機(jī)構(gòu)必須始終確保其可用性;
• 由于實(shí)時(shí)請(qǐng)求，證書頒發(fā)機(jī)構(gòu)會(huì)收到有關(guān)每個(gè)用戶訪問(wèn)過(guò)哪些站點(diǎn)的信息。

實(shí)際上，在所有現(xiàn)代瀏覽器中，兩種解決方案（OCSP和CRL）相互補(bǔ)充，而且，通常，可以自定義用于檢查證書狀態(tài)的首選策略。

轉(zhuǎn)載自?habr.com

總結(jié)

以上是生活随笔為你收集整理的由于在客户端检测到一个协议错误_TLS协议的分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。