信息处理方法、网关及验证平台与流程

文档序号:11180385阅读:850来源:国知局
信息处理方法、网关及验证平台与流程

本发明涉及通信领域,尤其涉及一种信息处理方法、网关及验证平台。



背景技术:

为了对超文本传输协议(hypertexttransferprotocol,http)报文进行内容计费,目前业界普遍采用基于加密层(transportlayersecurity,tls)流程中初始协商消息中带的明文字段(servernameindication,sni),该字段用于标识业务的域名信息。但存在客户端和服务器配合作假,把sni字段设置为免流的字段,造成流量的盗用。所以服务器如何校验sni字段的真实性是一个待解决的问题。



技术实现要素:

有鉴于此,本发明实施例期望提供一种信息处理方法、网关及验证平台,至少部分解决sni字段导致的计费的精准性差的问题。

为达到上述目的,本发明的技术方案是这样实现的:

本发明实施例第一方面提供一种信息处理方法,包括:

获取服务器的ip地址;

识别服务器名字指示sni字段,获取所述服务器的域名;

基于所述域名和所述ip地址进行可信度验证;

基于所述可信度验证的结果,确定业务数据包的内容计费策略。

基于上述方案,所述基于所述域名和所述ip地址进行可信度验证,包括:

判断所述域名和所述ip地址是否位于可信列表和不可信列表中;

若所述域名和ip地址位于所述可信列表中,则直接根据所述sni字段确定计费策略;

若所述域名和ip地址位于所述不可信列表中,则结合所述sni信息校正计费策略。

基于上述方案,所述基于所述域名和所述ip地址进行可信度验证,还可包括:

若所述域名和所述ip地址既然不位于所述可信列表,也不位于所述不可信列表中,则将所述域名和所述ip地址发送给验证平台,进行所述可信度验证;

接收所述验证平台进行所述可信度验证的验证结果。

基于上述方案,所述方法还包括:

根据所述验证结果,更新所述可信列表或所述不可信列表。

基于上述方案,所述方法还包括:

若所述域名和所述ip地址既然不位于所述可信列表,也不位于所述不可信列表中,转发业务数据包并按照所述sni字段进行首次计费。

本发明实施例第二方面提供一种信息处理方法,包括:

接收网关发送的域名和ip地址;其中,所述域名为基于数据包中的服务器名字指示sni字段确定的;

对所述域名和所述ip地址进行验证,并形成验证结果;

将所述验证结果发送给所述网关;其中,所述验证结果,能够用于为所述网关进行内容计费提供依据。

基于上述方案,所述对所述域名和所述ip地址进行验证,并形成验证结果,包括:

依据所述域名和所述ip地址,查询黑名单和/或白名单,根据查询结果形成所述验证结果;其中,所述黑名单为包括不可信的域名和ip地址;所述白名单包括可信的域名和ip地址。

基于上述方案,所述对所述域名和所述ip地址进行验证,并形成验证结果,包括:

当所述黑名单和白名单中都不包括所述域名和所述ip地址时,根据所述域名查询预制证书,以获取所述ip地址对应的密钥信息;

依据所述密钥信息,向所述ip地址发送验证信息;

接收所述ip地址返回的验证信息,形成所述验证结果。

基于上述方案,所述方法还包括:

根据所述验证结果,更新所述黑名单或白名单。

本发明实施例第三方面提供一种网关,包括:

获取单元,用于获取服务器的ip地址;

识别单元,用于识别服务器名字指示sni字段,获取所述服务器的域名;

第一验证单元,用于基于所述域名和所述ip地址进行可信度验证;

确定单元,用于基于所述可信度验证的结果,确定业务数据包的内容计费策略。

基于上述方案,所述第一验证单元,具体用于判断所述域名和所述ip地址是否位于可信列表和不可信列表中;

所述确定单元,具体用于若所述域名和ip地址位于所述可信列表中,则直接根据所述sni字段确定计费策略;若所述域名和ip地址位于所述不可信列表中,则结合所述sni信息校正计费策略。

基于上述方案,所述第一验证单元,具体用于若所述域名和所述ip地址既然不位于所述可信列表,也不位于所述不可信列表中,则将所述域名和所述ip地址发送给验证平台,进行所述可信度验证;接收所述验证平台进行所述可信度验证的验证结果。

基于上述方案,所述网关还包括:

第一更新单元,用于根据所述验证结果,更新所述可信列表或所述不可信列表。

基于上述方案,所述网关还包括:

通信单元,用于若所述域名和所述ip地址既然不位于所述可信列表,也不位于所述不可信列表中,转发业务数据包并按照所述sni字段进行首次计费。

本发明实施例第四方面提供一种验证平台,包括:

接收单元,用于接收网关发送的域名和ip地址;其中,所述域名为基于数 据包中的服务器名字指示sni字段确定的;

第二验证单元,用于对所述域名和所述ip地址进行验证,并形成验证结果;

发送单元,用于将所述验证结果发送给所述网关;其中,所述验证结果,能够用于为所述网关进行内容计费提供依据。

基于上述方案,所述第二验证单元,具体用于依据所述域名和所述ip地址,查询黑名单和/或白名单,根据查询结果形成所述验证结果;其中,所述黑名单为包括不可信的域名和ip地址;所述白名单包括可信的域名和ip地址。

基于上述方案,所述第二验证单元,还用于当所述黑名单和白名单中都不包括所述域名和所述ip地址时,根据所述域名查询预制证书,以获取所述ip地址对应的密钥信息;依据所述密钥信息,向所述ip地址发送验证信息;接收所述ip地址返回的验证信息,形成所述验证结果。

基于上述方案,所述验证平台还包括:

第二更新单元,用于根据所述验证结果,更新所述黑名单或白名单。

本发明实施例提供一种信息处理方法、网关及验证平台,在tls连接建立的过程中,会对域名和ip地址之间的对应关系进行验证,以验证sni字段中携带的域名是真实的,以减少sin字段中携带者伪造的域名或与ip地址不对应的域名导致的基于该sni字段进行收费导致的计费精确度低的现象。

附图说明

图1为本发明实施例提供的第一种信息处理方法的流程示意图;

图2为本发明实施例提供的第二种信息处理方法的流程示意图;

图3为本发明实施例提供的对域名和ip地址进行验证的验证流程示意图;

图4为本发明实施例提供的一种网关的结构示意图;

图5为本发明实施例提供的一种验证平台的结构示意图;

图6为本发明实施例提供的一种信息系统结构示意图;

图7为本发明实施例提供的第三种信息处理方法的流程示意图。

具体实施方式

以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐述。

实施例一:

如图1所示,本实施例提供一种信息处理方法,包括:

步骤s110:获取服务器的ip地址;

步骤s120:识别服务器名字指示sni字段,获取所述服务器的域名;

步骤s130:基于所述域名和所述ip地址进行可信度验证;

步骤s140:基于所述可信度验证的结果,确定业务数据包的内容计费策略。

本实施例所述的信息处理方法,为能够应用于网关中的信息处理方法,本实施例中所述的网关可包括路由器。

在步骤s110中获取服务器的ip地址,可包括网关与服务器建立传输控制协议(transportcontrollerprotocol,tcp)连接,在建立tcp连接时就可以将获得服务器的ip地址。

在步骤s120中识别所述sni字段,通常sni字段是明文信息,故网关直接可以通过解码就能够获得sni字段中的域名。通常在进行计费时,根据该域名来进行计费。

在步骤s130中将对该域名和ip地址进行可信度验证,避免域名造假导致的计费结果不准确的问题。网关在进行数据转发时,是根据数据包中的目的ip地址进行数据包的转发的,而计费则时根据sni字段中的域名来处理的。若出现sni字段造假,即sni中的域名并非目的ip地址的域名,就有可能将收费的数据包,视为免费的数据包给转发了,从而导致计费结果的不准确。在本实施例中为了防止这种现象的产生,在本实施例中网关增加了进行可信度验证的步骤。

在步骤s130中,将根据可信度验证的结果进行内容计费处理。具体可包括,若sni字段表明是免费的,且验证结果表示为可信,则直接对该数据包进行免 费。若sni字段表示是免费的,而验证结果表明是不可信的,也可对该数据包进行收费处理。显然这样可以提高收费的准确度。

作为本实施例的进一步改进,在所述网关中存储有可信列表和非可信列表。通常可信列表中包括的域名和ip地址的对应关系,表示域名和ip地址之间的对应关系是正确的,不会存在ip地址或域名的伪造或错误。非可信列表中的域名和ip地址之间的对应关系是非可信的,表示域名或ip地址的至少其中之一有错误。故在本实施例中,所述步骤s130可包括:判断所述域名和所述ip地址是否位于可信列表和不可信列表中;若所述域名和ip地址位于所述可信列表中,则直接根据所述sni字段确定计费策略;若所述域名和ip地址位于所述不可信列表中,则结合所述sni信息校正计费策略。显然,这样可以简便的避免sni字段造假导致的计费结果不精确的问题。在本实施例中若步骤s110中提取的域名和步骤s120中获取的ip地址对应位于所述可信列表中,表示所述sni字段可信,可以直接根据所述sni字段确定出内容计费策略。若域名和ip地址的这种对应关系位于非可信列表中,则需要校正内容计费策略。通常情况下,非法用户为了避免计费,会将收费业务数据,通过位置sni字段的内容,改变成免费数据,则此时需要将免费策略校正为计费策略。还有一种可能是sni字段中原本要存储的收费较高的域名修改成收费较低的域名,这个时候,需要将计费策略中的计费单价恢复到较高的计费。

进一步地,所述步骤s130还可包括:

若所述域名和所述ip地址既然不位于所述可信列表,也不位于所述不可信列表中,则将所述域名和所述ip地址发送给验证平台,进行所述可信度验证;

接收所述验证平台进行所述可信度验证的验证结果。

若当前域名和ip地址是第一次获取到,这个时候,需要重新验证。在本实施例中所述网关可以将所述域名和ip地址发送给验证平台,由验证平台来进行验证。

在具体的实现过程中,所述网关也可以自行进行验证。例如,所述网关与该ip地址对应的服务器重新发起tls链接建立,在所述网关中存储有该域名 对应的预制证书。所述网关可以通过查询该预制证书,确定出向该域名对应的所述ip地址发送验证信息的密钥,该密钥通常为公钥。若所述域名和所述ip地址都并非伪造的,则所述ip地址应该能够接收并解码所述验证信息,再接收到所述验证信息之后,将会向网关反馈信息,这个时候所述网关就可以根据反馈信息来确定出所述域名和所述ip地址的对应关系是否正确,进而在步骤s140中确定出是否可以根据该sni字段直接进行计费。例如,所述反馈信息表明接收验证信息的一方,正确解码了验证信息,则认为该域名和ip地址之间的对应关系是正确的,是不存在伪造的条件的。

当然,具体实现时,可以由验证平台来实现上述验证处理,而网关仅直接接收验证结果就好。

延续上述实施例,所述方法还包括:

根据所述验证结果,更新所述可信列表或所述不可信列表。

若验证结果表明,所述域名和所述ip地址不可信,则将该域名和该ip地址添加到所述不可信列表中,则下次在出现该域名和ip地址时,就可以直接认为出现造假现象,应该进行内容收费。若所述域名和ip地址可信,则将该域名和该ip地址添加到所述可信列表中,方便后续数据包的快速转发及计费处理。

在本实施例中为了,避免可信sni字段,因未记载网关中的可信列表中导致的延时问题,在本实施例中所述方法还包括:

若所述域名和所述ip地址既然不位于所述可信列表,也不位于所述不可信列表中,转发业务数据包并按照所述sni字段进行首次计费。即网关一边对所述域名和ip地址发送给网关进行验证,或自行根据预制证书继续验证,一边转发数据包,避免数据包的延时,若下次再出现类似的数据包,则可以根据当前次验证的结果进行数据中sni字段的再次验证,一方面提升了收费的精准性,另一方面减少了因验证导致的时延大的问题。

在具体的实现过程中,若验证出sni字段携带的域名与服务器的ip地址的对应关系不正确,存在伪造和篡改的嫌疑,向指定设备发送提示信息,例如,向发送业务数据包的两端发送提示信息,和通信运营商的监控设备发送提示信 息,以通过提示信息,告知当前sni字段存在域名伪造和篡改的嫌疑,方便后续的监控,从源头上减少sni字段伪造和篡改的嫌疑。

实施例二:

如图2所示,本实施例提供一种信息处理方法,其特征在于,包括:

步骤s210:接收网关发送的域名和ip地址;其中,所述域名为基于数据包中的服务器名字指示sni字段确定的;

步骤s220:对所述域名和所述ip地址进行验证,并形成验证结果;

步骤s230:将所述验证结果发送给所述网关;其中,所述验证结果,能够用于为所述网关进行内容计费提供依据。

本实施例所述的方法,可为应用于验证平台中的方法,在本实施例中所述验证平台可又一台或多台服务器构成,也可以由一台或多台具有验证功能的虚拟机构成。

在本实施例中步骤s210中将从路由器等网关接收域名和ip地址,此时的域名为可为从sni字段中提取的。

在步骤s220中将进行域名和ip地址的验证,并形成验证结果。

在步骤s230中将验证结果发送给网关,方便网关对数据包的转发进行收费等处理。

在本实施例中所述验证平台将协助网关进行域名和ip地址是否可信的验证,以提升网关进行计费的精准度。

所述步骤s220的实现方式有多种,以下提供几种可实现方式:

方式一:

如图3所示,所述步骤s220可包括:

步骤s221:根据所述域名查询预制证书,以获取所述ip地址对应的密钥信息;

步骤s222:依据所述密钥信息,向所述ip地址发送验证信息;

步骤s223:接收所述ip地址返回的验证信息,形成所述验证结果。

所述预制证书可为预先存储在验证平台中的信息,当一个服务器构架完毕 之后,可能会与通信运营商进行签约,形成签约信息,签约信息中就可能包括所述预制证书。通常所述预制证书中包括公钥,在信息交互时利用公钥进行加密,则需要由存储在对应ip地址的设备中的私钥进行解密,才能获得正确的信息。在本实施例中,利用所述域名查询所述预制证书,从预制证书可读取所述公钥,利用所述公钥将向该ip地址发送验证信息,并接收该ip地址返回的验证信息,若该验证信息表明该ip地址的设备正确解密并解码了该验证信息,则表示该域名和该ip地址的对应关系正确,不存在着域名造价的问题,从而不存在者sni字段中域名的造价问题,可以直接根据该sni字段进行计费处理。

方式二:

所述步骤s220可包括:

依据所述域名和所述ip地址,查询黑名单和/或白名单,根据查询结果形成所述验证结果;其中,所述黑名单为包括不可信的域名和ip地址;所述白名单包括可信的域名和ip地址。

在本实施例中所述验证平台中可预先存储了有域名和ip地址的对应关系,存储有正确对应关系的为白名单,包括错误域名和ip地址对应关系的黑名单。在本实施例中所述验证平台可以通过查询白名单和黑名单中的至少其中之一,初步确定出域名和ip地址的对应关系是否正确。

当然,作为方式二的进一步改进,所述步骤s220还包括:

当所述黑名单和白名单中都不包括所述域名和所述ip地址时,根据所述域名查询预制证书,以获取所述ip地址对应的密钥信息;

依据所述密钥信息,向所述ip地址发送验证信息;

接收所述ip地址返回的验证信息,形成所述验证结果。

若当前域名和ip地址的对应关系在白名单和黑名单中都未存储,此时,就还不能确定该域名和ip地址的对应关系是否正确,在本实施例中同样可以采用前述步骤s221至步骤s223进行验证,以通过信息交互的方式确定出所述域名和所述ip地址之间的对应关系是否正确。

为了方便后续的域名和ip地址之间对应关系的验证,所述方法还包括:

根据所述验证结果,更新所述黑名单或白名单。

在本实施例中,还将根据步骤s223的处理,更新白名单或黑名单。若步骤s223的验证结果表明,该ip地址对应的设备,没有能够正确解密该验证信息,则将该域名和该ip添加到黑名单中,这样后续,在进行验证时,直接通过查询黑名单就能够确定出是否存在着sni字段造假的问题。若验证结果表明,对应的ip地址的设备正确解密所述验证信息,则可将该域名和ip地址添加到白名单中,方便后续验证。

在本实施例中所述验证平台可以与多台网关进行上述域名和ip地址之间对应关系的验证,这样就可以多台设备进行黑名单和白名单的共享,以提高验证效率。

实施例三:

如图4所示,本实施例提供一种网关,包括:

获取单元110,用于获取服务器的ip地址;

识别单元120,用于识别服务器名字指示sni字段,获取所述服务器的域名;

第一验证单元130,用于基于所述域名和所述ip地址进行可信度验证;

确定单元140,用于基于所述可信度验证的结果,确定业务数据包的内容计费策略。

在本实施例中所述获取单元110、识别单元120、第一验证单元130及确定单元140都可对应于网关中的处理器或处理电路。所述处理器可包括中央处理器、数字信号处理器、应用处理器、微处理器或可编程阵列等。所述处理电路可包括专用集成电路。

所述处理器或处理电路可以通过可执行代码的执行,实现上述功能,以识别出所述sni字段中携带的域名与ip地址的对应关系是否正确,从而防止sni字段中携带伪造的域名或不真实的域名导致的计费精确度低的现象。在本实施例中所述网关可以为路由器等设备。所述处理器可为路由器中的通信处理器等。

所述第一验证单元130,具体用于判断所述域名和所述ip地址是否位于可 信列表和不可信列表中;

所述确定单元140,具体用于若所述域名和ip地址位于所述可信列表中,则直接根据所述sni字段确定计费策略;若所述域名和ip地址位于所述不可信列表中,则结合所述sni信息校正计费策略。

在本实施例中所述第一验证单元130可包括存储介质,所述存储介质可存储有可信列表和所述不可信列表。所述第一验证单元130可以将获取单元110获取的ip地址和识别单元120识别的域名,为查询所以,查询所述可信列表和不可信列表中的至少其中之一,然后确定出所述域名和ip地址的对应关系是否正确。若正确,则可能在所述可信列表中查询到该域名和该ip地址的对应关系,若不正确,则可能在不可信列表中查询到该ip和该域名。总之,在本实施例中所述第一验证单元130在tls建链阶段,识别出所述sni字段中携带的域名是否正确,是否存在伪造和篡改等现象,从而方便确定单元140确定出能够提升计费精准度的信息。

在本实施例中,所述第一验证单元130具体可用于在与该ip地址对应的服务器重新发起tls链接建立时,查询该域名对应的预制证书,通过查询该预制证书,确定出向该域名对应的所述ip地址发送验证信息的密钥,该密钥通常为公钥;若所述域名和所述ip地址都并非伪造的,则所述ip地址应该能够接收并解码所述验证信息,再接收到所述验证信息之后,将会向网关反馈信息,这个时候所述网关就可以根据反馈信息来确定出所述域名和所述ip地址的对应关系是否正确,从而实现对所述域名和ip地址的验证。

进一步地,所述第一验证单元130,具体用于若所述域名和所述ip地址既然不位于所述可信列表,也不位于所述不可信列表中,则将所述域名和所述ip地址发送给验证平台,进行所述可信度验证;接收所述验证平台进行所述可信度验证的验证结果。

在本实施例中所述网关中可存储有所述可信列表和不可信列表,从而方便第一验证单元130快速通过查询所述可信列表或不可信列表,确定域名和ip地址之间的对应关系是否正确,以完成验证。本实施例所述的可信列表和不可信 列表的定义可以参见前述实施例,在此就不重复了。

所述网关还包括:第一更新单元,用于根据所述验证结果,更新所述可信列表或所述不可信列表。在本实施例中所述网关还包括第一更新单元,这里的更新单元用于根据从验证平台或网关自行通过验证的信息,更新所述可信列表或不可信列表,以方便下一次的验证。

所述网关还包括:

通信单元,用于若所述域名和所述ip地址既然不位于所述可信列表,也不位于所述不可信列表中,转发业务数据包并按照所述sni字段进行首次计费。

在本实施例中所述网关包括通信单元,该通信单元可以向服务器发送业务数据包,在本实施例中为了避免首次验证过程中,因验证流程所需的时间较长,导致的业务数据包的转发延时,在本实施例中会在查询到该域名和ip地址的对应关系既不在所述可信列表,也不再所述不可信列表中,则先转发所述业务数据包,并直接根据sni字段首次计费,在后续完成了校验,更新了所述可信列表或非可信列表之后,则会基于验证结果进行后续的计费策略的校正,以提升后续计费的精准度。本实施例中所述通信单元可对应于网关的通信接口,这里的通信接口可为有线接口或无线接口。所述有线接口可为光纤接口或电缆接口。所述无线接口可为各种天线等。

实施例四:

如图5所示,本实施例提供一种验证平台,包括:

接收单元210,用于接收网关发送的域名和ip地址;其中,所述域名为基于数据包中的服务器名字指示sni字段确定的;

第二验证单元220,用于对所述域名和所述ip地址进行验证,并形成验证结果;

发送单元230,用于将所述验证结果发送给所述网关;其中,所述验证结果,能够用于为所述网关进行内容计费提供依据。

本实施例所述接收单元210可为一台或多台能够进行域名和ip地址之前对应关系验证是否正确的服务器。

所述接收单元210可对应于接收接口,能够从网关接收到域名和ip地址。所述域名可以为tls报文中提取的sni字段中获取的。所述tls报文可为tls建链中传输的数据。

第二验证单元220将会进行域名和ip地址是否有正确的对应关系的验证,形成上述验证结果。本实施例所述的第二验证单元220可对应于验证平台中的处理器或处理电路。所述处理器或处理电路的结构。

所述发送单元230可对应于发送接口,这里的发送接口同样可为网关进行数据交互的接口,可以将所述验证结果发送给网关,方便网关进行内容计费策略的确定和校正。

总之,本实施例提供了一种验证平台,能够协助网关提升计费精准度。

此外,所述第二验证单元220,具体用于依据所述域名和所述ip地址,查询黑名单和/或白名单,根据查询结果形成所述验证结果;其中,所述黑名单为包括不可信的域名和ip地址;所述白名单包括可信的域名和ip地址。

在本实施例中所述验证平台中存储有黑名单和白名单。在本实施例中所述的黑名单对应于前述实施例中的不可信列表;所述白名单对应于前述实施例中的可信列表。

在本实施例中所述验证平台可以通过黑名单和白名单的查询,确定出从网关接收的域名和ip地址之间的对应关系是否正确,从而方便网关根据验证平台的验证结果,确定出sni字段的内容是否存在伪造和篡改的现象,提升计费的精准度。

此外,所述第二验证单元220,还用于当所述黑名单和白名单中都不包括所述域名和所述ip地址时,根据所述域名查询预制证书,以获取所述ip地址对应的密钥信息;依据所述密钥信息,向所述ip地址发送验证信息;接收所述ip地址返回的验证信息,形成所述验证结果。

在本实施例中所述第二验证单元220若确定出黑名单和白名单都不包括所述域名和ip地址时,通过与该ip地址的设备进行信息交互,来进行所述域名和ip地址之间对应关系是否正确的验证的结构。当然,所述第二验证单元220 也可以不查询黑名单和白名单的情况下,直接通过与该ip地址对应的设备的信息交互,来进行域名和该ip地址之间的验证。

作为本实施例的进一步改进,第二更新单元,用于根据所述验证结果,更新所述黑名单或白名单。

本实施例所述第二更新单元,可对应于处理器或处理电路,能够用于根据上述验证结果,更新所述黑名单或白名单,方便后续的验证,以提升后续的验证效率。

以下结合上述任意实施例提供两个具体示例:

示例一:

如图6所示,本示例提供一种通信系统,包括:

用户设备(userequipment,ue)、网关(ggsn/p-gw)、服务器(sp)及验证平台。

在本实施例所述ue与服务器之间的数据包,需要通过网关进行转发。在进行数据转发之前,网关需要建立ue与服务器之间的tcp连接及进行tls建链处理。

在本实施例中所述验证平台分别能够与网关和服务器进行连接。

在本实施例中所述网关中存储有可信列表和不可信列表,当进行tls建链时,在建链的初始阶段,网关会从tls报文中提取sni字段,根据该sni字段,得到后续进行业务数据收发的域名。在进行tls建链之前,网关将作为中间节点,建立ue与服务器之间将进行tcp连接,在建立tcp连接的过程中,会确定出服务器的ip地址。在本实施例中,所述服务器可为内容服务提供者(serviceprovider,sp)故也可以如图6所示,简称为sp。所述网关可包括如图6中所示的通用分组无线业务网关支持节点(gatewaygprssupportnode)或分组数据网网关。

当网关通过自身存储的可信列表和不可信列表,无法确定该域名与ip地址之间的对应关系是否正确时,将该域名和ip地址发送给验证平台进行统一验证。

验证平台接收到给域名和ip地址之后,查询内部的黑名单和白名单,根据 查询结果确定域名和ip地址是否正确。若无法通过查询确定,则可以通过向该ip地址对应的设备发送利用公钥加密的验证信息,来进行验证。若验证成功,则认为该域名和ip地址的对应关系正确,否则认为验证不正确。

在具体的实现过程中,所述验证平台将会与网络中大量的网关进行连接,由于大量的信息处理,在该验证平台中存储有大量的黑名单和白名单,可以简便的通过查询进行验证。

示例二:

如图7所示,本示例提供一种信息处理方法:

步骤1:网关通过透传建链消息,实现ue与服务器sp之间的tcp三次握手,网关透传建链消息。这里的建链消息为建立tcp连接的信息,此时,网关获得了服务器的ip地址。

步骤2:进行tls建链处理。网关从ue接收到第一消息,这里的第一消息可为ue传输的打招呼的信息,例如,“clienthello”。网关在ue和sp之间透传消息;解析sni字段,如果sni字段中的域名和sp的ip在可信列表中有对应关系,则验证通过,将sid设置为后向计费;如果在不可信列表中,sid设为正常前向计费。如果sp的ip和域名对应关系在上述列表中都不存在,则记录握手信息,传递给验证平台。这里的后向计费和正常前向计费都为前述内容计费策略的一种。此处的后向计费为由运营商的服务器进行计费的计费策略;前向计费可为由客户端进行计费的计费策略。这样的话,后向计费能够监督伪造sin字段的数据费用,提高计费的精确度。

网关还会将无对应关系的域名和ip地址发送给验证平台。

网关透传消息,本次建链成功。这里透传的消息为第二消息。这里的第二消息可包括服务器的招呼消息,整数、服务器密钥交互等各种消息。

步骤3:验证平台模拟ue发起tcp建链和tls握手,握手使用的整数为sni字段中域名对应的预制整数,向sp发送第二消息;如果模拟握手过程中出现问题,则计入该ip和域名的对应关系入黑名单,如果握手通过,则记录该ip地址和域名的对应关系如白名单;并通知网关。

在本申请所提供的几个实施例中,应该理解到,所揭露的设备和方法,可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,如:多个单元或组件可以结合,或可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口,设备或单元的间接耦合或通信连接,可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的,作为单元显示的部件可以是、或也可以不是物理单元,即可以位于一个地方,也可以分布到多个网络单元上;可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外,在本发明各实施例中的各功能单元可以全部集成在一个处理模块中,也可以是各单元分别单独作为一个单元,也可以两个或两个以上单元集成在一个单元中;上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:移动存储设备、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

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

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1