sni机制浅析—waf运营中的坑
2021-08-12 16:40:49 Author: www.freebuf.com(查看原文) 阅读量:24 收藏

freeBuf

主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

背景

之前在替换到期的服务器ssl证书时发现HTTPS站点进行业务访问时,WINDOWS XP客户端IE浏览器获取到的ssl证书和网站证书不一致问题,经排查问题是WAF的证书管理机制适配性造成。公司使用的某厂waf证书管理机制实现原理为WAF的证书管理做了一个证书池机制,有且只有一个证书池。一台WAF的所有证书都在这个证书池内,每次证书交互都存在一定几率返回证书错误的现象。一直到新版本补丁新增SNI功能支持,依托SNI功能实现证书和https站点的绑定关系。但是存在一个缺陷,当客户端不支持SNI功能的时候,还会存在证书交互错误的现象。

总得来说sni机制还是属于特定条件下遇到的一个坑(windows xp,android4.3以下的系统),如果由于客户终端环境遇到访问https业务异常的时候,可作为一个可选排查项。接下来本文讲一下sni机制。

工作原理

waf反向代理模式,用nginx作为前端负载均衡器并负责https集中解密工作(以用户访问的域名为依据进行流量分配,同样的也是以域名为依据来判断应该将哪张证书丢给用户。即:SNI(Server Name Identification)功能

1、用户通过DNS解析获知"a.test.com"、"b.test.com"、"c.test.com"三个域名对应的IP都为"192.168.178.154"

2、用户与"192.168.178.154"进行SSL握手,获取相应域名证书后再次向"192.168.178.154"发起真正的http(已加密)请求

3、"192.168.178.154"收到加密后的http请求后先进行解密,然后再根据相应的策略向后端服务器server1-3发起http请求(未加密)

4、后端服务器server1-3进行处理后将回应的包发送给nginx,nginx将该数据进行加密后再次封装然后发送给用户

以上流程xp在访问http站点时,一切正常,但到了https站点的情况,则有所不同:

xp在进行ssl握手时,第一次使用TLSv1握手失败,然后自动换用SSLv3进行握手,但依然失败。

尝试用win7访问https站点,发现可以成功,比较两者:

可以看到WIN7的hello包中携带了Extension:server_name字段,并且里面包含了要访问的域名信息。而反观WINXP则没有该字段,所以WIN7发hello的时候的nginx就会回应hello,而WINXP发hello时nginx就会回Alert。

所以结论就很明显了,WINXP在使用IE访问https网站时,服务器不能使用SNI方式进行分流,不然会因为不能建立SSL握手而访问失败。

解决方案

那么windows xp如何访问https站点呢,以下为使用搜狗浏览器抓的包。

搜狗浏览器在发送SSL的hello包时会携带Extension:server_name字段。

可以发现换浏览器是可以解决这一问题,但是作为服务器方的我们是不能要求客户的浏览器,那么服务器方面有什么解决方案呢?有的,主要是两种:

1、服务端通过IP地址颁发证书(WINXP虽不携带访问的域名信息,但它总有三层包头吧!

2、服务端全站只用一张大通配证书,无论用户访问哪个域名都将该证书丢给它。


文章来源: https://www.freebuf.com/sectool/284468.html
如有侵权请联系:admin#unsafe.sh