TLS概述

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

在IETF（Internet工程任務組）標準化SSL協議后，它被重命名為TLS。因此，盡管名稱SSL和TLS是可互換的，但它們仍然不同，因為每個描述了協議的不同版本。

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

如前所述，TLS旨在用于TCP，但是為了使用UDP（用戶數據報協議）等數據報協議，開發了一種特殊版本的TLS，稱為DTLS（數據報傳輸層安全性）。

加密，身份驗證和完整性

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

• 加密 - 隱藏從一臺計算機傳輸到另一臺計算機的信息;
• 身份驗證 - 驗證傳輸信息的作者身份;
• 誠信 - 檢測信息的偽造。

為了建立加密安全數據通道，連接節點必須就所使用的加密方法和密鑰達成一致。TLS協議唯一標識此過程，更多內容在TLS Handshake中進行了討論。應當注意，TLS使用公鑰加密，其允許節點在沒有彼此任何先驗知識的情況下建立共享秘密加密密鑰。

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

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

因此，簡要考慮了TLS協議的加密安全性的所有三種機制。

握手

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

讓我們更詳細地分析此過程的每個步驟：

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

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

服務器批準所使用協議的版本，從提供的列表中選擇加密方法，附加其證書并向客戶端發送響應（如果需要，服務器也可以請求客戶端證書）。

此時的協議版本和加密方法被視為已批準，客戶端檢查發送的證書并啟動RSA或Diffie-Hellman密鑰交換，具體取決于所設置的參數。

服務器處理客戶端發送的消息，驗證MAC，并以加密形式向客戶端發送最終（“完成”）消息。

客戶端解密收到的消息，檢查MAC，如果一切正常，則認為連接已建立，應用程序數據交換開始。

顯然，建立TLS連接通常是一個漫長而耗時的過程，因此TLS標準中有幾個優化。特別是，有一個稱為“縮寫握手”的過程，它允許您使用先前商定的參數重新連接（當然，如果客戶端和服務器過去已經建立了TLS連接）。在“恢復會話”項中更詳細地討論了該過程。

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

TLS密鑰交換

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

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

應該再次注意，公鑰加密僅在初始連接建立期間的TLS握手過程中使用。配置隧道后，對稱加密開始起作用，并使用指定的對稱密鑰加密當前會話中的通信。這對于提高性能是必要的，因為公鑰加密需要更多的計算能力。

恢復TLS會話

如前所述，完整的TLS握手過程在計算成本方面非常冗長且昂貴。因此，開發了一個過程，允許您根據已配置的數據恢復先前中斷的連接。

從協議的第一個公共版本（SSL 2.0）開始，TLS握手內的服務器（即，初始ServerHello消息）可以生成并發送32字節的會話標識符。當然，在這種情況下，服務器為每個客戶端存儲生成的標識符和會話參數的緩存。反過來，客戶端存儲發送的ID，并在初始ClientHello消息中包含它（當然，如果存在）。如果客戶端和服務器都具有相同的會話標識符，則使用圖中所示的簡化算法建立公共連接。如果沒有，則需要完整版的TLS握手。

會話續訂過程允許您跳過對稱密鑰的生成，這會顯著增加連接建立時間，但不會影響其安全性，因為使用了先前會話中先前未妥協的數據。

然而，存在實際限制：由于服務器必須存儲關于所有打開會話的數據，這導致數千和數百萬客戶同時請求的流行資源的問題。

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

TLS錯誤啟動

會話恢復技術無疑會提高協議性能并降低計算成本，但是，它不適用于與服務器的初始連接，或者在前一個會話已經過期的情況下。

為了獲得更好的性能，開發了TLS False Start技術，這是一個可選的協議擴展，允許您在TLS握手僅部分完成時發送數據。詳細的TLS False Start方案如圖所示：

重要的是要注意TLS False Start不會改變TLS握手過程。它基于這樣的假設：在客戶端和服務器已經知道連接參數和對稱密鑰的那一刻，可以已經發送應用程序數據，并且可以并行執行所有必要的檢查。因此，連接已準備好使用之前的一個消息傳遞迭代。

TLS信任鏈

身份驗證是每個TLS連接的組成部分。考慮Alice和Bob之間最簡單的身份驗證過程：

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

Alice和Bob交換公鑰。

Alice生成一條消息，用她的私鑰對其進行加密，并將其發送給Bob。

Bob使用從Alice接收的密鑰來解密消息，從而驗證所接收消息的真實性。

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

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

前一段中描述的是創建“信任鏈”（或“信任鏈”，如果是英語）。
在TLS協議中，信任鏈數據基于由特殊機構提供的真實性證書，稱為證書頒發機構（CA）。證書頒發機構進行檢查，如果頒發的證書被泄露，則該證書將被撤銷。

從頒發的證書形成已經被認為是一個信任鏈。它的根源是所謂的“根CA證書” - 由大型中心簽署的證書，其可信度是無可爭辯的。通常，信任鏈看起來像這樣：

當然，有些情況下必須撤銷或撤銷已頒發的證書（例如，證書的私鑰被泄露，或整個認證程序受到損害）。為此，真品證書包含有關檢查其相關性的特殊說明。因此，在構建信任鏈時，有必要檢查每個信任節點的相關性。

這種檢查的機制很簡單，它基于所謂的。“證書撤銷清單”（CRL）。每個證書頒發機構都有此列表，這是一個簡單的已撤銷證書序列號列表。因此，任何想要驗證證書真實性的人只需下載該列表并搜索要檢查的證書號。如果找到該號碼 - 則表示該證書已被撤銷。

顯然存在一些技術上的不合理性：要僅檢查一個證書，需要請求整個撤銷證書列表，這會導致速度變慢。為了解決這個問題，開發了一種稱為證書證書狀態協議（OCSP）的機制。它允許您動態檢查證書狀態。當然，這減少了網絡帶寬的負擔，但同時也產生了幾個問題：

• CA必須處理實時工作負載;
• 證書頒發機構必須始終確保其可用性;
• 由于實時請求，證書頒發機構會收到有關每個用戶訪問過哪些站點的信息。

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

轉載自?habr.com

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。