白话SSL/TLS默认重协商漏洞原理与安全重协商对抗机制

  • A+
所属分类:系统文档

SSL/TLS协议是现代互联网安全的基础,任何网上银行、电子商务、电子政务、电子医疗等等互联网重要应用,都要基于SSL/TLS提供的安全、保密、可信机制才能正常运行。所以,任何SSL/TLS的安全漏洞都值得我们深入研究并理解。

什么是重协商?

白话SSL/TLS默认重协商漏洞原理与安全重协商对抗机制

在SSL/TLS协议中,协商是指通信双方客户端和服务器,选取相同算法、传递数字证书、互验对方身份、交换共享密钥等一系列的动作。重协商(即,重新协商)是指在已经协商好的SSL/TLS TCP连接上重新协商,用以更换算法、更换数字证书、重新验证对方身份、更新共享密钥等等。SSL/TLS协议本身支持重协商,且RFC文档建议SSL/TLS实现(指OPENSSL等库)也应该默认支持重协商。

重协商包括两种方式,分别如图A和图B所示:

白话SSL/TLS默认重协商漏洞原理与安全重协商对抗机制

图A是客户端主动发出ClientHello2进行重协商。

图B是服务器通过发出Hello Request消息,请求客户端发起重协商。如果客户端同意重协商,则才会发起ClientHello2。

不管是哪一方发起的重协商,如果接收方不同意的话,都会通过SSL Alert响应以拒绝重协商。

几年之前,美国某安全公司的研究人员发现SSL/TLS协议重协商机制有严重的安全漏洞,中间人可以利用这个漏洞,将自己的数据注入到客户端与服务器的SSL/TLS“安全连接”之中。该漏洞被发现的第二年,通过RFC 5746引入新的“安全重协商”机制,来解决这个漏洞。本文先介绍一下默认重协商机制的安全漏洞的原理,再介绍一下安全重协商机制是如何对抗这个漏洞的。

什么是中间人?

所谓中间人,通常可能有如下三种形式。

第一种是通过伪造ARP消息,对局域网内用户流量进行重定向,令其所有流量都通过中间人中转,从而中间人有机会对流量的内容进行监视或篡改。

第二种是通过伪造DNS消息,对互联网用户访问指定网站的流量重定向,令其与该网站之间的流量都通过中间人中转,从而中间人有机会对该网站相关的流量内容进行监视或篡改。

第三种是企业网关、企业防火墙、电信运营商GGSN/PGW网关设备等,用户的流量必须经过这些设备才能正常上网,这些设备天生就可以从“转发者”转变为“中间人”从而对流经的流量进行监视或篡改。

普通用户可能通常不会遇到前两种情况,但是第三种情况很有可能发生。所以,作为客户端和服务器的软件开发者、以及SSL/TLS库的开发者,出于为用户的安全着想,应该确保拒绝不安全的重协商,或者只支持安全的重协商。

重协商的安全漏洞原理

白话SSL/TLS默认重协商漏洞原理与安全重协商对抗机制

 客户端首先发出一个ClientHello1,客户端期待进行首次协商。(注意:客户端认为ClientHello1是首次协商)

 中间人收到ClientHello1之后,按理说它应该将其转发给服务器。但是中间人这时决定“作恶”,将ClientHello1缓存起来暂不转发。中间人自己构造一个ClientHello2,对服务器发起首次协商,协商好后中间人将精心伪造的数据发送给服务器。(注意:服务器认为ClientHello2是首次协商)

 服务器收到这些数据,会认为这是正常的数据。因为服务器的APP程序通常需要处理粘包,所以中间人如果了解APP协议(如HTTPS)的话,则会精心构造不完整的数据,让服务器的APP程序认为发生粘包,将数据暂缓不处理,继续等待后续的数据上来。

 这时,中间人调出之前暂缓的ClientHello1,将其在同一个SSL/TLS TCP连接中,发送给服务器。(注意:ClientHello1消息本身是加密的,因为其是在ClientHello2协商好后的加密SSL/TLS连接中传输)

 服务器收到ClientHello1后,认为这是一次重协商,协商好后,客户端发送真正的数据给服务器。

 服务器的APP程序,收到客户端的真正数据后,将其与之前缓存的中间人精心构造的数据粘合起来,进行业务处理。

从而,中间人在不需要劫持、解密SSL/TLS连接的情况下,成功地将自己伪造的数据插入到用户真正数据之前。这个安全漏洞可以让心机卓绝的中间人做好多事情,比如伪造一个HTTP GET消息,然后用HTTP的IGNORE字段屏蔽掉真正数据的HTTP GET头,但是却保留了用户的Cookie信息,从而利用用户的Cookie去访问网站内容,比如可能利用此法删掉用户之前发的帖子等。

这个漏洞成因在于,客户端认为的首次协商却被服务器认为是重协商,以及首次协商和重协商之间缺少关联性。RFC 5746引入明确首次协商与重协商的方法,以及确认首次协商和重协商的关联性校验,从而确保中间人的攻击行为可以被识别并拒绝,保证重协商安全。

白话SSL/TLS默认重协商漏洞原理与安全重协商对抗机制

客户端发起ClientHello1。

中间人缓存ClientHello1,精心构造ClientHello2,与服务器进行首次协商。这里假设中间人在ClientHello2中不携带安全重协商标识。

中间人与服务器协商成功,发送伪造的数据给服务器。

中间人将之前缓存的ClientHello1发送给服务器。

如果服务器禁止重协商,则这时看到ClientHello1,会认为发生了重协商,不允许,所以中断连接。

如果服务器禁止不安全的重协商、但允许安全的重协商,则因为之前中间人构造的首次协商消息ClientHello2中指示不支持安全重协商,所以现在收到ClientHello1认为发生了不安全的重协商,所以中断连接。

因此,这种情况以及各种子情景都没有问题,不会有安全漏洞。

白话SSL/TLS默认重协商漏洞原理与安全重协商对抗机制

客户端发起ClientHello1。

中间人缓存ClientHello1,精心构造ClientHello2,与服务器进行首次协商。这里假设中间人在ClientHello2中携带支持安全重协商标识。

中间人与服务器协商成功,发送伪造的数据给服务器。在这时,因为双方都支持安全重协商,所以服务器会要求中间人将服务器发送的Finish消息中的首次协商会话摘要信息记录下来,以便重协商时再带给服务器;当然,服务器自己也会将这个首次协商会话摘要信息记录到自己的内存中)

中间人将之前缓存的ClientHello1发送给服务器。

如果服务器禁止不安全的重协商、但是允许安全的重协商,且如果ClientHello1中支持安全重协商,则按照RFC 5746是不合理的,只有首次协商ClientHello才允许带有支持安全重协商标识,重协商阶段的ClientHello是不允许携带该标识的。所以,服务器认为可能是遇到攻击,中断连接。

如果服务器禁止不安全的重协商、但是允许安全的重协商,且如果ClientHello1中不携带支持安全重协商标识,则服务器会认为这是正常的重协商。然后,服务器会提取出前边第3步中记录的首次协商会话摘要信息,按照RFC 5746,ClientHello1中应该带有相同的这个首次协商会话摘要信息。但是,一方面客户端的ClientHello1是不可能带有这个信息的,所以服务器校验失败;另一方面,如果中间人将这个信息插入给ClientHello1,那么虽然服务器现在校验成功,但是后续服务器校验协商会话完整性时还是会失败。

总而言之,安全重协商机制会补上重协商的漏洞隐患,让中间人攻击无机可乘。

参考文献:

1. RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2

2. RFC 5746 Transport Layer Security (TLS) Renegotiation Indication Extension

--------------------- 

原文:https://blog.csdn.net/o4dc8ojo7zl6/article/details/78537550 

  • 我的微信
  • 这是我的微信扫一扫
  • weinxin
  • 我的微信公众号
  • 我的微信公众号扫一扫
  • weinxin

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: