Ssl握手報文的解析方法及裝置的制造方法
【專利摘要】本申請?zhí)峁┮环N安全套接層SSL握手報文的解析方法及裝置，所述方法包括：接收對端發(fā)送的SSL握手報文；識別接收到的所述SSL握手報文的類型；基于識別出的所述SSL握手報文的類型解析所述SSL握手報文。應用本申請不需要多次切換當前的SSL會話狀態(tài)、緩存報文等，因此網絡設備在當前的SSL會話狀態(tài)與接收到的SSL握手報文不匹配時，對所述SSL握手報文的解析效率高。
【專利說明】
SSL握手報文的解析方法及裝置
技術領域
[0001] 本申請設及網絡通信技術領域，尤其設及S化握手報文的解析方法及裝置。
【背景技術】
[0002] 為了提高網絡數據傳輸的安全性，越來越多的應用、網站開始使用SSUSecure Sockets Layer,安全套接層)協(xié)議，廣泛應用的有電子商務、網上銀行等領域。S化協(xié)議是一 個安全協(xié)議，為基于TCP的應用層協(xié)議提供安全連接，如S化協(xié)議可W為HTTP協(xié)議提供安全 連接。在使用S化協(xié)議進行信息交流之前，網絡設備之間需要通過S化握手協(xié)商完成對彼此 的認證。
[0003] 現有技術中，網絡設備W當前的S化會話狀態(tài)為基礎對S化握手報文進行解析。當 接收到S化握手報文時，網絡設備調用與當前的S化會話狀態(tài)對應的解析函數對該S化握手 報文進行解析。如果該S化握手報文與當前的S化會話狀態(tài)不匹配，則會出現解析錯誤，此 時，網絡設備不得不對該S化握手報文進行緩存，并切換當前的S化會話狀態(tài)，然后對該SSL 握手報文重新進行解析。由W上過程可知，當接收到的S化握手報文與當前的S化會話狀態(tài) 不匹配時，現有技術對該S化握手報文的解析效率低。

【發(fā)明內容】

[0004] 有鑒于此，本申請?zhí)峁┮环NS化握手報文的解析方法及裝置，來解決現有技術中當 網絡設備當前的S化會話狀態(tài)與接收到的S化握手報文不匹配時對該S化握手報文的解析效 率低的問題。
[0005] 具體地，本申請是通過如下技術方案實現的：
[0006] 根據本申請實施例的第一方面，提供一種S化握手報文的解析方法，所述方法應用 于網絡設備上，所述方法包括：
[0007] 接收對端發(fā)送的S化握手報文；
[000引識別接收到的所述S化握手報文的類型；
[0009] 基于識別出的所述S化握手報文的類型解析所述S化握手報文。
[0010] 根據本申請實施例的第二方面，提供一種解析SSL握手報文的裝置，所述裝置應用 于網絡設備上，所述裝置包括：
[0011] 接收單元，用于接收對端發(fā)送的S化握手報文；
[0012] 識別單元，用于識別接收到的所述S化握手報文的類型；
[0013] 解析單元，用于基于識別出的所述S化握手報文的類型解析所述S化握手報文。
[0014] 本申請?zhí)峁㏒化握手報文的解析方法及裝置，當接收到S化握手報文時，網絡設備 可W先判斷所述S化握手報文的類型，然后調用與所述S化握手報文的類型對應的解析函數 解析所述S化握手報文。在本申請中，由于網絡設備不再基于S化會話狀態(tài)來解析報文，而是 基于S化握手報文的類型來解析報文，因此可W提升對所述S化握手報文的解析效率。
【附圖說明】
[0015] 圖1是應用本申請實施例實現S化握手報文解析的一個應用場景示意圖；
[0016] 圖2是網絡設備之間建立SSL連接的一個交互流程圖；
[0017] 圖3是本申請S化握手報文的解析方法的一個實施例流程圖；
[0018] 圖4是本申請SSL握手報文的解析裝置所在設備的一種硬件結構圖；
[0019] 圖5是本申請SSL握手報文的解析裝置的一個實施例框圖。
【具體實施方式】
[0020] 運里將詳細地對示例性實施例進行說明，其示例表示在附圖中。下面的描述設及 附圖時，除非另有表示，不同附圖中的相同數字表示相同或相似的要素。W下示例性實施例 中所描述的實施方式并不代表與本申請相一致的所有實施方式。相反，它們僅是與如所附 權利要求書中所詳述的、本申請的一些方面相一致的裝置和方法的例子。
[0021] 在本申請使用的術語是僅僅出于描述特定實施例的目的，而非旨在限制本申請。 在本申請和所附權利要求書中所使用的單數形式的"一種"、"所述"和"該"也旨在包括多數 形式，除非上下文清楚地表示其他含義。還應當理解，本文中使用的術語"和/或"是指并包 含一個或多個相關聯的列出項目的任何或所有可能組合。
[0022] 應當理解，盡管在本申請可能采用術語第一、第二、第=等來描述各種信息，但運 些信息不應限于運些術語。運些術語僅用來將同一類型的信息彼此區(qū)分開。例如，在不脫離 本申請范圍的情況下，第一信息也可W被稱為第二信息，類似地，第二信息也可W被稱為第 一信息。取決于語境，如在此所使用的詞語"如果"可W被解釋成為"在……時"或"當…… 時"或"響應于確定"。
[0023] 參見圖1，為應用本申請實施例實現S化握手報文解析的一個應用場景示意圖。為 了加強網絡數據的安全性，客戶端和服務器之間可W建立S化連接。建立S化連接的交互流 程可W如圖2所示（圖2僅展示出部分交互流程），由圖2可知，在進行S化握手協(xié)商時，有些 S化握手報文是必不可少的（如圖1中標識為Required的報文），如開始會話連接的Cl ient Hello報文。但是，有些握手報文是可W根據網絡設備的自身需要選擇是否發(fā)送至與其進行 S S L握手協(xié)商的對端的（如圖1中標識為0 P t i 0 n a 1的報文），如包含自身證書信息的 Certif icate 報文。
[0024] W客戶端為例，客戶端的初始S化會話狀態(tài)為SSL_SEND_CLIENT_HE化0,此狀態(tài)表 示客戶端可W向對端即服務器發(fā)送S化握手報文。此時，客戶端的S化狀態(tài)機發(fā)現自己處于 SSL_沈ND_化IENT_肥化0的狀態(tài)，于是，執(zhí)行向服務器發(fā)送ClientHello報文的操作。所述 Client Hello報文發(fā)送成功后，客戶端將當前的S化會話狀態(tài)切換至下一個S化會話狀態(tài) SSL_GET_SERVER_HELLO，此狀態(tài)表示客戶端在等待來自服務器的Server HelIo報文。
[0025] 服務器接收到來自客戶端的Client Hello報文后，根據S化協(xié)議的相關內容向客 戶端發(fā)送Server HelIo報文，客戶端接收并解析所述Server HelIo報文后，將當前的SSL會 話狀態(tài)切換至SSL_GET_SERVER_CERT，此狀態(tài)表示客戶端希望接收服務器發(fā)來的證書，因 此，此時，客戶端在等待服務器發(fā)送包含證書信息的報文。
[00%]服務器在發(fā)送Server Hello報文后，根據S化協(xié)議的相關內容，服務器立刻發(fā)送包 含自身證書信息的報文即Cedif icate報文。客戶端接收并解析所述Cedif ica1:e報文，然 后將狀態(tài)切換至551^_6日1'_5?。と??_皿化0_00肥，W等待服務器發(fā)送Server胎Ilo Done報 文。
[0027] 但是，服務器發(fā)送Server Hello Done報文后，按照自身的配置，可能先向客戶端 發(fā)送Certificate Request報文，然后再發(fā)送Server Hello Done報文，或者直接發(fā)送 Server胎Ilo Done報文。因為，客戶端當前的SSL會話狀態(tài)為SSL_GET_SERVERJ1E1X0_ DO肥，表示客戶端想要接收Server Hello Done報文。所W，當客戶端接收到來自服務器的 Certificate Request報文時，因為客戶端的SSL狀態(tài)機發(fā)現自己處于SSL_GET_SERVER_ 肥化0_D0肥狀態(tài)，因此，客戶端的S化狀態(tài)機會采用與此S化會話狀態(tài)對應的解析函數對接 收到的Cedificate Request報文進行解析。因為客戶端采用的解析函數與報文的類型不 對應，因此，解析的結果自然是錯誤的。解析錯誤之后，客戶端發(fā)現此握手報文為 Certificate Request報文，于是，客戶端將此握手報文緩存，并把當前的SSL會話狀態(tài)切換 至SSL_GET_WRVER_CRET_REQ，然后采用與此SSL會話狀態(tài)對應的解析函數對Cedificate Request報文進行解析，此解析過程可W成功。由上述過程可知，在現有技術中，通常是基于 S化會話狀態(tài)來解析S化握手報文的，因此，在調用與當前的S化會話狀態(tài)對應的解析函數對 該S化握手報文進行解析時，如果該S化握手報文與當前的S化會話狀態(tài)不匹配，則會出現解 析錯誤，此時，網絡設備不得不對該握手報文進行緩存，并切換會話狀態(tài)重新進行解析，因 此當接收到的S化握手報文與當前的S化會話狀態(tài)不匹配時，現有技術對該S化握手報文的 解析效率低。
[0028] 有鑒于此，本申請?zhí)岢鲆环NS化握手報文的解析方法，通過接收對端發(fā)送的S化握 手報文，識別出接收到的所述S化握手報文的類型，并基于識別出的所述S化握手報文的類 型解析所述S化握手報文。由于在本申請中不再基于S化會話狀態(tài)來解析報文，而是通過SSL 握手報文的類型來解析S化握手報文，因此，網絡設備不需要多次切換S化會話狀態(tài)、緩存報 文等。本申請在網絡設備當前的S化會話狀態(tài)與接收到的S化握手報文不匹配時，對所述SSL 握手報文的解析效率高。
[0029] 參見圖3,為本申請S化握手報文的解析方法的一個實施例流程圖，該實施例應用 在網絡設備上，包括了 W下步驟：
[0030] 步驟301:接收對端發(fā)送的S化握手報文。
[0031] 在本申請中，所述網絡設備可W包括建立S化會話的本端主機或者對端服務器。因 此，所述網絡設備可W接收來自對端客戶端或者對端服務器發(fā)送的S化握手報文。
[0032] 步驟302:識別接收到的所述S化握手報文的類型。
[0033] 接收到S化握手報文后，網絡設備可W根據所述S化握手報文頭部的字節(jié)特征，識 別出所述S化握手報文的類型。所述S化握手報文的前9個字節(jié)有著特定的格式，所述字節(jié)特 征可W包括所述S化握手報文的特定格式。
[0034] 在一個示例中，所述SSL握手報文的特定格式可W如表1所示(表1僅展示出部分所 述S化握手報文的信息）： 「AAOC1
[0036] 表1
[0037] 表1中，0x16表示所述報文為握手報文，0x0301表示所述報文使用S化協(xié)議，253表 示報文長度，Certif icate Request表示報文類型。因此，由表1可知，當所述S化握手報文如 表1所示時，所述S化握手報文為Certificate Request報文。
[0038] 步驟303:基于識別出的所述S化握手報文的類型解析所述S化握手報文。
[0039] 在本申請中，可W不再基于S化會話狀態(tài)來解析S化握手報文，而是基于S化報文類 型來解析S化握手報文。
[0040] 在識別出接收到的所述S化握手報文的類型后，可W基于識別出的所述S化握手報 文的類型對所述SSL握手報文進行解析。所述網絡設備可W預先為每一種SSL握手報文分別 設置與其報文類型對應的解析函數，當識別出接收到的所述S化握手報文的類型后，所述網 絡設備可W調用預先設置的與S化握手報文的類型對應的解析函數對所述S化握手報文進 行解析。
[0041] 在一個示例中，現有技術中，網絡設備當前的S化會話狀態(tài)與與其對應的解析函數 的對應羊系前W血下夫2所元（夫2中何展元1中部A對脈羊系），
[0042]
[0043] 表 2
[0044] 本申請中，因為可W預先為每一種SSL握手報文分別設置與其對應的解析函數，所 W所述S化握手報文的類型與預先設置的與其對應的解析函數的對應關系可W如下表3所 示(表3中僅展示出部分對應關系）：
[0047]由表2和表3可知，當接收到SSL握手報文時，現有技術是調用與當前的SSL會話狀 態(tài)對應的解析函數解析接收到的SSL握手報文，但本申請是調用與接收到的SSL握手報文的 類型對應的解析函數來解析接收到的報文。
[0048] 在一個示例中，W客戶端為例，現有技術中，假設客戶端當前的S化會話狀態(tài)為 SSL_GET_SERVER_CERT_REQ，則當接收到服務器發(fā)送的S化握手報文后，客戶端會調用與當 前的S化會話狀態(tài)對應的解析函數對接收到的S化握手報文進行解析。因為客戶端當前的 S化會話狀態(tài)為SSL_GET_SERVER_CERT_REQ，所W，由表2可知，客戶端會調用ssl_get_ se;rve;r_ced_req函數對接收到的S化握手報文進行解析。當客戶端接收到的S化握手報文 是Certificate Request報文時，解析可W成功；當客戶端接收到的S化握手報文不是 Certificate Request報文時，則解析失敗。假設客戶端在解析失敗后，發(fā)現接收到的S化握 手報文為Server胎Ilo Done報文，則客戶端需要先將所述Server胎Ilo Done報文緩存， 并將當前的S化會話狀態(tài)切換為SSL_GET_SERVERJ1E1X0_D0肥，然后調用與此S化會話狀態(tài) 對應的解析函數對接收到的報文進行解析。由表2可知，所述解析函數為ssl_get_se;rve;r_ he 1 lo_done,當調用此函數對所述Server He 1 Io Done報文進行解析時，可W解析成功。
[0049] 在本申請中，同樣假設客戶端當前的S化會話狀態(tài)為551^_661'_5?。?1?_〔61?1'_1?69， 則當接收到服務器發(fā)送的S化握手報文后，客戶端可W先根據所述S化握手報文頭部的字節(jié) 特征識別出所述S化握手報文的類型，假設識別出的所述S化握手報文為Certificate Request報文，由表3可知，客戶端可W調用與所述Cedificate Request報文對應的解析函 數ssl_get_se;rve;r_ce;rt_req對所述S化握手報文進行解析，解析可W成功;假設客戶端識 別出的所述S化握手報文不為Ce;rtificate Request報文，如為Server Hello Done報文，由 表3可知，客戶端可W調用與Server Hello Done報文對應的解析函數ssl_get_se;rve;r_ he 1 lo_done對所述握手報文進行解析，解析可W成功。
[0050] 由上述示例可見，當接收到與當前的S化會話狀態(tài)不匹配的S化握手報文時，本申 請不需要如現有技術一樣多次切換S化會話狀態(tài)、緩存報文等。因此，本申請在網絡設備當 前的S化會話狀態(tài)與接收到的S化握手報文不匹配時，可W解決現有技術對接收到的S化握 手報文的解析效率低的問題。
[0051] 需要說明的是，在網絡設備識別出接收到的S化握手報文的類型之后，在根據所述 S化握手報文的類型解析所述S化握手報文之前，可W根據當前的S化會話狀態(tài)判斷所述SSL 握手報文是否為合理報文。當所述S化握手報文為合理報文時，網絡設備可W根據識別出的 所述S化握手報文的類型解析所述S化握手報文；當所述S化握手報文為不合理報文時，網絡 設備可W斷開與對端的S化連接。其中，所述合理報文為符合S化協(xié)議相關內容的報文。
[0052] W客戶端為例，假設客戶端當前的S化會話狀態(tài)為SSL_GET_SERVER_CERT，當接收 到來自服務器發(fā)送的Server Hello報文時，則可W根據客戶端當前的S化會話狀態(tài)判斷出 所述S化握手報文為不滿足S化協(xié)議相關內容的報文。因為按照S化協(xié)議的相關內容，客戶端 只有在完成對Server Hel Io報文的解析之后，才有可能將S化會話狀態(tài)切換至SSL_GET_ SERVER_(ERT，因此，客戶端收到Server HelIo報文后，可W根據其會話狀態(tài)判斷所述S化握 手報文為不符合S化協(xié)議相關內容的報文，即所述S化握手報文為不合理報文。
[0053] 同樣假設客戶端當前的S化會話狀態(tài)為SSL_GET_SERVER_CERT，當接收到來自服務 器發(fā)送的Server Hello Done報文時，客戶端可W根據當前的S化會話狀態(tài)判斷所述S化握 手報文是否為合理報文?？蛻舳水斍暗腟化會話狀態(tài)為SSL_GET_SERVER_CRET_REQ，表示客 戶端想要接收服務器發(fā)送的Cedificate Request報文。根據S化協(xié)議的相關內容，服務器 可W不發(fā)送Ce;rtificate Request報文，而是直接發(fā)送Server Hello Done報文。因此，所述 S化握手報文為合理報文。
[0054] 當接收到的S化握手報文為合理報文時，網絡設備可W對其進行解析。解析成功 后，網絡設備可W判斷當前的S化會話狀態(tài)與所述S化握手報文是否匹配，并可W根據判斷 結果來完成當前S化會話狀態(tài)的切換。其中，在進行S化會話狀態(tài)切換時，如果當前的S化會 話狀態(tài)與所述S化握手報文匹配，則可W將當前的S化會話狀態(tài)切換至下一個S化會話狀態(tài)； 如果當前的S化會話狀態(tài)與所述S化握手報文不匹配，則可W將當前的S化會話狀態(tài)切換為 與所述S化握手報文匹配的S化會話狀態(tài)的下一個S化會話狀態(tài)。
[0055] 本申請?zhí)峁㏒化握手報文的解析方法及裝置，當接收到S化握手報文時，網絡設備 可W先判斷其報文類型，然后調用與所述S化握手報文的類型對應的解析函數解析所述SSL 握手報文。由于在本申請中不再基于S化會話狀態(tài)來解析報文，而是通過S化握手報文的類 型來解析S化握手報文，因此，網絡設備不需要多次切換S化會話狀態(tài)、緩存報文等。故本申 請在網絡設備當前的S化會話狀態(tài)與接收到的S化握手報文不匹配時，對所述S化握手報文 的解析效率高。
[0056] 下面通過具體實施例并結合應用場景圖對W上實施例進行詳細說明：
[0057] 由圖1和圖2可知，客戶端和服務器之間可W按照圖2所示的S化交互流程來建立 S化連接。W客戶端為例，在與服務器建立S化連接的過程中，可W有很多的S化會話狀態(tài)。例 如，客戶端想要向服務器發(fā)送報文W開始建立S化連接時，客戶端當前的S化會話狀態(tài)為 SSL_SEND_CLIENT_肥化0，此會話狀態(tài)為客戶端的初始狀態(tài)。當客戶端當前的S化會話狀態(tài) 為此狀態(tài)時，表示客戶端想要發(fā)送報文。于是，客戶端向服務器發(fā)送Client Hello報文W開 始與服務器建立S化連接。Client Hello報文發(fā)送完成后，客戶端會將S化會話狀態(tài)切換成 當前S化會話狀態(tài)的下一個S化會話狀態(tài)SSL_GET_SERVER_HE化0,此狀態(tài)表示客戶端在等待 服務器端發(fā)送Server Hello報文。服務器在接收到Client Hello報文后，可W向客戶端發(fā) 送Server HelIo報文。
[005引在一個示例中，現有技術中，當客戶端接收到來自服務器發(fā)送的Server Hello報 文時，調用與當前的SSL會話狀態(tài)對應的解析函數對接收到的Server HelIo報文進行解析。 由表2可知，與SSL_GET_SERVER_HELL0對應的解析函數為ssl_get_server_hel Io。因此，客 戶端會調用331_旨日1：_3日1'￥日1'_11日110對接收到的5日1'￥日1'胎110報文進行解析。因為解析函數 831_旨日1：_3日1'￥日1'_11日110與5日1'￥日1'胎110報文相對應，所^客戶端可^解析成功。當客戶端 解析成功后，客戶端可W按照自身的需求將S化會話狀態(tài)切換為SSL_GET_SERVER_CERT，此 狀態(tài)表示客戶端想要接收服務器發(fā)送的包含證書信息的報文即Cedificate報文。服務器 在發(fā)送Server Hel Io報文后，根據SSL協(xié)議的相關內容，可W向客戶端發(fā)送自身的 Certificate報文?？蛻舳私邮盏紺edif icate報文后，調用與當前狀態(tài)SSL_GET_SERVER_ CERT對應的解析函數ssl_get_se;rve;r_ce;rt對Ce;rtif ica1:e報文進行解析。因為解析函數 ssl_get_se;rve;r_ce;rt與Ce;rtificate報文相對應。所W可W解析成功。然后，客戶端可W將 S化會話狀態(tài)切換至當前SSL會話狀態(tài)的下一個SSL會話狀態(tài)SSL_GET_SERVER_CRET_REQ。此 狀態(tài)表示客戶端想要接收來自服務器的C&rtificate Request報文。
[0059]服務器在發(fā)送Cedificate報文之后，可W按照自身的配置，向客戶端發(fā)送 Certificate Request報文，然后再發(fā)送Server胎Ilo Done報文，或者直接發(fā)送Server Hello Done報文。
[0060] 假設，服務器發(fā)送Ce;rtificate報文之后，不發(fā)送Ce;rtificate Request報文，而是 直接發(fā)送Server Hello Done報文。此時，客戶端當前的SSL會話狀態(tài)可W為SSL_GET_ 沈尺￥邸_0?61'_1?69。
[0061] 現有技術中，接收到服務器發(fā)送的Server Hello Done報文后，客戶端調用與當前 的 SSL 會話狀態(tài) SSL_GET_SERVER_CRET_REQ 對應的解析函數 ssl_get_server_cert_req 對 Server Hello Done報文進行解析。因為解析函數ssl_get_se;rve;r_ce;rt_req與Server Hello Done報文不對應，因此，解析失敗。此時，客戶端可W發(fā)現接收到的S化握手報文為 Server胎Ilo Done報文。客戶端將Server Hello Done報文進行緩存，然后，將S化會話狀 態(tài)切換到與Server胎Ilo Done報文對應的SSL會話狀態(tài)SSL_GET_WRVERJffilX0_D0肥，并 調用與會話狀態(tài)SSL_GET_SERVERJffiLL0_D0肥對應的解析函數ssl_get_server_hello_ done對Server胎Ilo Done報文進行解析。因為解析函數ssl_get_se;rve;r_hello_done與 Server胎Ilo Done報文相對應，所W，可W解析成功。由上述現有技術可知，當接收到的 S化握手報文與當前的S化會話狀態(tài)不匹配時，現有技術需要多次切換S化會話狀態(tài)、緩存報 文等，因此，現有技術對所述S化握手報文的解析效率低。
[0062] 本申請中，接收到服務器發(fā)送的Server Hello Done報文后，客戶端可W根據報文 頭部的字節(jié)特征如報文前9個字節(jié)的特定格式識別出接收到的S化握手報文為Server Hello Done報文。然后，客戶端可W根據當前的S化會話狀態(tài)判斷所述S化握手報文是否為 合理報文。根據S化協(xié)議的相關內容，由客戶端當前的S化會話狀態(tài)為SSL_GET_SERVER_ CRET_REQ可知，當接收到的S化握手報文為Server Hello Done報文時，可W判斷所述S化握 手報文為合理報文。然后客戶端可W調用與Server Hello Done報文對應的解析函數ssl_ get_se;rve;r_hello_done對接收到的Server Hello Done報文進行解析。因為解析函數ssl_ get_se;rve;r_hello_done與Server Hello Done報文相對應，所W，可W解析成功。由W上過 程可知，當接收到的S化握手報文與當前的S化會話狀態(tài)不匹配時，本申請不需要多次切換 S化會話狀態(tài)、緩存報文等，因此，本申請對所述S化握手報文的解析效率高。
[0063] 進一步地，本申請中，對接收到的S化握手報文解析成功之后，還可W根據當前的 S化會話狀態(tài)與所述S化握手報文的匹配結果，對S化會話狀態(tài)進行切換。
[0064] 同樣地，W客戶端為例，當接收到的S化握手報文與當前的S化會話狀態(tài)匹配時，客 戶端可W在成功解析所述S化握手報文之后，將S化會話狀態(tài)切換至當前S化會話狀態(tài)的下 一個SSL會話狀態(tài)。
[0065] 在一個示例中，假設客戶端當前的S化會話狀態(tài)為SSL_GET_SERVER_CERT。當接收 到服務器發(fā)送的Cedificate報文時，客戶端可W調用與Cedificate報文對應的解析函數 ssl_get_se;rve;r_ce;rt對Ce;rtif icate報文進行解析。解析成功后，因為Ce;rtif icate報文與 客戶端當前的S化會話狀態(tài)SSL_GET_SERVER_CERT匹配。因此，客戶端可W將S化會話狀態(tài)切 換至當前SSL會話狀態(tài)的下一個SSL會話狀態(tài)SSL_GET_SERVER_CRET_REQ。
[0066] 當接收到的S化握手報文與當前的S化會話狀態(tài)不匹配時，可W將當前的S化會話 狀態(tài)切換為與所述S化握手報文匹配的S化會話狀態(tài)將當前的S化會話狀態(tài)切換為與所述 S化握手報文匹配的S化會話狀態(tài)的下一個S化會話狀態(tài)。
[0067] 在一個示例中，假設客戶端當前的S化會話狀態(tài)為SSL_GET_SERVER_CRET_REQ，當 接收到服務器發(fā)送的Server Hello Done報文時，客戶端可W根據當前的S化會話狀態(tài)判斷 所述S化握手報文是否為合理報文?？蛻舳水斍暗腟化會話狀態(tài)為SSL_GET_SERVER_CRET_ REQ，表示客戶端想要接收服務器發(fā)送的Cedificate Request報文。根據S化協(xié)議的相關內 容，服務器可W不發(fā)送Ce;rtificate Request報文，而是直接發(fā)送Server Hello Done報文。 因此，所述S化握手報文為合理報文。然后客戶端可W調用與Server Hello Done報文對應 的函數對其進行解析。解析成功后，因為Server Hello Done報文與客戶端當前的SSL會話 狀態(tài)SSL_GET_SERVER_CRET_REQ不匹配，因此，客戶端可W將當前的S化會話狀態(tài)切換為與 所述S化握手報文匹配的S化會話狀態(tài)的下一個S化會話狀態(tài)。即，客戶端可W在成功解析 Server胎Ilo Done報文之后，將當前的SSL會話狀態(tài)切換至與Server Hello Done報文匹 配的SSL會話狀態(tài)SSL_GET_SERVERJ1E1X0_D0肥的下一個SSL會話狀態(tài)。所述下一個SSL會話 狀態(tài)可^為551_沈饑'_化16饑'_〔6腳。
[0068] 在一個示例中，假設客戶端當前的S化會話狀態(tài)為SSL_GET_SERVER_CRET_REQ，當 接收到服務器發(fā)送的Server Hello報文時，客戶端可W根據當前的S化會話狀態(tài)判斷所述 S化握手報文是否為合理報文?？蛻舳水斍暗腟化會話狀態(tài)為SSL_GET_SERVER_CRET_REQ，表 示客戶端想要接收服務器發(fā)送的Cedificate Request報文。根據S化協(xié)議的相關內容，只 有在客戶端已經將Server HelIo報文成功解析之后，S化會話狀態(tài)才有可能切換至SSL_ 061'_5?。?1?_〔1?61'_1?69，因此，當客戶端當前的 SSL會話狀態(tài)為SSL_GET_SERVER_CRET_REQ 時，客戶端不應該接收到服務器發(fā)送的Server Hello報文。因此，所述S化握手報文為不合 理報文。此時，客戶端可W不再調用與Server Hello報文對應的函數對其進行解析，而是在 判斷出所述S化握手報文為不合理報文后，斷開與服務器的S化連接。
[0069] 本申請?zhí)峁㏒化握手報文的解析方法及裝置，當接收到S化握手報文時，網絡設備 可W先判斷其報文類型，然后調用與所述S化握手報文的類型對應的解析函數解析所述SSL 握手報文。由于在本申請中不再基于S化會話狀態(tài)來解析報文，而是通過S化握手報文的類 型來解析S化握手報文，因此，網絡設備不需要多次切換S化會話狀態(tài)、緩存報文等。故本申 請在網絡設備當前的S化會話狀態(tài)與接收到的S化握手報文不匹配時，對所述S化握手報文 的解析效率高。
[0070] 與前述S化握手報文的解析方法的實施例相對應，本申請還提供了 S化握手報文的 解析裝置的實施例。
[0071] 本申請S化握手報文的解析裝置的實施例可W應用在網絡設備上。裝置實施例可 W通過軟件實現，也可W通過硬件或者軟硬件結合的方式實現。W軟件實現為例，作為一個 邏輯意義上的裝置，是通過其所在設備的處理器將非易失性存儲器中對應的計算機程序指 令讀取到內存中運行形成的。從硬件層面而言，如圖4所示，為本申請SSL握手報文的解析裝 置所在設備的一種硬件結構圖，除了圖4所示的處理器、內存、網絡接口、W及非易失性存儲 器之外，實施例中裝置所在的設備通常還可W包括其他硬件，如負責處理報文的轉發(fā)忍片 AfrAfr 寸寸O
[0072] 請參考圖5,為本申請SSL握手報文的解析裝置的一個實施例框圖：
[0073] 該裝置可W包括:接收單元510、識別單元520W及解析單元530。
[0074] 接收單元510,用于接收對端發(fā)送的S化握手報文；
[0075] 識別單元520,用于識別接收到的所述S化握手報文的類型；
[0076] 解析單元530，用于基于識別出的所述S化握手報文的類型解析所述S化握手報文。
[0077] 在一個可選的實現方式中，所述識別單元520可W具體用于：
[0078] 基于所述S化握手報文頭部的字節(jié)特征識別所述S化握手報文的類型。
[0079] 在一個可選的實現方式中，所述解析單元530可W具體用于：
[0080] 根據當前的S化會話狀態(tài)判斷所述S化握手報文是否為合理報文；
[0081] 當所述S化握手報文為合理報文時，則基于識別出的所述S化握手報文的類型解析 所述S化握手報文;當所述S化握手報文為不合理報文時，則斷開與對端的S化連接。
[0082] 在一個可選的實現方式中，所述解析單元530可W具體用于：
[0083] 當所述S化握手報文為合理報文時，調用與所述S化握手報文的類型對應的解析函 數解析所述SSL握手報文。
[0084] 在一個可選的實現方式中，所述裝置還可W包括(圖5中未示出）：
[0085] 判斷單元540,用于判斷當前的S化會話狀態(tài)與所述S化握手報文是否匹配；
[0086] 第一切換單元550,用于如果當前的S化會話狀態(tài)匹配所述S化握手報文時，則將當 前的SSL會話狀態(tài)切換至下一個SSL會話狀態(tài)。
[0087] 在另一個可選的實現方式中，所述裝置還可W包括(圖5中未示出）：
[0088] 第二切換單元560,用于如果當前的S化會話狀態(tài)不匹配所述S化握手報文時，將當 前的S化會話狀態(tài)切換為與所述S化握手報文匹配的S化會話狀態(tài)的下一個S化會話狀態(tài)。
[0089] 在一個可選的實現方式中，所述網絡設備可W包括建立S化會話的本端主機或者 對端服務器。
[0090] 上述裝置中各個單元的功能和作用的實現過程具體詳見上述方法中對應步驟的 實現過程，在此不再寶述。
[0091] 對于裝置實施例而言，由于其基本對應于方法實施例，所W相關之處參見方法實 施例的部分說明即可。W上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件 說明的單元可W是或者也可W不是物理上分開的，作為單元顯示的部件可W是或者也可W 不是物理單元，即可W位于一個地方，或者也可W分布到多個網絡單元上。可W根據實際的 需要選擇其中的部分或者全部模塊來實現本申請方案的目的。本領域普通技術人員在不付 出創(chuàng)造性勞動的情況下，即可W理解并實施。
[0092] 在本申請實施例中，當接收到S化握手報文時，網絡設備可W先判斷其報文類型， 然后調用與所述S化握手報文的類型對應的解析函數解析所述S化握手報文。由于在本申請 中不再基于S化會話狀態(tài)來解析報文，而是通過S化握手報文的類型來解析S化握手報文，因 此，網絡設備不需要多次切換S化會話狀態(tài)、緩存報文等。故本申請在網絡設備當前的S化會 話狀態(tài)與接收到的S化握手報文不匹配時，對所述S化握手報文的解析效率高。
[0093] W上所述僅為本申請的較佳實施例而已，并不用W限制本申請，凡在本申請的精 神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本申請保護的范圍之內。
【主權項】
1. 一種安全套接層SSL握手報文的解析方法，其特征在于，所述方法應用于網絡設備 上，所述方法包括： 接收對端發(fā)送的SSL握手報文； 識別接收到的所述SSL握手報文的類型； 基于識別出的所述SSL握手報文的類型解析所述SSL握手報文。2. 根據權利要求1所述的方法，其特征在于，所述識別接收到的所述SSL握手報文的類 型包括： 基于所述SSL握手報文頭部的字節(jié)特征識別所述SSL握手報文的類型。3. 根據權利要求1所述的方法，其特征在于，所述基于識別出的所述SSL握手報文的類 型解析所述SSL握手報文，包括： 根據當前的SSL會話狀態(tài)判斷所述SSL握手報文是否為合理報文； 當所述SSL握手報文為合理報文時，則基于識別出的所述SSL握手報文的類型解析所述 SSL握手報文;當所述SSL握手報文為不合理報文時，則斷開與對端的SSL連接。4. 根據權利要求3所述的方法，其特征在于，所述基于識別出的所述SSL握手報文的類 型解析所述SSL握手報文包括： 當所述SSL握手報文為合理報文時，調用與所述SSL握手報文的類型對應的解析函數解 析所述SSL握手報文。5. 根據權利要求4所述的方法，其特征在于，所述方法還包括： 判斷當前的SSL會話狀態(tài)與所述SSL握手報文是否匹配； 如果當前的SSL會話狀態(tài)匹配所述SSL握手報文時，則將當前的SSL會話狀態(tài)切換至下 一個SSL會話狀態(tài)。6. 根據權利要求5所述的方法，其特征在于，所述方法還包括： 如果當前的SSL會話狀態(tài)不匹配所述SSL握手報文時，將當前的SSL會話狀態(tài)切換為與 所述SSL握手報文匹配的SSL會話狀態(tài)的下一個SSL會話狀態(tài)。7. 根據權利要求1所述的方法，其特征在于，所述網絡設備包括建立SSL會話的本端主 機或者對端服務器。8. -種SSL握手報文的解析裝置，其特征在于，所述裝置應用于網絡設備上，所述裝置 包括： 接收單元，用于接收對端發(fā)送的SSL握手報文； 識別單元，用于識別接收到的所述SSL握手報文的類型； 解析單元，用于基于識別出的所述SSL握手報文的類型解析所述SSL握手報文。9. 根據權利要求8所述的裝置，其特征在于，所述識別單元具體用于： 基于所述SSL握手報文頭部的字節(jié)特征識別所述SSL握手報文的類型。10. 根據權利要求8所述的裝置，其特征在于，所述解析單元具體用于： 根據當前的SSL會話狀態(tài)判斷所述SSL握手報文是否為合理報文； 當所述SSL握手報文為合理報文時，則基于識別出的所述SSL握手報文的類型解析所述 SSL握手報文;當所述SSL握手報文為不合理報文時，則斷開與對端的SSL連接。11. 根據權利要求10所述的裝置，其特征在于，所述解析單元具體用于： 當所述SSL握手報文為合理報文時，調用與所述SSL握手報文的類型對應的解析函數解 析所述SSL握手報文。12. 根據權利要求11所述的裝置，其特征在于，所述裝置還包括： 判斷單元，用于判斷當前的SSL會話狀態(tài)與所述SSL握手報文是否匹配； 第一切換單元，用于如果當前的SSL會話狀態(tài)匹配所述SSL握手報文時，則將當前的SSL 會話狀態(tài)切換至下一個SSL會話狀態(tài)。13. 根據權利要求12所述的裝置，其特征在于，所述裝置還包括： 第二切換單元，用于如果當前的SSL會話狀態(tài)不匹配所述SSL握手報文時，將當前的SSL 會話狀態(tài)切換為與所述SSL握手報文匹配的SSL會話狀態(tài)的下一個SSL會話狀態(tài)。14. 根據權利要求8所述的裝置，其特征在于，所述網絡設備包括建立SSL會話的本端主 機或者對端服務器。
【文檔編號】H04L29/06GK105939317SQ201510807374
【公開日】2016年9月14日
【申請日】2015年11月19日
【發(fā)明人】陳嘉園
【申請人】杭州迪普科技有限公司