由于在客户端检测到一个协议错误_TLS协议的分析
TLS概述
TLS（傳輸層安全性）協(xié)議基于SSL（安全套接字層）協(xié)議，該協(xié)議最初由Netscape開發(fā)，用于增強Internet上的電子商務安全性。SSL是在應用程序級實現(xiàn)的，直接位于TCP（傳輸控制協(xié)議）之上，允許更高級別的協(xié)議（如HTTP或電子郵件協(xié)議）無需更改即可正常工作。如果正確配置了SSL，則第三方觀察者只能找到連接參數(shù)（例如，使用的加密類型），以及傳輸頻率和大概數(shù)據(jù)量，但無法讀取和更改它們。
Internet協(xié)議棧中TLS（SSL）的具體位置如圖所示：
在IETF（Internet工程任務組）標準化SSL協(xié)議后，它被重命名為TLS。因此，盡管名稱SSL和TLS是可互換的，但它們?nèi)匀徊煌?#xff0c;因為每個描述了協(xié)議的不同版本。
該協(xié)議的第一個發(fā)布版本稱為SSL 2.0，但由于發(fā)現(xiàn)了漏洞，因此很快被SSL 3.0取代。如前所述，SSL是由Netscape開發(fā)的，因此在1999年1月，IETF以TLS 1.0的名稱公開標準化。然后在2006年4月，發(fā)布了一個版本的TLS 1.1，它擴展了協(xié)議的原始功能并涵蓋了已知的漏洞。目前的協(xié)議版本是TLS 1.2，于2008年8月發(fā)布。
如前所述，TLS旨在用于TCP，但是為了使用UDP（用戶數(shù)據(jù)報協(xié)議）等數(shù)據(jù)報協(xié)議，開發(fā)了一種特殊版本的TLS，稱為DTLS（數(shù)據(jù)報傳輸層安全性）。
加密，身份驗證和完整性
TLS協(xié)議旨在為所有正在使用它的應用程序提供三種服務，即：加密，身份驗證和完整性。從技術上講，并非所有三種都可以使用，但在實踐中，為了確保安全，通常使用所有三種：
- 加密 - 隱藏從一臺計算機傳輸?shù)搅硪慌_計算機的信息;
- 身份驗證 - 驗證傳輸信息的作者身份;
- 誠信 - 檢測信息的偽造。
為了建立加密安全數(shù)據(jù)通道，連接節(jié)點必須就所使用的加密方法和密鑰達成一致。TLS協(xié)議唯一標識此過程，更多內(nèi)容在TLS Handshake中進行了討論。應當注意，TLS使用公鑰加密，其允許節(jié)點在沒有彼此任何先驗知識的情況下建立共享秘密加密密鑰。
同樣在TLS握手過程的框架中，可以建立客戶端和服務器的身份的真實性。例如，客戶可以確定向他提供有關銀行帳戶信息的服務器實際上是銀行服務器。反之亦然：公司的服務器可以確定連接到它的客戶是公司的員工，而不是局外人（這種機制稱為信任鏈，將在相應的部分討論）。
最后，TLS提供每個消息的發(fā)送MAC（消息認證碼）代碼，其創(chuàng)建算法是單向加密散列函數(shù)（實際上是校驗和），其密鑰對于兩個通信參與者都是已知的。每次發(fā)送消息時，都會生成其MAC值，該值也可以由接收方生成，這可以確保信息的完整性并防止其替換。
因此，簡要考慮了TLS協(xié)議的加密安全性的所有三種機制。
握手
在通過TLS開始數(shù)據(jù)交換之前，客戶端和服務器必須就連接參數(shù)達成一致，即：所使用協(xié)議的版本，數(shù)據(jù)加密方法，并在必要時檢查證書。啟動連接的方案稱為TLS Handshake，如圖所示：
讓我們更詳細地分析此過程的每個步驟：
顯然，建立TLS連接通常是一個漫長而耗時的過程，因此TLS標準中有幾個優(yōu)化。特別是，有一個稱為“縮寫握手”的過程，它允許您使用先前商定的參數(shù)重新連接（當然，如果客戶端和服務器過去已經(jīng)建立了TLS連接）。在“恢復會話”項中更詳細地討論了該過程。
握手過程還有一個額外的擴展，稱為TLS False Start。此擴展允許客戶端和服務器在加密方法建立后立即開始交換加密數(shù)據(jù)，這減少了一次迭代消息的連接建立。這在“TLS False Start”中有更詳細的討論。
TLS密鑰交換
=由于各種歷史和商業(yè)原因，TLS使用RSA算法最常使用密鑰交換：客戶端生成對稱密鑰，使用服務器的公鑰對其進行簽名，然后將其發(fā)送到服務器。反過來，使用私鑰解密服務器上的客戶端密鑰。在此之后，密鑰交換被宣布完成。該算法有一個缺點：同一對公鑰和私鑰也用于服務器認證。因此，如果攻擊者獲得對服務器私鑰的訪問權，他就可以解密整個通信會話。此外，攻擊者可以簡單地以加密版本記錄整個通信會話，并在以后可以獲得服務器的私鑰時進行解密。與此同時，Diffie-Hellman密鑰交換似乎更安全，因為安裝的對稱密鑰永遠不會離開客戶端或服務器，因此，即使他知道服務器的私鑰，也不會被入侵者截獲。降低過去通信會話危害的風險的服務基于：對于每個新的通信會話，創(chuàng)建新的所謂的“臨時”對稱密鑰。因此，即使在最壞的情況下（如果攻擊者知道服務器的私鑰），攻擊者也只能從未來的會話中獲取密鑰，而不能解密先前記錄的密鑰。所謂的“臨時”對稱密鑰。因此，即使在最壞的情況下（如果攻擊者知道服務器的私鑰），攻擊者也只能從未來的會話中獲取密鑰，而不能解密先前記錄的密鑰。所謂的“臨時”對稱密鑰。因此，即使在最壞的情況下（如果攻擊者知道服務器的私鑰），攻擊者也只能從未來的會話中獲取密鑰，而不能解密先前記錄的密鑰。
目前，所有瀏覽器在建立TLS連接時，更喜歡Diffie-Hellman算法的組合和臨時密鑰的使用，以提高連接的安全性。
應該再次注意，公鑰加密僅在初始連接建立期間的TLS握手過程中使用。配置隧道后，對稱加密開始起作用，并使用指定的對稱密鑰加密當前會話中的通信。這對于提高性能是必要的，因為公鑰加密需要更多的計算能力。
恢復TLS會話
如前所述，完整的TLS握手過程在計算成本方面非常冗長且昂貴。因此，開發(fā)了一個過程，允許您根據(jù)已配置的數(shù)據(jù)恢復先前中斷的連接。
從協(xié)議的第一個公共版本（SSL 2.0）開始，TLS握手內(nèi)的服務器（即，初始ServerHello消息）可以生成并發(fā)送32字節(jié)的會話標識符。當然，在這種情況下，服務器為每個客戶端存儲生成的標識符和會話參數(shù)的緩存。反過來，客戶端存儲發(fā)送的ID，并在初始ClientHello消息中包含它（當然，如果存在）。如果客戶端和服務器都具有相同的會話標識符，則使用圖中所示的簡化算法建立公共連接。如果沒有，則需要完整版的TLS握手。
會話續(xù)訂過程允許您跳過對稱密鑰的生成，這會顯著增加連接建立時間，但不會影響其安全性，因為使用了先前會話中先前未妥協(xié)的數(shù)據(jù)。
然而，存在實際限制：由于服務器必須存儲關于所有打開會話的數(shù)據(jù)，這導致數(shù)千和數(shù)百萬客戶同時請求的流行資源的問題。
為了避免這個問題，開發(fā)了一個“會話票證”機制，它消除了在服務器上存儲每個客戶端數(shù)據(jù)的需要。如果客戶端在初始連接建立期間表明它支持該技術，則TLS握手期間服務器向客戶端發(fā)送所謂的會話票證 - 使用服務器私鑰加密的會話參數(shù)。下次會話恢復時，客戶端會發(fā)送會話票證和ClientHello。因此，服務器不需要存儲關于每個連接的數(shù)據(jù)，但是連接仍然是安全的，因為會話票證使用僅在服務器上已知的密鑰加密。
TLS錯誤啟動
會話恢復技術無疑會提高協(xié)議性能并降低計算成本，但是，它不適用于與服務器的初始連接，或者在前一個會話已經(jīng)過期的情況下。
為了獲得更好的性能，開發(fā)了TLS False Start技術，這是一個可選的協(xié)議擴展，允許您在TLS握手僅部分完成時發(fā)送數(shù)據(jù)。詳細的TLS False Start方案如圖所示：
重要的是要注意TLS False Start不會改變TLS握手過程。它基于這樣的假設：在客戶端和服務器已經(jīng)知道連接參數(shù)和對稱密鑰的那一刻，可以已經(jīng)發(fā)送應用程序數(shù)據(jù)，并且可以并行執(zhí)行所有必要的檢查。因此，連接已準備好使用之前的一個消息傳遞迭代。
TLS信任鏈
身份驗證是每個TLS連接的組成部分。考慮Alice和Bob之間最簡單的身份驗證過程：
顯然，這個方案建立在Alice和Bob之間的信任基礎上。假設公鑰的交換發(fā)生在例如個人會議期間，因此Alice確信她直接從Bob接收到密鑰，而Bob又確信她收到了Alice的公鑰。
現(xiàn)在讓愛麗絲收到查理的消息，她不熟悉，但聲稱自己是鮑勃的朋友。為了證明這一點，Charlie要求他提前用Bob的私鑰簽署他自己的公鑰，然后將這個簽名附加到給Alice的消息上。Alice首先檢查Bob在Chalie的密鑰上的簽名（她能夠做到這一點，因為Bob的公鑰已經(jīng)知道），確保Charlie真的是Bob的朋友，接受他的消息并執(zhí)行已知的完整性檢查，確保消息來自Charlie ：
前一段中描述的是創(chuàng)建“信任鏈”（或“信任鏈”，如果是英語）。
在TLS協(xié)議中，信任鏈數(shù)據(jù)基于由特殊機構提供的真實性證書，稱為證書頒發(fā)機構（CA）。證書頒發(fā)機構進行檢查，如果頒發(fā)的證書被泄露，則該證書將被撤銷。
從頒發(fā)的證書形成已經(jīng)被認為是一個信任鏈。它的根源是所謂的“根CA證書” - 由大型中心簽署的證書，其可信度是無可爭辯的。通常，信任鏈看起來像這樣：
當然，有些情況下必須撤銷或撤銷已頒發(fā)的證書（例如，證書的私鑰被泄露，或整個認證程序受到損害）。為此，真品證書包含有關檢查其相關性的特殊說明。因此，在構建信任鏈時，有必要檢查每個信任節(jié)點的相關性。
這種檢查的機制很簡單，它基于所謂的。“證書撤銷清單”（CRL）。每個證書頒發(fā)機構都有此列表，這是一個簡單的已撤銷證書序列號列表。因此，任何想要驗證證書真實性的人只需下載該列表并搜索要檢查的證書號。如果找到該號碼 - 則表示該證書已被撤銷。
顯然存在一些技術上的不合理性：要僅檢查一個證書，需要請求整個撤銷證書列表，這會導致速度變慢。為了解決這個問題，開發(fā)了一種稱為證書證書狀態(tài)協(xié)議（OCSP）的機制。它允許您動態(tài)檢查證書狀態(tài)。當然，這減少了網(wǎng)絡帶寬的負擔，但同時也產(chǎn)生了幾個問題：
- CA必須處理實時工作負載;
- 證書頒發(fā)機構必須始終確保其可用性;
- 由于實時請求，證書頒發(fā)機構會收到有關每個用戶訪問過哪些站點的信息。
實際上，在所有現(xiàn)代瀏覽器中，兩種解決方案（OCSP和CRL）相互補充，而且，通常，可以自定義用于檢查證書狀態(tài)的首選策略。
轉(zhuǎn)載自?habr.com總結
以上是生活随笔為你收集整理的由于在客户端检测到一个协议错误_TLS协议的分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 正则匹配括号里面的内容不包括括号_pyt
- 下一篇： 【转】VTK修炼之道2_VTK体系结构1