CN105939317A - Ssl握手报文的解析方法及装置 - Google Patents

Abstract

本申请提供一种安全套接层SSL握手报文的解析方法及装置，所述方法包括：接收对端发送的SSL握手报文；识别接收到的所述SSL握手报文的类型；基于识别出的所述SSL握手报文的类型解析所述SSL握手报文。应用本申请不需要多次切换当前的SSL会话状态、缓存报文等，因此网络设备在当前的SSL会话状态与接收到的SSL握手报文不匹配时，对所述SSL握手报文的解析效率高。

Description

SSL握手报文的解析方法及装置

技术领域

本申请涉及网络通信技术领域，尤其涉及SSL握手报文的解析方法及装置。

背景技术

为了提高网络数据传输的安全性，越来越多的应用、网站开始使用SSL(Secure Sockets Layer，安全套接层)协议，广泛应用的有电子商务、网上银行等领域。SSL协议是一个安全协议，为基于TCP的应用层协议提供安全连接，如SSL协议可以为HTTP协议提供安全连接。在使用SSL协议进行信息交流之前，网络设备之间需要通过SSL握手协商完成对彼此的认证。

现有技术中，网络设备以当前的SSL会话状态为基础对SSL握手报文进行解析。当接收到SSL握手报文时，网络设备调用与当前的SSL会话状态对应的解析函数对该SSL握手报文进行解析。如果该SSL握手报文与当前的SSL会话状态不匹配，则会出现解析错误，此时，网络设备不得不对该SSL握手报文进行缓存，并切换当前的SSL会话状态，然后对该SSL握手报文重新进行解析。由以上过程可知，当接收到的SSL握手报文与当前的SSL会话状态不匹配时，现有技术对该SSL握手报文的解析效率低。

发明内容

有鉴于此，本申请提供一种SSL握手报文的解析方法及装置，来解决现有技术中当网络设备当前的SSL会话状态与接收到的SSL握手报文不匹配时对该SSL握手报文的解析效率低的问题。

具体地，本申请是通过如下技术方案实现的：

根据本申请实施例的第一方面，提供一种SSL握手报文的解析方法，所述方法应用于网络设备上，所述方法包括：

接收对端发送的SSL握手报文；

识别接收到的所述SSL握手报文的类型；

基于识别出的所述SSL握手报文的类型解析所述SSL握手报文。

根据本申请实施例的第二方面，提供一种解析SSL握手报文的装置，所述装置应用于网络设备上，所述装置包括：

接收单元，用于接收对端发送的SSL握手报文；

识别单元，用于识别接收到的所述SSL握手报文的类型；

解析单元，用于基于识别出的所述SSL握手报文的类型解析所述SSL握手报文。

本申请提供SSL握手报文的解析方法及装置，当接收到SSL握手报文时，网络设备可以先判断所述SSL握手报文的类型，然后调用与所述SSL握手报文的类型对应的解析函数解析所述SSL握手报文。在本申请中，由于网络设备不再基于SSL会话状态来解析报文，而是基于SSL握手报文的类型来解析报文，因此可以提升对所述SSL握手报文的解析效率。

附图说明

图1是应用本申请实施例实现SSL握手报文解析的一个应用场景示意图；

图2是网络设备之间建立SSL连接的一个交互流程图；

图3是本申请SSL握手报文的解析方法的一个实施例流程图；

图4是本申请SSL握手报文的解析装置所在设备的一种硬件结构图；

图5是本申请SSL握手报文的解析装置的一个实施例框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

参见图1，为应用本申请实施例实现SSL握手报文解析的一个应用场景示意图。为了加强网络数据的安全性，客户端和服务器之间可以建立SSL连接。建立SSL连接的交互流程可以如图2所示(图2仅展示出部分交互流程)，由图2可知，在进行SSL握手协商时，有些SSL握手报文是必不可少的(如图1中标识为Required的报文)，如开始会话连接的Client Hello报文。但是，有些握手报文是可以根据网络设备的自身需要选择是否发送至与其进行SSL握手协商的对端的(如图1中标识为Optional的报文)，如包含自身证书信息的Certificate报文。

以客户端为例，客户端的初始SSL会话状态为SSL_SEND_CLIENT_HELLO，此状态表示客户端可以向对端即服务器发送SSL握手报文。此时，客户端的SSL状态机发现自己处于SSL_SEND_CLIENT_HELLO的状态，于是，执行向服务器发送Client Hello报文的操作。所述Client Hello报文发送成功后，客户端将当前的SSL会话状态切换至下一个SSL会话状态SSL_GET_SERVER_HELLO，此状态表示客户端在等待来自服务器的ServerHello报文。

服务器接收到来自客户端的Client Hello报文后，根据SSL协议的相关内容向客户端发送Server Hello报文，客户端接收并解析所述Server Hello报文后，将当前的SSL会话状态切换至SSL_GET_SERVER_CERT，此状态表示客户端希望接收服务器发来的证书，因此，此时，客户端在等待服务器发送包含证书信息的报文。

服务器在发送Server Hello报文后，根据SSL协议的相关内容，服务器立刻发送包含自身证书信息的报文即Certificate报文。客户端接收并解析所述Certificate报文，然后将状态切换至SSL_GET_SERVER_HELLO_DONE，以等待服务器发送Server Hello Done报文。

但是，服务器发送Server Hello Done报文后，按照自身的配置，可能先向客户端发送Certificate Request报文，然后再发送Server Hello Done报文，或者直接发送Server Hello Done报文。因为，客户端当前的SSL会话状态为SSL_GET_SERVER_HELLO_DONE，表示客户端想要接收Server HelloDone报文。所以，当客户端接收到来自服务器的Certificate Request报文时，因为客户端的SSL状态机发现自己处于SSL_GET_SERVER_HELLO_DONE状态，因此，客户端的SSL状态机会采用与此SSL会话状态对应的解析函数对接收到的Certificate Request报文进行解析。因为客户端采用的解析函数与报文的类型不对应，因此，解析的结果自然是错误的。解析错误之后，客户端发现此握手报文为Certificate Request报文，于是，客户端将此握手报文缓存，并把当前的SSL会话状态切换至SSL_GET_SERVER_CRET_REQ，然后采用与此SSL会话状态对应的解析函数对Certificate Request报文进行解析，此解析过程可以成功。由上述过程可知，在现有技术中，通常是基于SSL会话状态来解析SSL握手报文的，因此，在调用与当前的SSL会话状态对应的解析函数对该SSL握手报文进行解析时，如果该SSL握手报文与当前的SSL会话状态不匹配，则会出现解析错误，此时，网络设备不得不对该握手报文进行缓存，并切换会话状态重新进行解析，因此当接收到的SSL握手报文与当前的SSL会话状态不匹配时，现有技术对该SSL握手报文的解析效率低。

有鉴于此，本申请提出一种SSL握手报文的解析方法，通过接收对端发送的SSL握手报文，识别出接收到的所述SSL握手报文的类型，并基于识别出的所述SSL握手报文的类型解析所述SSL握手报文。由于在本申请中不再基于SSL会话状态来解析报文，而是通过SSL握手报文的类型来解析SSL握手报文，因此，网络设备不需要多次切换SSL会话状态、缓存报文等。本申请在网络设备当前的SSL会话状态与接收到的SSL握手报文不匹配时，对所述SSL握手报文的解析效率高。

参见图3，为本申请SSL握手报文的解析方法的一个实施例流程图，该实施例应用在网络设备上，包括了以下步骤：

步骤301：接收对端发送的SSL握手报文。

在本申请中，所述网络设备可以包括建立SSL会话的本端主机或者对端服务器。因此，所述网络设备可以接收来自对端客户端或者对端服务器发送的SSL握手报文。

步骤302：识别接收到的所述SSL握手报文的类型。

接收到SSL握手报文后，网络设备可以根据所述SSL握手报文头部的字节特征，识别出所述SSL握手报文的类型。所述SSL握手报文的前9个字节有着特定的格式，所述字节特征可以包括所述SSL握手报文的特定格式。

在一个示例中，所述SSL握手报文的特定格式可以如表1所示(表1仅展示出部分所述SSL握手报文的信息)：

Content Type	Version	Length	Handshake Protocol
				0x16	0x0301	253	Certificate Request

表1

表1中，0x16表示所述报文为握手报文，0x0301表示所述报文使用SSL协议，253表示报文长度，Certificate Request表示报文类型。因此，由表1可知，当所述SSL握手报文如表1所示时，所述SSL握手报文为CertificateRequest报文。

步骤303：基于识别出的所述SSL握手报文的类型解析所述SSL握手报文。

在本申请中，可以不再基于SSL会话状态来解析SSL握手报文，而是基于SSL报文类型来解析SSL握手报文。

在识别出接收到的所述SSL握手报文的类型后，可以基于识别出的所述SSL握手报文的类型对所述SSL握手报文进行解析。所述网络设备可以预先为每一种SSL握手报文分别设置与其报文类型对应的解析函数，当识别出接收到的所述SSL握手报文的类型后，所述网络设备可以调用预先设置的与SSL握手报文的类型对应的解析函数对所述SSL握手报文进行解析。

在一个示例中，现有技术中，网络设备当前的SSL会话状态与与其对应的解析函数的对应关系可以如下表2所示(表2中仅展示出部分对应关系)：

表2

本申请中，因为可以预先为每一种SSL握手报文分别设置与其对应的解析函数，所以所述SSL握手报文的类型与预先设置的与其对应的解析函数的对应关系可以如下表3所示(表3中仅展示出部分对应关系)：

SSL握手报文的类型	对应的解析函数
		Client Hello	ssl_send_client_hello
Server Hello	ssl_get_server_hello
		Certificate	ssl_get_server_cert
Certificate Request	ssl_get_server_cert_req
		Server Hello Done	ssl_get_server_hello_done

表3

由表2和表3可知，当接收到SSL握手报文时，现有技术是调用与当前的SSL会话状态对应的解析函数解析接收到的SSL握手报文，但本申请是调用与接收到的SSL握手报文的类型对应的解析函数来解析接收到的报文。

在一个示例中，以客户端为例，现有技术中，假设客户端当前的SSL会话状态为SSL_GET_SERVER_CERT_REQ，则当接收到服务器发送的SSL握手报文后，客户端会调用与当前的SSL会话状态对应的解析函数对接收到的SSL握手报文进行解析。因为客户端当前的SSL会话状态为SSL_GET_SERVER_CERT_REQ，所以，由表2可知，客户端会调用ssl_get_server_cert_req函数对接收到的SSL握手报文进行解析。当客户端接收到的SSL握手报文是Certificate Request报文时，解析可以成功；当客户端接收到的SSL握手报文不是Certificate Request报文时，则解析失败。假设客户端在解析失败后，发现接收到的SSL握手报文为Server HelloDone报文，则客户端需要先将所述Server Hello Done报文缓存，并将当前的SSL会话状态切换为SSL_GET_SERVER_HELLO_DONE，然后调用与此SSL会话状态对应的解析函数对接收到的报文进行解析。由表2可知，所述解析函数为ssl_get_server_hello_done,当调用此函数对所述Server Hello Done报文进行解析时，可以解析成功。

在本申请中，同样假设客户端当前的SSL会话状态为SSL_GET_SERVER_CERT_REQ，则当接收到服务器发送的SSL握手报文后，客户端可以先根据所述SSL握手报文头部的字节特征识别出所述SSL握手报文的类型，假设识别出的所述SSL握手报文为Certificate Request报文，由表3可知，客户端可以调用与所述Certificate Request报文对应的解析函数ssl_get_server_cert_req对所述SSL握手报文进行解析，解析可以成功；假设客户端识别出的所述SSL握手报文不为Certificate Request报文，如为Server Hello Done报文，由表3可知，客户端可以调用与Server HelloDone报文对应的解析函数ssl_get_server_hello_done对所述握手报文进行解析，解析可以成功。

由上述示例可见，当接收到与当前的SSL会话状态不匹配的SSL握手报文时，本申请不需要如现有技术一样多次切换SSL会话状态、缓存报文等。因此，本申请在网络设备当前的SSL会话状态与接收到的SSL握手报文不匹配时，可以解决现有技术对接收到的SSL握手报文的解析效率低的问题。

需要说明的是，在网络设备识别出接收到的SSL握手报文的类型之后，在根据所述SSL握手报文的类型解析所述SSL握手报文之前，可以根据当前的SSL会话状态判断所述SSL握手报文是否为合理报文。当所述SSL握手报文为合理报文时，网络设备可以根据识别出的所述SSL握手报文的类型解析所述SSL握手报文；当所述SSL握手报文为不合理报文时，网络设备可以断开与对端的SSL连接。其中，所述合理报文为符合SSL协议相关内容的报文。

以客户端为例，假设客户端当前的SSL会话状态为SSL_GET_SERVER_CERT，当接收到来自服务器发送的Server Hello报文时，则可以根据客户端当前的SSL会话状态判断出所述SSL握手报文为不满足SSL协议相关内容的报文。因为按照SSL协议的相关内容，客户端只有在完成对Server Hello报文的解析之后，才有可能将SSL会话状态切换至SSL_GET_SERVER_CERT，因此，客户端收到Server Hello报文后，可以根据其会话状态判断所述SSL握手报文为不符合SSL协议相关内容的报文，即所述SSL握手报文为不合理报文。

同样假设客户端当前的SSL会话状态为SSL_GET_SERVER_CERT，当接收到来自服务器发送的Server Hello Done报文时，客户端可以根据当前的SSL会话状态判断所述SSL握手报文是否为合理报文。客户端当前的SSL会话状态为SSL_GET_SERVER_CRET_REQ，表示客户端想要接收服务器发送的Certificate Request报文。根据SSL协议的相关内容，服务器可以不发送Certificate Request报文，而是直接发送Server Hello Done报文。因此，所述SSL握手报文为合理报文。

当接收到的SSL握手报文为合理报文时，网络设备可以对其进行解析。解析成功后，网络设备可以判断当前的SSL会话状态与所述SSL握手报文是否匹配，并可以根据判断结果来完成当前SSL会话状态的切换。其中，在进行SSL会话状态切换时，如果当前的SSL会话状态与所述SSL握手报文匹配，则可以将当前的SSL会话状态切换至下一个SSL会话状态；如果当前的SSL会话状态与所述SSL握手报文不匹配，则可以将当前的SSL会话状态切换为与所述SSL握手报文匹配的SSL会话状态的下一个SSL会话状态。

本申请提供SSL握手报文的解析方法及装置，当接收到SSL握手报文时，网络设备可以先判断其报文类型，然后调用与所述SSL握手报文的类型对应的解析函数解析所述SSL握手报文。由于在本申请中不再基于SSL会话状态来解析报文，而是通过SSL握手报文的类型来解析SSL握手报文，因此，网络设备不需要多次切换SSL会话状态、缓存报文等。故本申请在网络设备当前的SSL会话状态与接收到的SSL握手报文不匹配时，对所述SSL握手报文的解析效率高。

下面通过具体实施例并结合应用场景图对以上实施例进行详细说明：

由图1和图2可知，客户端和服务器之间可以按照图2所示的SSL交互流程来建立SSL连接。以客户端为例，在与服务器建立SSL连接的过程中，可以有很多的SSL会话状态。例如，客户端想要向服务器发送报文以开始建立SSL连接时，客户端当前的SSL会话状态为SSL_SEND_CLIENT_HELLO，此会话状态为客户端的初始状态。当客户端当前的SSL会话状态为此状态时，表示客户端想要发送报文。于是，客户端向服务器发送Client Hello报文以开始与服务器建立SSL连接。Client Hello报文发送完成后，客户端会将SSL会话状态切换成当前SSL会话状态的下一个SSL会话状态SSL_GET_SERVER_HELLO，此状态表示客户端在等待服务器端发送ServerHello报文。服务器在接收到Client Hello报文后，可以向客户端发送ServerHello报文。

在一个示例中，现有技术中，当客户端接收到来自服务器发送的ServerHello报文时，调用与当前的SSL会话状态对应的解析函数对接收到的ServerHello报文进行解析。由表2可知，与SSL_GET_SERVER_HELLO对应的解析函数为ssl_get_server_hello。因此，客户端会调用ssl_get_server_hello对接收到的Server Hello报文进行解析。因为解析函数ssl_get_server_hello与Server Hello报文相对应，所以客户端可以解析成功。当客户端解析成功后，客户端可以按照自身的需求将SSL会话状态切换为SSL_GET_SERVER_CERT，此状态表示客户端想要接收服务器发送的包含证书信息的报文即Certificate报文。服务器在发送Server Hello报文后，根据SSL协议的相关内容，可以向客户端发送自身的Certificate报文。客户端接收到Certificate报文后，调用与当前状态SSL_GET_SERVER_CERT对应的解析函数ssl_get_server_cert对Certificate报文进行解析。因为解析函数ssl_get_server_cert与Certificate报文相对应。所以可以解析成功。然后，客户端可以将SSL会话状态切换至当前SSL会话状态的下一个SSL会话状态SSL_GET_SERVER_CRET_REQ。此状态表示客户端想要接收来自服务器的Certificate Request报文。

服务器在发送Certificate报文之后，可以按照自身的配置，向客户端发送Certificate Request报文，然后再发送Server Hello Done报文，或者直接发送Server Hello Done报文。

假设，服务器发送Certificate报文之后，不发送Certificate Request报文，而是直接发送Server Hello Done报文。此时，客户端当前的SSL会话状态可以为SSL_GET_SERVER_CRET_REQ。

现有技术中，接收到服务器发送的Server Hello Done报文后，客户端调用与当前的SSL会话状态SSL_GET_SERVER_CRET_REQ对应的解析函数ssl_get_server_cert_req对Server Hello Done报文进行解析。因为解析函数ssl_get_server_cert_req与Server Hello Done报文不对应，因此，解析失败。此时，客户端可以发现接收到的SSL握手报文为Server Hello Done报文。客户端将Server Hello Done报文进行缓存，然后，将SSL会话状态切换到与Server Hello Done报文对应的SSL会话状态SSL_GET_SERVER_HELLO_DONE，并调用与会话状态SSL_GET_SERVER_HELLO_DONE对应的解析函数ssl_get_server_hello_done对Server Hello Done报文进行解析。因为解析函数ssl_get_server_hello_done与Server Hello Done报文相对应，所以，可以解析成功。由上述现有技术可知，当接收到的SSL握手报文与当前的SSL会话状态不匹配时，现有技术需要多次切换SSL会话状态、缓存报文等，因此，现有技术对所述SSL握手报文的解析效率低。

本申请中，接收到服务器发送的Server Hello Done报文后，客户端可以根据报文头部的字节特征如报文前9个字节的特定格式识别出接收到的SSL握手报文为Server Hello Done报文。然后，客户端可以根据当前的SSL会话状态判断所述SSL握手报文是否为合理报文。根据SSL协议的相关内容，由客户端当前的SSL会话状态为SSL_GET_SERVER_CRET_REQ可知，当接收到的SSL握手报文为Server Hello Done报文时，可以判断所述SSL握手报文为合理报文。然后客户端可以调用与Server Hello Done报文对应的解析函数ssl_get_server_hello_done对接收到的Server Hello Done报文进行解析。因为解析函数ssl_get_server_hello_done与Server Hello Done报文相对应，所以，可以解析成功。由以上过程可知，当接收到的SSL握手报文与当前的SSL会话状态不匹配时，本申请不需要多次切换SSL会话状态、缓存报文等，因此，本申请对所述SSL握手报文的解析效率高。

进一步地，本申请中，对接收到的SSL握手报文解析成功之后，还可以根据当前的SSL会话状态与所述SSL握手报文的匹配结果，对SSL会话状态进行切换。

同样地，以客户端为例，当接收到的SSL握手报文与当前的SSL会话状态匹配时，客户端可以在成功解析所述SSL握手报文之后，将SSL会话状态切换至当前SSL会话状态的下一个SSL会话状态。

在一个示例中，假设客户端当前的SSL会话状态为SSL_GET_SERVER_CERT。当接收到服务器发送的Certificate报文时，客户端可以调用与Certificate报文对应的解析函数ssl_get_server_cert对Certificate报文进行解析。解析成功后，因为Certificate报文与客户端当前的SSL会话状态SSL_GET_SERVER_CERT匹配。因此，客户端可以将SSL会话状态切换至当前SSL会话状态的下一个SSL会话状态SSL_GET_SERVER_CRET_REQ。

当接收到的SSL握手报文与当前的SSL会话状态不匹配时，可以将当前的SSL会话状态切换为与所述SSL握手报文匹配的SSL会话状态将当前的SSL会话状态切换为与所述SSL握手报文匹配的SSL会话状态的下一个SSL会话状态。

在一个示例中，假设客户端当前的SSL会话状态为SSL_GET_SERVER_CRET_REQ，当接收到服务器发送的Server Hello Done报文时，客户端可以根据当前的SSL会话状态判断所述SSL握手报文是否为合理报文。客户端当前的SSL会话状态为SSL_GET_SERVER_CRET_REQ，表示客户端想要接收服务器发送的Certificate Request报文。根据SSL协议的相关内容，服务器可以不发送Certificate Request报文，而是直接发送ServerHello Done报文。因此，所述SSL握手报文为合理报文。然后客户端可以调用与Server Hello Done报文对应的函数对其进行解析。解析成功后，因为Server Hello Done报文与客户端当前的SSL会话状态SSL_GET_SERVER_CRET_REQ不匹配，因此，客户端可以将当前的SSL会话状态切换为与所述SSL握手报文匹配的SSL会话状态的下一个SSL会话状态。即，客户端可以在成功解析Server Hello Done报文之后，将当前的SSL会话状态切换至与Server Hello Done报文匹配的SSL会话状态SSL_GET_SERVER_HELLO_DONE的下一个SSL会话状态。所述下一个SSL会话状态可以为SSL_SENT_CLIENT_CERT。

在一个示例中，假设客户端当前的SSL会话状态为SSL_GET_SERVER_CRET_REQ，当接收到服务器发送的Server Hello报文时，客户端可以根据当前的SSL会话状态判断所述SSL握手报文是否为合理报文。客户端当前的SSL会话状态为SSL_GET_SERVER_CRET_REQ，表示客户端想要接收服务器发送的Certificate Request报文。根据SSL协议的相关内容，只有在客户端已经将Server Hello报文成功解析之后，SSL会话状态才有可能切换至SSL_GET_SERVER_CRET_REQ，因此，当客户端当前的SSL会话状态为SSL_GET_SERVER_CRET_REQ时，客户端不应该接收到服务器发送的ServerHello报文。因此，所述SSL握手报文为不合理报文。此时，客户端可以不再调用与Server Hello报文对应的函数对其进行解析，而是在判断出所述SSL握手报文为不合理报文后，断开与服务器的SSL连接。

本申请提供SSL握手报文的解析方法及装置，当接收到SSL握手报文时，网络设备可以先判断其报文类型，然后调用与所述SSL握手报文的类型对应的解析函数解析所述SSL握手报文。由于在本申请中不再基于SSL会话状态来解析报文，而是通过SSL握手报文的类型来解析SSL握手报文，因此，网络设备不需要多次切换SSL会话状态、缓存报文等。故本申请在网络设备当前的SSL会话状态与接收到的SSL握手报文不匹配时，对所述SSL握手报文的解析效率高。

与前述SSL握手报文的解析方法的实施例相对应，本申请还提供了SSL握手报文的解析装置的实施例。

本申请SSL握手报文的解析装置的实施例可以应用在网络设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请SSL握手报文的解析装置所在设备的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的设备通常还可以包括其他硬件，如负责处理报文的转发芯片等等。

请参考图5，为本申请SSL握手报文的解析装置的一个实施例框图：

该装置可以包括：接收单元510、识别单元520以及解析单元530。

接收单元510，用于接收对端发送的SSL握手报文；

识别单元520，用于识别接收到的所述SSL握手报文的类型；

解析单元530，用于基于识别出的所述SSL握手报文的类型解析所述SSL握手报文。

在一个可选的实现方式中，所述识别单元520可以具体用于：

基于所述SSL握手报文头部的字节特征识别所述SSL握手报文的类型。

在一个可选的实现方式中，所述解析单元530可以具体用于：

根据当前的SSL会话状态判断所述SSL握手报文是否为合理报文；

当所述SSL握手报文为合理报文时，则基于识别出的所述SSL握手报文的类型解析所述SSL握手报文；当所述SSL握手报文为不合理报文时，则断开与对端的SSL连接。

在一个可选的实现方式中，所述解析单元530可以具体用于：

当所述SSL握手报文为合理报文时，调用与所述SSL握手报文的类型对应的解析函数解析所述SSL握手报文。

在一个可选的实现方式中，所述装置还可以包括(图5中未示出)：

判断单元540，用于判断当前的SSL会话状态与所述SSL握手报文是否匹配；

第一切换单元550，用于如果当前的SSL会话状态匹配所述SSL握手报文时，则将当前的SSL会话状态切换至下一个SSL会话状态。

在另一个可选的实现方式中，所述装置还可以包括(图5中未示出)：

第二切换单元560，用于如果当前的SSL会话状态不匹配所述SSL握手报文时，将当前的SSL会话状态切换为与所述SSL握手报文匹配的SSL会话状态的下一个SSL会话状态。

在一个可选的实现方式中，所述网络设备可以包括建立SSL会话的本端主机或者对端服务器。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

在本申请实施例中，当接收到SSL握手报文时，网络设备可以先判断其报文类型，然后调用与所述SSL握手报文的类型对应的解析函数解析所述SSL握手报文。由于在本申请中不再基于SSL会话状态来解析报文，而是通过SSL握手报文的类型来解析SSL握手报文，因此，网络设备不需要多次切换SSL会话状态、缓存报文等。故本申请在网络设备当前的SSL会话状态与接收到的SSL握手报文不匹配时，对所述SSL握手报文的解析效率高。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (14)

1.一种安全套接层SSL握手报文的解析方法，其特征在于，所述方法应用于网络设备上,所述方法包括：

接收对端发送的SSL握手报文；

识别接收到的所述SSL握手报文的类型；

基于识别出的所述SSL握手报文的类型解析所述SSL握手报文。

2.根据权利要求1所述的方法，其特征在于，所述识别接收到的所述SSL握手报文的类型包括：

基于所述SSL握手报文头部的字节特征识别所述SSL握手报文的类型。

3.根据权利要求1所述的方法，其特征在于，所述基于识别出的所述SSL握手报文的类型解析所述SSL握手报文，包括：

根据当前的SSL会话状态判断所述SSL握手报文是否为合理报文；

当所述SSL握手报文为合理报文时，则基于识别出的所述SSL握手报文的类型解析所述SSL握手报文；当所述SSL握手报文为不合理报文时，则断开与对端的SSL连接。

4.根据权利要求3所述的方法，其特征在于，所述基于识别出的所述SSL握手报文的类型解析所述SSL握手报文包括：

当所述SSL握手报文为合理报文时，调用与所述SSL握手报文的类型对应的解析函数解析所述SSL握手报文。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

判断当前的SSL会话状态与所述SSL握手报文是否匹配；

如果当前的SSL会话状态匹配所述SSL握手报文时，则将当前的SSL会话状态切换至下一个SSL会话状态。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

如果当前的SSL会话状态不匹配所述SSL握手报文时，将当前的SSL会话状态切换为与所述SSL握手报文匹配的SSL会话状态的下一个SSL会话状态。

7.根据权利要求1所述的方法，其特征在于，所述网络设备包括建立SSL会话的本端主机或者对端服务器。

8.一种SSL握手报文的解析装置，其特征在于，所述装置应用于网络设备上,所述装置包括：

接收单元，用于接收对端发送的SSL握手报文；

识别单元，用于识别接收到的所述SSL握手报文的类型；

解析单元，用于基于识别出的所述SSL握手报文的类型解析所述SSL握手报文。

9.根据权利要求8所述的装置，其特征在于，所述识别单元具体用于：

基于所述SSL握手报文头部的字节特征识别所述SSL握手报文的类型。

10.根据权利要求8所述的装置，其特征在于，所述解析单元具体用于：

根据当前的SSL会话状态判断所述SSL握手报文是否为合理报文；

当所述SSL握手报文为合理报文时，则基于识别出的所述SSL握手报文的类型解析所述SSL握手报文；当所述SSL握手报文为不合理报文时，则断开与对端的SSL连接。

11.根据权利要求10所述的装置，其特征在于，所述解析单元具体用于：

当所述SSL握手报文为合理报文时，调用与所述SSL握手报文的类型对应的解析函数解析所述SSL握手报文。

12.根据权利要求11所述的装置，其特征在于，所述装置还包括：

判断单元，用于判断当前的SSL会话状态与所述SSL握手报文是否匹配；

第一切换单元，用于如果当前的SSL会话状态匹配所述SSL握手报文时，则将当前的SSL会话状态切换至下一个SSL会话状态。

13.根据权利要求12所述的装置，其特征在于，所述装置还包括：

第二切换单元，用于如果当前的SSL会话状态不匹配所述SSL握手报文时，将当前的SSL会话状态切换为与所述SSL握手报文匹配的SSL会话状态的下一个SSL会话状态。

14.根据权利要求8所述的装置，其特征在于，所述网络设备包括建立SSL会话的本端主机或者对端服务器。