美国计算机应急响应小组(US-CERT)警告:很多拦截HTTPS流量的安全产品都没有很好地验证证书。
使用安全产品检测HTTPS流量的公司,可能无法避免地弱化了其用户加密连接的安全性,将用户暴露给中间人攻击。
US-CERT是美国国土安全部(DHS)下属机构,在最近的一次调查过后发布了一份咨询公告,称HTTPS检测产品并不能完全反映出客户端和服务器间原始连接的安全属性。
HTTPS检测会核对来自HTTPS站点的加密流量,确保不含有威胁或恶意软件。该过程通过拦截客户端到HTTPS服务器的连接来实现,会以客户端的名义创建连接,然后用本地产生的证书对发送给客户端的流量再次加密。做这项工作的产品基本上都相当于中间人代理。
典型企业环境中,HTTPS连接甚至能被拦截并重加密多次:在网络边界被网关安全产品或数据泄露预防系统拦截加密,在终端系统上被需要检测此类流量中恶意软件的反病毒程序拦截加密。
问题在于:由于任务落到了拦截代理身上,用户浏览器便不再能够验证真正的服务器证书了。而实际上,安全产品在验证服务器证书上表现特别糟糕。
最近,多家机构的研究人员对HTTPS检测实践进行了调查。这些机构包括谷歌、Mozilla、CloudFlare、密歇根大学、伊利诺伊大学香槟分校、加州大学、伯克利和国际计算机科学研究所。
他们发现,从美国连至CloudFlare内容分发网络的HTTPS流量中,超过10%都被拦截了;而去往电商网站的连接有6%被拦截。
分析发现,被拦截的HTTPS连接中,32%的电商流量和54%的CloudFlare流量,这比用户直接连接服务器更不安全。
值得注意的是,被拦截连接不仅仅使用更弱的加密算法,其中10-40%支持的还是那些已知被攻破的密码。这些会导致中间人攻击之后的拦截、降级、甚至解密该连接。 |
原因在于,浏览器制造商具备长期且恰当的专业知识理解TLS连接和证书验证的潜在怪癖。可以说,再没有比现代浏览器实现得更好的客户端TLS(HTTPS采用的加密协议)了。
安全产品厂商使用过时的TLS库,定制这些库,甚至尝试重新实现该协议的一些功能特性,造成了严重的漏洞。
US-CERT指出的另一个普遍问题是,很多HTTPS拦截产品没能恰当地验证服务器提供的证书链。
“证书链验证错误很少发送给客户端,致使客户端认为各项操作都是按照预期与正确的服务器进行的。”
BadSSL网站上,公司企业可以检验其HTTPS检测产品是否不恰当地验证证书,或者允许了不安全密码通行。来自 Qualys SSL Labs 的客户端测试,同样可以对某些已知TLS漏洞和缺陷进行检测。
卡内基梅隆大学CERT协调中心发表了博客文章,披露了HTTPS拦截常见陷阱的更多信息,以及可能有漏洞的产品名单。