CN103618726A - 一种基于https协议实现移动数据业务识别的方法 - Google Patents

Abstract

本发明提出了一种基于HTTPS协议实现移动数据业务识别的方法，其特征在于，包括如下步骤：第一步，以TCP会话为单位缓存数据，首先完成协议识别，如果是Handshake协议，则根据Handshake Type识别Client Hello消息和Certificate消息；第二步，根据识别出的Client Hello消息和Certificate消息，提取相应的HOST信息；第三步，基于提取出的HOST信息，完成业务类型识别。本发明可以以主动方式实现HTTPS业务类型识别，即通过对HTTPS方式的SSL/TLS各版本协议握手阶段实现HOST提取，并通过预设的HOST与业务类型对应表可扩展得到业务类型，有效提升业务识别广度。

Description

一种基于HTTPS协议实现移动数据业务识别的方法

技术领域

本发明涉及信令监测技术领域，特别涉及中国移动、中国联通、中国电信所属的GSM、GPRS、WCDMA、CDMA20001xEV-DO运营支撑系统、信令监测系统技术领域。

背景技术

随着移动互联网的迅猛发展，移动数据应用更加丰富，基于HTTPS技术的应用越来越普遍，根据2013年1-6月份移动数据流量统计结果，运营商约10%的流量为HTTPS应用产生。

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

SSL(Secure Sockets Layer安全套接层),及其继任者传输层安全(Transport Layer Security，TLS)是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。

现阶段移动互联网SSL应用协议以SSL、SSLV3、TLSV1、TLSV1.2为主，常用TCP端口为：443。

由于HTTPS技术对应用层做了加密处理，因此无法象解析HTTP协议一样，直接解析出应用层URL、HOST等信息。因此，对移动数据业务识别造成了影响。

由于SSL/TLS协议在握手阶段也可能包含域名信息，通过此类信息也可实现业务识别。现阶段针对SSL/TLS承载的数据业务识别，采用对已知业务被动识别的方法，即针对所有端口为443的TCP数据包，逐包检测是否包含预设字符串来实现。例如，识别“陌陌”业务，通过在所有源目的端口为443的TCP数据包中过滤包含字符串为“.immomo.com”的流量来实现业务识别。

现有技术中存在着如下缺陷：（1）目前针对HTTPS的应用主要采用已知业务被动方式识别，识别种类有限。（2）由于SSL/TLS协议并不一定全部经443端口的TCP传输，现有识别规则有局限性，会对业务识别完整性造成影响。

在实际应用中存在非443端口的SSL/TLS协议消息，在图1示例中，实际是采用TCP端口：80来传输SSL/TLS协议。

因此，本发明要解决的技术问题是：（1）SSL/TLS协议承载域名信息的字段有规律可循，因此可以改被动识别为主动识别，提升数据识别广度。（2）增加TCP全端口实现SSL/TLS协议识别规则，提升业务识别准确性。

发明内容

本发明提出了一种一种基于HTTPS协议实现移动数据业务识别的方法，包括如下步骤：第一步，以TCP会话为单位缓存数据，首先完成协议识别，如果是Handshake协议，则根据Handshake Type识别Client Hello消息和Certificate消息；第二步，根据识别出的Client Hello消息和Certificate消息，提取相应的HOST信息；第三步，基于提取出的HOST信息，完成业务类型识别。

根据本发明的一个方面，在第二步中，如果发现Client Hello消息，则基于server_name扩展字段提取HOST信息；如果发现Certificate消息，则基于rdnSequence字段的id-at-commonName信息提取HOST信息。

根据本发明的一个方面，完整的一次TCP会话数据是以TCP连接建立开始，拆除TCP连接结束，其中4-20号数据包承载握手消息及应用层消息。

根据本发明的一个方面，第三步中，基于提取出的HOST信息，完成业务类型识别是按照如下方式进行识别的：基于预设的HOST与业务类型对应表，结合”Client_Hello_Host、Certificate_Host内容，完成业务类型识别。

根据本发明的一个方面，在基于Client Hello消息提取的HOST填入”Client_Hello_Host”，如消息中不包含server_name扩展字段，”Client_Hello_Host”填空；在基于Certificate消息提取的HOST，去除HOST信息第1位的“*”号，填入“Certificate_Host”，如果本次握手过程无Certificate消息，则”Certificate_Host”填空。

根据本发明的一个方面，HOST与业务类型对应表为：

HOST	业务类型
		weibo.cn	新浪微博业务
kuwo.cn	酷我音乐盒
		q.qlogo.cn	腾讯QQ
msf.3g.qq.com	腾讯QQ
		conf.3g.qq.com	腾讯QQ
immomo.com	陌陌
		hotmail.com	Hotmail邮件业务
www.google.com	谷歌
		apple.com	苹果应用
icloud.com	icloud云应用
		......	......

附图说明

结合随后的附图，从下面的详细说明中可显而易见的得出本发明的上述及其他目的、特征及优点。在附图中：

图1示出了根据本发明实施例的实际使用端口示意图。

图2示出了根据本发明实施例的采集合成设备解析HOST信息示意图。

图3示出了根据本发明实施例的HTTPS协议结构示意图。

图4示出了根据本发明实施例的SSL/TLS握手阶段信令流程示意图。

图5示出了根据本发明实施例的ClientHello消息扩展字段server_name包含的HOST信息提取位置示意图。

图6示出了根据本发明实施例的rdnSequence字段包含部分HOST信息提取位置示意图。

图7示出了根据本发明实施例的Handshake协议识别示意图。

图8示出了根据本发明实施例的提取的HOST信息为tyid.aliyun.com示意图。

图9示出了根据本发明实施例的提取的HOST信息为*.yytcdn.com示意图。

图10示出了根据本发明实施例的数据包解析示意图。

图11示出了根据本发明实施例的基于Client Hello消息提取的HOST为gs-loc.apple.com示意图。

图12示出了根据本发明实施例的基于Certificate消息提取的HOST为gs-loc.apple.com示意图。

图13示出了根据本发明实施例的数据包解析示意图。

图14示出了根据本发明实施例的Client Hello消息不包含HOST信息的Client Hello消息示意图。

图15示出了根据本发明实施例的基于Certificate消息提取的HOST为www.google.com的示意图。

图16示出了根据本发明实施例的数据包解析示意图。

图17示出了根据本发明实施例的基于Client Hello消息提取的HOST为service.gc.apple.com示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

目前，针对HTTP协议承载的数据业务有较成熟的识别机制，由于HTTP协议采用明文传输，通过采集合成设备对HTTP协议包中的HOST、URI信息解析，并通过预设规则即可完成业务识别。

识别示例如下：

（1）参见附图2，采集合成设备可直接解析出HOST信息，即：api.weibo.cn。

（2）参见表1，通过预设的HOST与业务类型对应表，可识别出为：新浪微博业务。

表1：

HOST	业务类型
		weibo.cn	新浪微博业务
kuwo.cn	酷我音乐盒
		q.qlogo.cn	腾讯QQ
msf.3g.qq.com	腾讯QQ
		conf.3g.qq.com	腾讯QQ
immomo.com	陌陌
		hotmail.com	Hotmail邮件业务
www.google.com	谷歌
		apple.com	苹果应用
icloud.com	icloud云应用
		......	......

HTTPS传输基于SSL/TLS协议，对应用层的数据业务做了加密处理，无法对应用层消息直接解析，但在加密过程中的握手阶段会包含完整，或部分HOST信息，基于这些完整或部分HOST信息，可实现业务类型识别。

以下针对HTTPS方式传输的数据业务类型识别方法详细说明。

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL。

SSL(Secure Sockets Layer安全套接层),及其继任者传输层安全(Transport Layer Security，TLS)是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。

现阶段移动互联网SSL应协议以：SSL、SSLV3、TLSV1、TLSV1.2为主，常用TCP端口为：443，在某些应用场景，也可采用其它端口号。

HTTPS协议结构如图3所示。一般应用分为应用层、TCP层和IP层。使用SSL后分为应用层、SSL层、TCP层和IP层。

SSL/TLS支持四种内容类型：application_data、alert、handshake和change_cipher_spec。

使用SSL/TLS的软件发送和接收的所有数据都是以application_data类型来发送的，其他三种内容类型用于对通信进行管理，如完成握手和报告错误等。

内容类型alert主要用于报告各种类型的错误。大多数alert(警示)用于报告握手中出现的问题，但也有一些指示在对记录试图进行解密或认证时发生的错误，alert消息的其他用途是指示连接将要关闭。

内容类型handshake用于承载握手消息。即便是最初形成连接的握手消息也是通过记录层以handshake类型的记录来承载的。由于加密密钥还未确立，这些初始的消息并未经过加密或认证，但是其他处理过程是一样的。有可能在现有的连接上初始化一次新的握手，在这种情况下，新的握手记录就像其他的数据一样，要经过加密和认证。

change_cipher_spec消息表示记录加密及认证的改变。一旦握手商定了一组新的密钥，就发送change_cipher_spec来指示此刻将启用新的密钥。

在handshake承载的握手消息中可能包含HOST消息，以下结合握手消息流程对HOST信息提取详细说明。

参见附图4,SSL/TLS握手阶段信令流程为：

第1步对应一条单一的握手消息，ClientHello。

第2步对应一系列SSL握手消息，服务器发送的第一条消息为ServerHello，其中包含了它所选择的算法，接着再在Certificate消息中发送其证书。最后，服务器发送ServerHelloDone消息以表示这一握手阶段的完成。需要ServerHelloDone的原因是一些更为复杂的握手变种，还要在Certifacate之后发送其他一些消息。当客户端接收到ServerHelloDone消息时，它就知道不会再有其他类似的消息过来了，于是就可以继续它这一方的握手。

第3步对应ClientKeyExchange消息。

第5与第6步对应Finished消息。该消息是第一条使用刚刚磋商过的算法加以保护的消息。为了防止握手过程遭到篡改，该消息的内容是前一阶段所有握手消息的MAC值。然而，由于Finished消息是以磋商好的算法加以保护的，所以也要与新磋商的MAC密钥—起计算消息本身的MAc值。

HOST信息提取位置说明如下：在SSL/TLS握手阶段ClientHello消息中可能包含完整HOST信息，在Certificate消息中包含部分HOST信息。

以下对HOST信息提取方法详细说明：

（1）基于ClientHello消息提取HOST信息方法：

ClientHello消息扩展字段server_name包含HOST信息，提取位置如附图5所示。在client hello消息中提取extension字段的server_name，接着在server_name字段提取HOST信息：gs-loc.apple.com。

（2）基于Certificate消息提取HOST信息方法：

Certificate消息返回的证书中，第一个为自身证书，此证书中subject:rdnSequence字段包含部分HOST信息，提取位置如附图6所示。uTF8String字段提取HOST信息：*.hotmail.com。

接下来，具体阐明基于HTTPS识别业务的实现方法。

1、协议及消息识别规则：

（1）SSL/TLS握手阶段的Handshake协议数据包识别规则：

根据SSL/TLS数据包头前11个字节，可完成Handshake协议识别。Handshake协议包头前11字节格式如表2所示：

表2：

字段类型	长度（字节）
		内容类型	1
版本信息	2
		内容长度	2
握手协议类型	1
		握手协议报文长度	3
版本信息	2

根据上表格式，识别规则如下：

a.TCP层Payload（有效载荷）第1字节取值为：0x16（10进制为22）；

b.第2-3字节与第10-11字节内容相同；

c.第4-5字节与第7-9字节内容按数值型还原后，差值为：4。

附图7为Handshake协议识别示例：

a.第1字节为0x16；

b.版本信息相同；

c.内容长度与协议报文长度差值为：4。

由此可判断该数据包为Handshake协议数据包。

（2）HOST信息提取方法：

HOST信息基于Handshake协议的Client Hello消息（Handshake Type:1）、Certificate消息（Handshake Type:11）识别，识别规则如下：

a.针对Handshake协议的Client Hello消息，基于server_name扩展字

段可实现完整HOST信息提取。

附图8示例中，提取的HOST信息为：tyid.aliyun.com。

b.针对Handshake协议的Certificate消息，基于rdnSequence字段的id-at-commonName信息可实现部分HOST信息提取。

附图9示例中，提取的HOST信息为：*.yytcdn.com

2、数据记录表结构规划：

基于SSL/TLS握手协议实现数据业务识别的数据记录至少应包含以下字段信息：

（1）开始时间：Client Hello消息时间。

（2）Client_Hello_Host：基于Client Hello消息提取的HOST；

（3）Certificate_Host：基于Certificate消息提取的HOST；

（4）业务类型：根据预设的HOST与业务类型对应表匹配后回填；

（5）业务流量：所有有效传输数据Payload总和；

（6）业务时长：第一个有效数据包至最后一个有效数据包时差。

3、数据合成及业务识别规则：

（1）以TCP会话为单位缓存数据，首先完成协议识别，如果Handshake协议，则根据Handshake Type识别Client Hello消息、Certificate消息；

（2）发现Client Hello消息时，将该条消息时间填入”开始时间”字段。

（3）基于Client Hello消息提取的HOST填入”Client_Hello_Host”，如消息中不包含server name扩展字段，”Client_Hello_Host”填空；

（4）基于Certificate消息提取的HOST，去除HOST信息第1位的“*”号，填入“Certificate_Host”，如果本次握手过程无Certificate消息，”Certificate_Host”填空；

（5）数据合成过程中实时累加Payload，至TCP会话结束时填入“业务流量”；

（6）第一条TCP拆链消息时间与开始时间差值填入“业务时长字段”。

（7）基于预设的HOST与业务类型对应表，结合”Client_Hello_Host、

Certificate_Host内容，完成业务类型识别。

根据本发明的一个具体实施例，（1）数据包中包含Client Hello消息、Certificate消息，且都可提取HOST信息的情况，具体参见附图10。完整的一次TCP会话数据（以TCP连接建立开始，拆除TCP连接结束），其中4-20号数据包承载握手消息及应用层消息。

参见附图11，基于Client Hello消息提取的HOST为：gs-loc.apple.com。

参见附图12，基于Certificate消息提取的HOST为：gs-loc.apple.com

（2）数据包中包含Client Hello消息、Certificate消息，Client Hello消息不包含server_name扩展信息，提取HOST信息的情况，具体参见附图13。完整的一次TCP会话数据（以TCP连接建立开始，拆除TCP连接结束），其中4-22号数据包承载握手消息及应用层消息。

参见附图14，Client Hello消息不包含HOST信息。

参见附图15，基于Certificate消息提取的HOST为：www.google.com。

（3）数据包中包含Client Hello消息，不包含Certificate消息，提取HOST信息的情况参见附图16所示。完整的一次TCP会话数据（以TCP连接建立开始，拆除TCP连接结束），其中4-22号数据包承载握手消息及应用层消息。

参见附图17，基于Client Hello消息提取的HOST为：service.gc.apple.com。

结合（1）、（2）、（3）分析结果，输出数据记录信息如表3所示：

表3：

开始时间

Client_Hello_Host

Certificate_Host

业务类型

业务流量

业务时长

				(Byte)	(ms)
						2013-5-1 16:19:18.217	gs-loc.apple.com	gs-loc.apple.com		6303	2319
2013-5-1 16:18:45.745		www.google.com		3106	1405
						2013-5-1 16:18:40.662	service.gc.apple.com			3165	5140

结合预设的HOST与业务类型对应表可扩展得到业务类型。

预设的HOST与业务类型对应表如表4所示：

表4：

HOST	业务类型
		weibo.cn	新浪微博业务
kuwo.cn	酷我音乐盒
		q.qlogo.cn	腾讯QQ
msf.3g.qq.com	腾讯QQ
		conf.3g.qq.com	腾讯QQ
immomo.com	陌陌
		hotmail.com	Hotmail邮件业务
www.google.com	谷歌
		apple.com	苹果应用
icloud.com	icloud云应用
		......	......

扩展业务类型后，数据表记录结果示例如表5所示：

表5：

通过本发明，可以以主动方式实现HTTPS业务类型识别，即通过对HTTPS方式的SSL/TLS各版本协议握手阶段实现HOST提取，并通过预设的HOST与业务类型对应表可扩展得到业务类型，有效提升业务识别广度。基于TCP全端口数据包的Handshake协议识别机制，有效提升业务识别深度。只针对HTTPS方式的SSL/TLS各版本协议握手阶段Handshake协议的Client Hello消息、Certificate消息提取HOST，合成效率高。

虽然已在具体实施方案中描述了本发明的实施方案及其各种功能组件，但是应当理解，可以用硬件、软件、固件、中间件或它们的组合来实现本发明的实施方案，并且本发明的实施方案可以用在多种系统、子系统、组件或其子组件中。本发明的每个实施例都可以与其它的实施例中的器件相互进行组合，而不是孤立的、单一的实施例，所有实施例之间都可以相互融合而形成新的实施例或者不同的解决方案。本发明虽然采用了不同的实施例来解决相应的技术问题，但是，这些不同的实施例并不是孤立的用于解决单个的技术问题，可以将这些不同的实施例组合起来共同解决需要克服的技术难题，可将不同实施例相互组合，以获得良好的性能。

以上所述，仅为本发明专利较佳的具体实施方式，但本发明专利的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明专利揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明专利的保护范围之内。

此外，对于本领域的普通技术人员来说可显而易见的得出其他优点和修改。因此，具有更广方面的本发明并不局限于这里所示出的并且所描述的具体说明及示例性实施例。因此，在不脱离由随后权利要求及其等价体所定义的一般发明构思的精神和范围的情况下，可对其做出各种修改。

Claims (6)

1.一种基于HTTPS协议实现移动数据业务识别的方法，其特征在于，包括如下步骤：

第一步，以TCP会话为单位缓存数据，首先完成协议识别，如果是Handshake协议，则根据Handshake Type识别Client Hello消息和Certificate消息；

第二步，根据识别出的Client Hello消息和Certificate消息，提取相应的HOST信息；

第三步，基于提取出的HOST信息，完成业务类型识别。

2.如权利要求1所述的基于HTTPS协议实现移动数据业务识别的方法，其特征在于：

在第二步中，

如果发现Client Hello消息，则基于server_name扩展字段提取HOST信息；

如果发现Certificate消息，则基于rdnSequence字段的id-at-commonName信息提取HOST信息。

3.如权利要求1所述的基于HTTPS协议实现移动数据业务识别的方法，其特征在于：

完整的一次TCP会话数据是以TCP连接建立开始，拆除TCP连接结束，其中4-20号数据包承载握手消息及应用层消息。

4.如权利要求1所述的基于HTTPS协议实现移动数据业务识别的方法，其特征在于：

第三步中，基于提取出的HOST信息，完成业务类型识别是按照如下方式进行识别的：

基于预设的HOST与业务类型对应表，结合”Client_Hello_Host、Certificate_Host内容，完成业务类型识别。

5.如权利要求2所述的基于HTTPS协议实现移动数据业务识别的方法，其特征在于：

在基于Client Hello消息提取的HOST填入”Client_Hello_Host”，如消息中不包含server_name扩展字段，”Client_Hello_Host”填空；

在基于Certificate消息提取的HOST，去除HOST信息第1位的“*”号，填入“Certificate_Host”，如果本次握手过程无Certificate消息，则”Certificate_Host”填空。

6.如权利要求4所述的基于HTTPS协议实现移动数据业务识别的方法，其特征在于：

HOST与业务类型对应表为：

Images