首页> 中国专利> 一种对中间人的存在进行辨识的方法及装置

一种对中间人的存在进行辨识的方法及装置

摘要

本申请公开了一种对中间人的存在进行辨识的方法,用以解决由于客户端无法辨识客户端与服务器之间是否存在中间人,从而可能使得传输的信息受到潜在的安全威胁的问题。方法包括:获得在客户端与服务器的握手过程中由客户端接收的服务器的第一证书相关信息,以及在客户端与服务器的非握手过程中由客户端接收的所述服务器的第二证书相关信息;判断第一证书相关信息和第二证书相关信息是否匹配。本申请还公开一种对中间人的存在进行辨识的装置。

著录项

  • 公开/公告号CN105516066A

    专利类型发明专利

  • 公开/公告日2016-04-20

    原文格式PDF

  • 申请/专利权人 阿里巴巴集团控股有限公司;

    申请/专利号CN201410504854.3

  • 发明设计人 陈海兵;

    申请日2014-09-26

  • 分类号H04L29/06(20060101);

  • 代理机构11315 北京国昊天诚知识产权代理有限公司;

  • 代理人许志勇

  • 地址 英属开曼群岛大开曼资本大厦一座四层847号邮箱

  • 入库时间 2023-12-18 15:37:44

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2019-04-09

    授权

    授权

  • 2016-05-18

    实质审查的生效 IPC(主分类):H04L29/06 申请日:20140926

    实质审查的生效

  • 2016-04-20

    公开

    公开

说明书

技术领域

本申请涉及计算机技术领域,尤其涉及一种对中间人的存在进行辨识的方 法及装置。

背景技术

在很多情况下,互联网使用者需要使用非私有终端上网,如使用公司或者 网吧提供的电脑上网。对于此类终端的拥有者,其对于安全的需求与终端的实 际使用者对于安全的需求并不完全一致,有时甚至会发生冲突。比如:对于实 际使用者,会希望在上网过程中,其个人隐私如银行账号密码等不被窥探;而 对于企业而言,为了防止其内部机密被恶意泄露或者为了提升员工的工作效 率,则希望对实际使用者的上网流量作扫描或者审计,从而确定实际使用者利 用终端所传输的具体信息。

一般地,对于非加密流量,简单的基于流的扫描就可以达到监控信息的目 的;而对于采用安全超文本传输协议(HyperTextTransferProtocoloverSecure SocketLayer,HTTPS)等安全套接层(SecureSocketsLayer,SSL)协议进行 加密得到的加密流量,则需要通过代理技术才能实现信息监控。一种典型的代 理技术的实现示意图如图1所示。

图1中,左侧方框代表企业的终端中安装的客户端(WebClient),中间方 框代表在企业网络出口处的网关或防火墙设备部署的SSL代理(SSLProxy1, 在图1所示的场景中,其一般被称为“中间人”),右边方框代表客户端所访问 的网站服务器,具体而言,该服务器的名称可以是图1中所示的“AlipayWeb Server”。

图1中,具备监控终端所传输的具体信息这一功能的是SSL代理,该功能 的实现原理大致为:SSL代理劫持来自客户端的SSL握手请求,然后利用该 SSL握手请求发起与真实服务器的SSL连接;在与服务器侧的SSL握手成功 后,再恢复与客户端的SSL握手,并在与客户端进行SSL握手时,向客户端 推送一本伪造的证书,使得客户端信任SSL代理,进而可以获取客户端所发送 的信息。

需要说明的是,根据SSL协议的设计,其具备一致性检查能力,即当遭受 到中间人攻击时,客户端会弹出告警,告知用户“当前接收到的证书非法”。 然而,对公司而言,该告警实际上是由自身部署的SSL代理所致,并非公司网 络受到实际攻击,因此,考虑到弹出的告警会影响实际使用者的上网体验或者 工作效率,一般会采用下述手段1和手段2,抑制客户端弹出告警:

手段1:使用SSL代理的自签名证书为客户端签发证书时,在签发的证书 中保持真实服务器的域名/Subject/Valid等信息。

手段2:将上述自签名证书作为可信电子商务认证授权机构(Certificate Authority,CA)证书,导入到客户端中。

结合上述手段1和手段2,可以使得终端对SSL代理签发的证书进行验证 时,会认为该证书是合法证书,从而得到客户端信任。

通过上述方式,一个典型的信息监控过程可以包括如图1所示的如下步骤:

1、客户端向服务器发起SSL握手请求;

2、SSL代理劫持来自客户端的SSL握手请求;

3、SSL代理向服务器发起SSL连接请求;

4、服务器响应SSL代理发起的SSL连接请求,并发送服务器自身的证书 给SSL代理;

5、SSL代理根据服务器(即真实服务器)的证书,使用自签名证书重新 签发一本证书(后文称新生成证书);

由前文所述的手段2可知,客户端会认为SSL代理使用的自签名证书是可 信CA证书,从而后续客户端在对新生成证书进行校验时,也会依据该自签名 证书签发的该新生成证书是可信的。

6、SSL代理将新生成证书推送给客户端;

7、客户端使用本地可信CA证书对收到的新生成证书做校验,校验通过;

8、客户端向服务器请求登录页面;

9、服务器向客户端回送登录页面;

10、客户端发送包含登录信息密文的HTTPPOST(HTTPPOST是一种 HTTP请求);

11、SSL代理对包含登录信息密文的HTTPPOST进行解密,得到登录信 息明文。

上述方案的缺陷在于,终端对于SSL代理的存在是无感知的,从而当终端 的实际使用者访问隐私或者金融类的HTTPS网站时,会将实际使用者的用户 名密码信息等明文信息暴露给SSL代理,从而使得该些信息受到潜在的安全威 胁。

类似地,在客户端与服务器之间存在设置在其他协议层的中间人的场景 下,也会存在上述问题。

发明内容

本申请实施例提供一种对中间人的存在进行辨识的方法,用以解决由于客 户端无法辨识客户端与服务器之间是否存在中间人,从而可能使得传输的信息 受到潜在的安全威胁的问题。

本申请实施例还提供一种对中间人的存在进行辨识的装置,用以解决由于 客户端无法辨识客户端与服务器之间是否存在中间人,从而可能使得传输的信 息受到潜在的安全威胁的问题。

本申请实施例采用下述技术方案:

一种对中间人的存在进行辨识的方法,包括:获得在客户端与服务器的握 手过程中由客户端接收的服务器的第一证书相关信息,以及在所述客户端与所 述服务器的非握手过程中由客户端接收的所述服务器的第二证书相关信息;判 断第一证书相关信息和第二证书相关信息是否匹配。

一种对中间人的存在进行辨识的装置,包括:信息获得单元,用于获得在 客户端与服务器的握手过程中由客户端接收的服务器的第一证书相关信息,以 及在所述客户端与所述服务器的非握手过程中由客户端接收的所述服务器的 第二证书相关信息;辨识单元,用于判断信息获得单元获得的第一证书相关信 息和第二证书相关信息是否匹配。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:

当设置有中间人时,该中间人仅会在客户端与服务器的握手过程中利用自 身的自签名证书和服务器的身份信息(如域名/Subject/Valid等信息),得到新 生成证书,而对客户端与服务器的非握手过程中传递的服务器的证书相关信息 不会执行类似操作,即非握手过程中传递的服务器的证书相关信息仍然是服务 器的真实证书相关信息。因此,通过比较握手过程和非握手过程中接收的同一 服务器的证书相关信息,可以达到辨识是否存在中间人的目的。

附图说明

此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部 分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不 当限定。在附图中:

图1为现有技术中采用代理技术监控终端所传输的具体信息的实现原理示 意图;

图2为本申请实施例提供的一种对中间人的存在进行辨识的方法的实现流 程示意图;

图3为本申请实施例2提供一种防范中间人攻击的方法的实现流程示意 图;

图4为本申请实施例3提供的一种对中间人的存在进行辨识的装置的具体 结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实 施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的 实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施 例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施 例,都属于本申请保护的范围。

以下结合附图,详细说明本申请各实施例提供的技术方案。

实施例1

为了解决客户端无法辨识客户端与服务器之间是否存在中间人的问题,本 申请实施例1提供一种对中间人的存在进行辨识的方法。该方法的具体实现流 程示意图如图2所示,包括如下步骤:

步骤21,获得在客户端与服务器的握手过程中由客户端接收的服务器的第 一证书相关信息,以及在客户端与服务器的非握手过程中由客户端接收的该服 务器的第二证书相关信息;

步骤22,判断第一证书相关信息和第二证书相关信息是否匹配。

其中,上述“证书相关信息”可以包括证书本身,也可以包括与证书密切 相关的信息,比如通过对证书进行哈希运算而得到的哈希值等。

采用实施例1提供的上述方法,当设置有中间人时,该中间人仅会在客户 端与服务器的握手过程中利用自身的自签名证书和服务器的身份信息(如域名 /Subject/Valid等信息),得到新生成证书,而对在客户端与服务器的非握手过 程中传递的服务器的证书相关信息不会执行类似操作,即在客户端与服务器的 非握手过程中传递的服务器的证书相关信息仍然是服务器的真实证书相关信 息。因此,通过比较握手过程和非握手过程中接收的同一服务器的证书相关信 息,可以达到辨识是否存在中间人的目的。

在一种实施方式中,为了使得中间人获取不到诸如用户机密信息(如针对 某服务器的登录名和密码)等机密信息,在判断出第一证书相关信息和第二证 书相关信息匹配时,可以执行特定操作。其中,这里所说的特定操作包括:使 得中间人接收不到机密信息的操作。

比如,一种执行特定操作的方式可以包括下述步骤:

展示提示信息;

接收用户指令;

根据用户指令,拒绝获得输入的机密信息,或取消对机密信息的发送。

上述提示信息可以包括“可能存在中间人,是否需要防范其攻击?”这样 的文本信息,同时,该提示信息还可以包含“同意防范”和“无需防范”这两 个选项。

后续当接收到用户通过选取“同意防范”这一选项而触发的用户指令时, 可以关闭包括机密信息输入入口的页面,从而达到拒绝机密信息的输入的目 的,进而也就达到了使得中间人接收不到机密信息的目的。

以下具体说明上述步骤21和22的一些可选的实现方式。

针对步骤21而言,获得在客户端与服务器的非握手过程中接收的服务器 的第二证书相关信息的时机可以包括:在发送机密信息前。

比如,在发送机密信息前,可以通过下述子步骤1~子步骤2,获得在客户 端与服务器的非握手过程中接收的服务器的第二证书相关信息:

子步骤1:向服务器发送机密信息页面获取请求;

其中,“机密信息页面”包括机密信息输入入口的页面,比如包括用户登 录名和密码的输入入口的登录页面。

子步骤2:接收服务器发送的机密信息页面。

其中,该机密信息页面中包含第二证书相关信息。

针对步骤22而言,在一种实施方式中,上述机密信息页面中还可以包含 检验脚本。

该检验脚本的存在,可以使得后续在对机密信息页面进行展示的同时,对 该检验脚本进行运行。运行该校验脚本的过程,即判断第一证书相关信息和第 二证书相关信息是否匹配的过程。

在一种实施方式中,当第一证书相关信息包括:证书,而第二证书相关信 息包括:证书所对应的哈希值(简称“对应的哈希值”)时,步骤22的具体实 现过程可以包括下述子步骤a~子步骤d:

子步骤a:对第一证书相关信息进行哈希运算,得到相应的哈希值;

子步骤b:判断对应的哈希值与得到的哈希值是否相同,在判断结果表示 对应的哈希值与得到的哈希值相同时,执行子步骤c;否则执行子步骤d;

子步骤c:确定第一证书相关信息和第二证书相关信息匹配;

子步骤d:确定第一证书相关信息和第二证书相关信息不匹配。

需要说明的是,实施例1所提供方法的各步骤的执行主体均可以是同一设 备,或者,该方法也由不同设备作为执行主体。比如,步骤21和步骤22的执 行主体可以为设备1;又比如,步骤21的执行主体可以为设备1,步骤22的 执行主体可以为设备2;等等。

实施例2

实施例2提供一种对SSL层中存在的中间人(即背景技术部分所说的SSL 代理)进行辨识,进而避免用户向中间人发送机密信息,从而防范中间人攻击 的方法。

实现该方法的系统架构示意图与图1类似,此处不再赘述。下文重点介绍 基于该系统架构,如何达到防范中间人攻击的目的。

请参考说明书附图3,其为实施例2提供的该方法的具体实现流程图。该 流程主要包括下述步骤:

1、客户端向服务器发起SSL握手请求;

2、SSL代理劫持来自客户端的SSL握手请求;

3、SSL代理向服务器发起SSL连接请求;

4、服务器响应SSL代理发起的SSL连接请求,并发送服务器自身的证书 给SSL代理;

5、SSL代理根据服务器(即真实服务器)的证书,使用自签名证书重新 签发一本证书(后文称新生成证书);

6、SSL代理将新生成证书推送给客户端;

7、客户端使用本地可信CA证书对收到的新生成证书做校验,校验通过;

8、客户端向服务器请求登录页面;

9、服务器向客户端回送携带有服务器的证书相关信息的登录页面;

10、客户端比较从应用层接收到的证书相关信息(即登录页面中携带的服 务器的证书相关信息)和SSL握手过程中获得的新生成证书的一致性,并在比 较结果表示从应用层接收到的证书相关信息和该新生成证书不一致时,弹出告 警,由用户选择是否继续登录,或终止登录。

11、客户端发送包含登录信息密文的HTTPPOST。

在一种实施方式中,当步骤9中所述的登录页面中携带的证书相关信息包 括对服务器的证书执行哈希运算而得到的哈希值时,该登录页面中还可以包含 检验脚本。客户端在接收到该登录页面后,通过运行该检验脚本,可以触发客 户端获取SSL握手过程中获得的新生成证书,并对该新生成证书执行哈希运 算,得到哈希值。

进一步地,客户端可以判断登录页面中携带的哈希值与对新生成证书执行 哈希运算得到的哈希值是否匹配,若不匹配,则弹出告警,由用户选择是否继 续登录,或终止登录。

通过本申请实施例2提供的上述方法可知,该方法可以有效地辨识出服务 器和客户端之间存在中间人(即SSL代理),从而可以通过向用户发出告警的 方式,避免客户端传输的机密信息受到来自中间人的潜在的安全威胁。

实施例3

为了解决现有技术中的客户端无法辨识客户端与服务器之间是否存在中 间人的问题,本申请实施例3提供一种对中间人的存在进行辨识的装置,该装 置的具体结构示意图如图4所示,包括信息获得单元41和辨识单元42。

其中,信息获得单元41,用于获得在客户端与服务器的握手过程中由客户 端接收的服务器的第一证书相关信息,以及在客户端与服务器的非握手过程中 由客户端接收的该服务器的第二证书相关信息;

辨识单元42,用于判断信息获得单元41获得的第一证书相关信息和第二 证书相关信息是否匹配。

在一种实施方式中,信息获得单元41可以是在发送机密信息前,获得在 客户端与服务器的非握手过程中接收的服务器的第二证书相关信息。

在一种实施方式中,信息获得单元41可以划分为以下子单元:

发送子单元,用于向服务器发送机密信息页面获取请求;

接收子单元,用于接收服务器发送的机密信息页面。

其中,机密信息页面中包含第二证书相关信息。

在一种实施方式中,当机密信息页面中包含有检验脚本时,辨识单元42 可以用于通过运行该检验脚本,判断第一证书相关信息和第二证书相关信息是 否匹配。

在一种实施方式中,若第一证书相关信息包括证书,第二证书相关信息包 括证书所对应的哈希值,则辨识单元42可以用于:对第一证书相关信息进行 哈希运算,得到相应的哈希值;判断第二证书相关信息包括的证书所对应的哈 希值与得到的哈希值是否相同;若相同,则确定第一证书相关信息和第二证书 相关信息匹配;若不相同,则确定第一证书相关信息和第二证书相关信息不匹 配。

在一种实施方式中,本申请实施例3提供的该装置还可以进一步包括操作 执行单元。该操作执行单元用于在辨识单元42判断出第一证书相关信息和第 二证书相关信息匹配时,执行特定操作。

其中,上述特定操作可以但不限于包括:使得中间人接收不到机密信息的 操作。

在一种实施方式中,操作执行单元可以用于执行下述操作:

展示提示信息;

接收用户指令;

根据用户指令,拒绝机密信息的输入,或拒绝获得输入的机密信息,或取 消对机密信息的发送。

当设置有中间人时,该中间人仅会在客户端与服务器的握手过程中利用自 身的自签名证书和服务器的身份信息(如域名/Subject/Valid等信息),得到新 生成证书,而对在客户端与服务器的非握手过程中传递的服务器的证书相关信 息不会执行类似操作,即在客户端与服务器的非握手过程中传递的服务器的证 书相关信息仍然是服务器的真实证书相关信息。因此,通过比较握手过程和非 握手过程中接收的同一服务器的证书相关信息,可以达到辨识是否存在中间人 的目的。

本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计 算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结 合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包 含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、 CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

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

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

在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输 出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器 (RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flashRAM)。 内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任 何方法或技术来实现信息存储。信息可以是计算机可读指令、信息结构、程序 的模块或其他信息。计算机的存储介质的例子包括,但不限于相变内存 (PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其 他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读 存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器 (CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁 磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算 设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒 体(transitorymedia),如调制的信息信号和载波。

还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非 排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包 括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、 方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括 一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设 备中还存在另外的相同要素。

本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程 序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和 硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算 机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、 光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技 术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所 作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号