HTTPS重定向的降噪方法及装置与流程

本发明涉及通信技术领域，尤指一种https重定向的降噪方法及装置。

背景技术：

基于安全套接层的超文本传输协议(hypertexttransferprotocoloversecuresocketlayer，https)是以安全为目标的超文本传输协议(hypertexttransferprotocoloversecuresocketlayer，http)通道，简单讲是http的安全版。即在http下加入安全套接层协议(securesocketslayer，ssl)，ssl是https的安全基础。

https重定向技术是认证设备对终端发起的https请求报文进行拦截，然后仿冒目的站点与终端进行传输控制协议(transmissioncontrolprotocol，tcp)握手、ssl握手，建立连接后向终端重定向推送认证页面。

目前，除通过浏览器发起的https请求报文外，还会有许多应用程序也发起大量的https请求报文，对于这些通过非浏览器发起的https请求报文，认证设备也会进行拦截重定向，通过非浏览器发起的https请求报文实际上是无效https请求报文，可以认定为https噪音，即使认证设备推送认证页面，应用程序也无法显示，而这些无效https请求报文会消耗认证设备的大量资源，甚至会影响正常https请求报文的处理。因此，目前亟需一种https重定向的降噪方法，来过滤掉https请求报文中的https噪音。

技术实现要素：

本发明实施例提供一种https重定向的降噪方法及装置，用以实现过滤掉https请求报文中的https噪音，对https重定向进行降噪。

根据本发明实施例，提供一种https重定向的降噪方法应用在认证设备中，包括：

接收第一终端发送的第一传输控制协议tcp请求报文；

获取所述第一tcp请求报文携带的源互联网协议ip地址、目的ip地址、源端口和目的端口；

确定在所述第一tcp请求报文的接收时刻之前的设定时长内是否接收过设定数量的携带所述源ip地址、所述目的ip地址和所述目的端口的第二tcp请求报文；

若确定在所述设定时长内接收过所述设定数量的第二tcp请求报文，则确定所述第一tcp请求报文携带的源端口和所述第二tcp请求报文携带的源端口是否按照设定规律变化；

若确定所述第一tcp请求报文携带的源端口和所述第二tcp请求报文携带的源端口按照设定规律变化，则丢弃所述第一tcp请求报文。

可选的，还包括：

若确定在所述设定时长内未接收过所述设定数量的第二tcp请求报文，则向所述第一终端发送与所述第一tcp请求报文对应的tcp响应报文；

记录所述第一tcp请求报文的源ip地址、目的ip地址、源端口、目的端口和接收时刻。

可选的，丢弃所述第一tcp请求报文之后，还包括：

记录所述第一tcp请求报文的源ip地址、目的ip地址、源端口、目的端口和接收时刻。

可选的，还包括：

接收第二终端发送的安全套接层协议ssl请求报文；

获取所述ssl请求报文中携带的统一资源定位器url和/或协议类型；

确定所述url与预先设置的url特征库是否匹配，和/或，确定所述协议类型是否是指定协议类型；

若确定所述url与所述url特征库匹配或者所述协议类型是所述指定协议类型，则丢弃所述ssl请求报文。

根据本发明实施例，还提供一种https重定向的降噪装置，应用在认证设备中，包括：

接收模块，用于接收第一终端发送的第一传输控制协议tcp请求报文；

获取模块，用于获取所述第一tcp请求报文携带的源互联网协议ip地址、目的ip地址、源端口和目的端口；

确定模块，用于确定在所述第一tcp请求报文的接收时刻之前的设定时长内是否接收过设定数量的携带所述源ip地址、所述目的ip地址和所述目的端口的第二tcp请求报文；若确定在所述设定时长内接收过所述设定数量的第二tcp请求报文，则确定所述第一tcp请求报文携带的源端口和所述第二tcp请求报文携带的源端口是否按照设定规律变化；

丢弃模块，用于若确定所述第一tcp请求报文携带的源端口和所述第二tcp请求报文携带的源端口按照设定规律变化，则丢弃所述第一tcp请求报文。

可选的，还包括发送模块和第一记录模块，其中：

所述发送模块，用于若确定在所述设定时长内未接收过所述设定数量的第二tcp请求报文，则向所述第一终端发送与所述第一tcp请求报文对应的tcp响应报文；

所述第一记录模块，用于记录所述第一tcp请求报文的源ip地址、目的ip地址、源端口、目的端口和接收时刻。

可选的，还包括第二记录模块，用于：

所述丢弃模块丢弃所述第一tcp请求报文之后，记录所述第一tcp请求报文的源ip地址、目的ip地址、源端口、目的端口和接收时刻。

可选的，还包括：

所述接收模块，还用于接收第二终端发送的安全套接层协议ssl请求报文；

所述获取模块，还用于获取所述ssl请求报文中携带的统一资源定位器url和/或协议类型；

所述确定模块，还用于确定所述url与预先设置的url特征库是否匹配，和/或，确定所述协议类型是否是指定协议类型；

所述丢弃模块，还用于若确定所述url与所述url特征库匹配或者所述协议类型是所述指定协议类型，则丢弃所述ssl请求报文。

本发明有益效果如下：

本发明实施例提供一种https重定向的降噪方法及装置，通过接收第一终端发送的第一tcp请求报文；获取所述第一tcp请求报文携带的源互联网协议ip地址、目的ip地址、源端口和目的端口；确定在所述第一tcp请求报文的接收时刻之前的设定时长内是否接收过设定数量的携带所述源ip地址、所述目的ip地址和所述目的端口的第二tcp请求报文；若确定在所述设定时长内接收过所述设定数量的第二tcp请求报文，则确定所述第一tcp请求报文携带的源端口和所述第二tcp请求报文携带的源端口是否按照设定规律变化；若确定所述第一tcp请求报文携带的源端口和所述第二tcp请求报文携带的源端口按照设定规律变化，则丢弃所述第一tcp请求报文。该方案中，可以直接在https重定向过程中的tcp握手阶段进行降噪，当tcp请求报文丢弃后，https重定向过程终止，从而可以实现过滤https噪音。

附图说明

图1为本发明实施例中一种基于tcp进行https重定向的降噪方法的流程图；

图2为本发明实施例中另一种基于ssl进行https重定向的降噪方法的流程图；

图3为本发明实施例中一种与图1对应的https重定向的降噪装置的结构示意图；

图4为本发明实施例中另一种与图2对应的https重定向的降噪装置的结构示意图。

具体实施方式

为了实现过滤掉https请求报文中的https噪音，对https重定向进行降噪，发明人进行了很深入的研究，发现：

对于https重定向来说，只有用户手动点击、或者系统前台自动触发的可以响应重定向的https请求报文，才不是https噪音，是正常https请求，其余https请求报文均可以被定义为https噪音。

按照用户行为，下表1列出了https请求报文的产生以及https请求报文是否https噪音的认定。

表1

按照网络分层结构，可以考虑不同层次的特征对https噪音分析处理，如下表2所示。

表2

针对数据链路层降噪的可行性分析：

对于数据链路层来说，能够感知的信息主要有源媒体访问控制(mediaaccesscontroladdress，mac)地址、目的mac地址、帧数据类型，根据这三者无法区分https请求报文与非https请求报文，就更别说进一步的分析https噪音了，所以数据链路层的降噪行不通。

针对网络层降噪的可行性分析：

对于网络层来说，能够感知的信息主要有源ip地址、目的ip地址、传输层协议号，根据这三者无法区分https请求报文与非https请求报文，就更别说进一步的分析https噪音了，所以网络层的降噪行不通。

针对传输层降噪的可行性分析：

对于传输层来说，能够感知的信息主要是传输层的具体数据，如tcp的源端口、目的端口，仅仅靠这些也无法对https噪音进行识别与判断。但是根据前期的抓包分析，浏览器在访问统一资源定位符(uniformresourcelocator，url)时，为了确保页面能够快速的呈现给用户，会同时发起多条https请求报文，只需要其中部分能够得到响应，那么页面就可以被呈现出来。其中剩余部分的https请求，可以直接丢弃，因此在链路层进行降噪是可行的。

针对会话层降噪的可行性分析：

对于会话层来说，ssl处于这一层次，ssl握手、计算需要占用大量的中央处理器(centralprocessingunit，cpu)资源，ssl可以获取足够丰富的信息，因此在会话层进行降噪是可行的。

针对应用层降噪的可行性分析：

对于应用层来说，上层业务经过openssl代理之后，可以看到实际的http报文，http首部有部分信息可以利用起来做为降噪点，如user-agent等，但是其实大部分的cpu计算已经在ssl握手中已经被消耗了，此处在做降噪用处不大。

综上考虑，可以从两个方面进行降噪处理：基于tcp和基于ssl进行降噪。在https重定向过程中，要先进行tcp握手再进行ssl握手，然后再进行http请求，因此，如果基于tcp降噪，后续不会有ssl握手和http请求，从而达到https重定向降噪；如果未基于tcp降噪，而是基于ssl降噪，后续不会有http请求，从而达到https重定向降噪。因此，可以只基于tcp降噪或者只基于ssl降噪，也可以先基于tcp降噪再基于ssl降噪。下面分别介绍基于tcp进行https重定向的降噪方法和基于ssl进行https重定向的降噪方法。

首先介绍基于tcp进行https重定向的降噪方法，可以应用在认证设备中，如图1所示，具体执行步骤如下：

s11：接收第一终端发送的第一tcp请求报文。

s12：获取第一tcp请求报文携带的源ip地址、目的ip地址、源端口和目的端口。

s13：确定在第一tcp请求报文的接收时刻之前的设定时长内是否接收过设定数量的携带源ip地址、目的ip地址和目的端口的第二tcp请求报文。

s14：若确定在设定时长内接收过设定数量的第二tcp请求报文，则确定第一tcp请求报文携带的源端口和第二tcp请求报文携带的源端口是否按照设定规律变化。

s15：若确定第一tcp请求报文携带的源端口和第二tcp请求报文携带的源端口按照设定规律变化，则丢弃第一tcp请求报文。

浏览器在访问url时，为了确保页面能够快速的呈现给用户，会同时发起多条https请求报文，只需要其中部分能够得到响应，那么页面就可以被呈现出来。其中剩余部分的https请求，可以直接丢弃。反应在tcp请求报文中，就是在设定时间内，tcp请求报文的源ip地址、目的ip地址和目的端口不变，而源端口按照设定规律变化，这就可以认为是同一终端多次发送的tcp请求，此时，只响应设定数量的tcp请求报文即可，后续再接收到的就可以直接丢弃。

其中，设定时长和设定数量可以根据实际需要进行设定，设定规律可以但不限于为端口号按照接收先后顺序依次递增。

该方案中，可以直接在https重定向过程中的tcp握手阶段进行降噪，当tcp请求报文丢弃后，https重定向过程终止，从而可以实现过滤https噪音。

可选的，上述方法还包括：

若确定在设定时长内未接收过设定数量的第二tcp请求报文，则向第一终端发送与第一tcp请求报文对应的tcp响应报文；记录第一tcp请求报文的源ip地址、目的ip地址、源端口、目的端口和接收时刻。对于在设定时长内未接收过设定数量的第二tcp请求报文的情况，说明还可以继续响应，可以发送tcp响应报文，并记录第一tcp请求报文的源ip地址、目的ip地址、源端口、目的端口和接收时刻，以便于后续继续进行降噪。

可选的，上述s15中丢弃第一tcp请求报文之后，上述方法还包括：

记录第一tcp请求报文的源ip地址、目的ip地址、源端口、目的端口和接收时刻。由于后续还有可能收到源ip地址、目的ip地址、目的端口相同，源端口不同的tcp请求报文，因此，可以记录第一tcp请求报文的源ip地址、目的ip地址、源端口、目的端口和接收时刻，以便于后续继续进行降噪。

以上介绍了基于tcp进行https重定向的降噪方法，可以应用在认证设备中，下面介绍基于ssl进行https重定向的降噪方法，可以应用在认证设备中，如图2所示，具体执行步骤如下：

s21：接收第二终端发送的ssl请求报文。

s22：获取ssl请求报文中携带的url和/或协议类型。

s23：确定url与预先设置的url特征库是否匹配，和/或，确定协议类型是否是指定协议类型。

s24：若确定url与url特征库匹配或者协议类型是指定协议类型，则丢弃ssl请求报文。

一个完整的ssl握手阶段涉及到的终端的必选流程为clienthello、clientkeyexchange、changecipherspec和finished，下面针对每个流程做如下具体的分析：

针对clienthello：终端开始新的握手，并将自身支持的功能交给认证，支持如下表3所示的字段：

表3

上述字段中有利于https重定向的降噪如下表4所示，其他字段不再一一列举。

表4

针对clientkeyexchange：终端发送生成主密钥所需要的额外信息；受协商的密码套件影响，内容随着不同的套件而不同。这部分为协议相关，与用户行为无关，无法作为特征提取出。

针对changecipherspec：终端切换加密方式并通知认证设备；这部分为协议相关，与用户行为无关，无法作为特征提取出。

针对finished：终端计算发送和接收到的握手信息的mac地址并发送；这部分为协议相关，与用户行为无关，无法作为特征提取出。

综上，ssl握手阶段有两个特征可以用于https噪音识别：终端访问的url与支持的协议(可以作为指定协议类型)。

对于终端访问的url，考虑到产生https噪音的形式多种多样，采用增加url特征库进行匹配，url特征库可以是白名单url库或者黑名单url库。

白名单url库的设定方法如下：

针对定位为非https噪音的url进行重定向，对于定位为https噪声的url在ssl握手阶段就直接阻断，白名单url可以为知名网站等等，例如如使用alexa(http://www.alexa.cn/)的网站排行、导航网站的网站排行、手机前十名的导航页面网站等，白名单url库支持周期性更新，以应变当前瞬息万变的情况。

黑名单url库考虑：

针对明确定义为https噪音的url加入黑名单库进行阻断，不在黑名单url库中的url可进行重定向。黑名单url可针收集明确是https噪音的url的特征，即人为操作不会访问的url，例如app中会发起类似访问接口的url(举例：新浪微博app访问api.weibo.cn)、系统更新访问的url等(举例：mdk系统更新访问mtepodownload.mdiatek.com)。黑名单url库支持周期性更新，以应变当前瞬息万变的情况。

对于终端支持的协议，当下大部分情况下目的端口443均为http1.x的流量，可以但不限于为http1.x。

该方案中，可以直接在https重定向过程中的ssl握手阶段进行降噪，当ssl请求报文丢弃后，https重定向过程终止，从而可以实现过滤https噪音。

基于同一发明构思，本发明实施例提供一种https重定向的降噪装置，与如图1所示的方法相对应，应用在认证设备中，该装置的结构如图3所示，包括：

接收模块31，用于接收第一终端发送的第一tcp请求报文；

获取模块32，用于获取第一tcp请求报文携带的源ip地址、目的ip地址、源端口和目的端口；

确定模块33，用于确定在第一tcp请求报文的接收时刻之前的设定时长内是否接收过设定数量的携带源ip地址、目的ip地址和目的端口的第二tcp请求报文；若确定在设定时长内接收过设定数量的第二tcp请求报文，则确定第一tcp请求报文携带的源端口和第二tcp请求报文携带的源端口是否按照设定规律变化；

丢弃模块34，用于若确定第一tcp请求报文携带的源端口和第二tcp请求报文携带的源端口按照设定规律变化，则丢弃第一tcp请求报文。

该方案中，可以直接在https重定向过程中的ssl握手阶段进行降噪，当ssl请求报文丢弃后，https重定向过程终止，从而可以实现过滤https噪音。

可选的，还包括发送模块和第一记录模块，其中：

发送模块，用于若确定在设定时长内未接收过设定数量的第二tcp请求报文，则向第一终端发送与第一tcp请求报文对应的tcp响应报文；

第一记录模块，用于记录第一tcp请求报文的源ip地址、目的ip地址、源端口、目的端口和接收时刻。

可选的，还包括第二记录模块，用于：

丢弃模块丢弃第一tcp请求报文之后，记录第一tcp请求报文的源ip地址、目的ip地址、源端口、目的端口和接收时刻。

可选的，还包括：

接收模块，还用于接收第二终端发送的安全套接层协议ssl请求报文；

获取模块，还用于获取ssl请求报文中携带的统一资源定位器url和/或协议类型；

确定模块，还用于确定url与预先设置的url特征库是否匹配，和/或，确定协议类型是否是指定协议类型；

丢弃模块，还用于若确定url与url特征库匹配或者协议类型是指定协议类型，则丢弃ssl请求报文。

基于同一发明构思，本发明实施例提供一种https重定向的降噪装置，与如图2所示的方法相对应，应用在认证设备中，该装置的结构如图4所示，包括：

接收模块41，用于接收第二终端发送的ssl请求报文；

获取模块42，用于获取ssl请求报文中携带的统一资源定位器url和/或协议类型；

确定模块43，用于确定url与预先设置的url特征库是否匹配，和/或，确定协议类型是否是指定协议类型；

丢弃模块44，用于若确定url与url特征库匹配或者协议类型是指定协议类型，则丢弃ssl请求报文。

该方案中，可以直接在https重定向过程中的ssl握手阶段进行降噪，当ssl请求报文丢弃后，https重定向过程终止，从而可以实现过滤https噪音。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的可选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括可选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样，倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。