作者 GoSSIP_SJTU 2015-11-16 10:47:00
被查看了13557次 , 本文转载自:乌云知识库

SSL/TLS协议安全系列- SSL中间人攻击防范方案概述

Author:张天陆

0x00 简述

基于PKI体系的SSL/TLS协议近年来暴出很多安全问题,比如著名的HeartBleed、POODLE攻击和Freak攻击等,2014年关于SSL/TLS协议证书验证问题的CVE有成千个。针对SSL协议在实现中暴露出的各种问题,这里我们讨论一下现有的加固和防范方案,主要包括四个方面:

a) Key pinning策略
b) HSTS策略
c) 多路径证书检查策略
d) DNS-based authentication

下面我们基于这四个策略做详细介绍。

0x01 Key Pinning策略

1、 Key Pinning介绍

Pinning是把服务器的主机名和证书、公钥等密码学要素联系起来的一种安全技术。例如,当知道某网站的正确证书,再次链接此网站时,可以通过对比已知的正确证书和从网站接收到的证书,判断是否被中间人攻击。当然,没有必要在本地保存某网站的完整证书信息,可以对证书做hash(比如SHA-256),本地保存对应的hash值,这样比完整证书更便捷,并且节省空间。

相对证书pinning,更为实际的是public key pinning,因为很多时候证书在重新签发时,并没有更换其公钥信息,这也是为什么很多证书拥有相同公钥的原因。这样如果在本地pin的是公钥信息,那么收到不同的证书也没关系,只要公钥内容相同,就可以信任这些证书。

对于SSH此类不依赖于证书的协议,可以直接pin公钥,但是对于SSL/TLS协议,最好的方式是pin X.509证书的SPKI(SubjectPublicKeyInfo)部分对应的hash值,SPKI部分包含了公钥以及其他额外的用于安全验证的信息(包括所使用的公钥加密算法、公钥位数)。

2、 pin的位置

服务器基于安全考虑,会经常更换公私钥对;并且如果私钥泄露,也需要从CA重新签发证书;并且同一个网站有可能部署了多个公私钥对。而如果pin的是服务器的公钥,那么在维护和使用上会相当复杂。

基于上述因素的考虑,可以将pin的位置放在证书链上。一般来说证书链开始于终端证书,有一个中间CA证书,最后是根CA证书。如果pin的是后两个证书信息(中间CA或者根CA的证书信息),那么服务器终端更换证书时,只要是同一个CA签发的,那么证书链没变,pin的信息也不用更换。

但是这里会出现另一个问题,CA可能会有很多的上级中间CA,或者不同的根CA,服务器在更换证书时,即使选择的是相同CA,那么上级中间CA有可能不同。

基于这些考虑,最佳的pin位置可以选择在证书链的第二个证书上,就是给服务器签发证书的CA的证书,因为即使服务器更换证书,也会选择该CA进行证书签发,pin的信息不会变。

3、何时用pin

最有效的pinning方式,是在native application中。因为这时作为开发者可以控制通信双方,对于桌面应用和移动应用都可以,比如一些银行软件,支付软件等。

对于这种情况,如果开发者可以控制通信双方(客户端与服务器),从而既可以使用自己的证书作为pinning信息,也可以使用第三方CA签发的证书。

4、使用key pinning的不足:

  • 服务器私钥如果泄露,就需要更换密钥对,另外服务器会经常更改密钥对,为了使相同密钥加密的信息不要太多。这时就需要经常的更换pin的信息,操作复杂。
  • 另外同一站点有可能有多个证书,pinning的内容如果不全面,有可能产生错误信息。
  • 对于一些应用在更换pin信息时,需要通过软件升级的方式,不太方便。

0x02 HSTS策略

1、 HSTS简介

HSTS(HTTP Strict Transport Security)HTTP严格传输安全,最早于2009年提出,标准化于2012年11月的RFC 6797,是一套由互联网工程任务组发布的互联网安全策略机制。网站可以选择使用HSTS策略,强制浏览器使用TLS协议,并且中断所有证书出现错误的连接,从而减轻浏览器在执行TLS协议时所面临的一些危险。

HSTS策略的使用,主要解决了以下几个问题:

  • 面对一个主机名(没有指明协议),浏览器不知道该网站是否使用TLS协议;
  • 当遇到证书错误不是阻断连接,而是给用户告警(用户多会选择忽略);
  • HTTPS页面从一个HTTP origin加载资源,被称为mixed content,攻击者可以通过控制从不安全页面加载到https页面的mix content实现攻击效果;
  • cookie遵守的同源策略和web content的同源策略不同,只根据host隔离,因此https和http会共用cookie。

HSTS通过两种方式,解决以上问题:

  • 在本地将所有的http转换为https,保证使用了HSTS的网站,只能通过https访问;
  • 当遇到证书错误时,中断链接。

2、HSTS安全意义

一些支持https的网站一般情况下也会监听http的请求,之后再讲这些请求重定向为https。例如:当收到http://www.facebook.com时,会将用户访问重定向为https://www.facebook.com。这种重定向是不安全的,因为第一个请求使用的是http,攻击者可以从中获取一些敏感信息(比如之前安全会话中的coocie等),另外,攻击者还可能将用户重定向到一些钓鱼网站。并且根据用户的输入习惯,不会在主机名前加上https,更容易带来威胁。

HSTS策略防止了这种威胁的存在,它要求浏览器在本地将http协议强制转换为https,之后再与服务器通过https协议进行通信。

3、HSTS执行

服务器开启HSTS的方法是,当客户端通过HTTPS发出请求时,在服务器返回的超文本传输协议响应头中包含Strict-Transport-Security字段(非加密传输时设置的HSTS字段无效,Strict-Transport-Security 头信息当通过HTTP请求传递,会被浏览器忽略,因为攻击者可能拦截或者篡改HTTP连接头,直到第一次通过https进行安全连接,并且收到Strict-Transport-Security头信息,才会针对该网站配置HSTS策略,这里可以通过浏览器对HSTS preload方式解决)。

Strict-Transport-Security字段包括:

Strict-Transport-Security: max-age=expireTime [; includeSubdomains]

其中:max-age参数指明了过期时间,单位秒,浏览器需要记住这个网站只能通过HTTPS访问的时间;includeSubdomains是可选参数,指明该网站的子域名也需要通过https访问。

浏览器对Strict-Transport-Security字段处理:

当浏览器使用https第一次访问网站,收到服务器响应的包含该字段的头,会记录下这些信息,之后在有效期内,把对该网站的请求都转换为https。每次浏览器收到Strict-Transport-Security头,都会更新max-age指定的有效期时间,这样可以防止HSTS策略过期。

我们用图形简单介绍HSTS功能:

图1

图1标示了正常情况下,服务器收到http请求时,重定向为https的过程,该过程是不安全的;

图2

图2标示了第一次安全连接时,收到HSTS的Strict-Transport-Security头信息,之后的访问都会执行HSTS策略。

图3

图3标示HSTS策略执行时的过程。

4、HSTS部署

HSTS的部署要考虑到全面性。默认情况下,HSTS只针对返回Strict-Transport-Security响应头的主机名部署,但是很多站点可以部署多个域名,因此要注意HSTS策略部署到所有的域名。

对于一些只有一个主机名的网站也需要考虑部署是否全面的问题。例如用户想要访问某网站时,没有加WWW前缀(输入XXX.com访问www.XXX.com),由于没法控制用户的输入,因此在配置HSTS时要注意覆盖到所有的主机名。

另外需要注意的是,HSTS部署的全面性要考虑到能够到达网站的所有的路径名,比如用户可能首先通过输入访问根域名,之后再访问其它子域名,此时根域名如果没有部署HSTS策略,有可能会招到SSL剥离攻击。

5、HSTS Preloading

当用户第一次正确使用https连接某网站,并且收到Strict-Transport-Security头时,才会根据头信息对该网站设置HSTS策略。为了提高HSTS的安全效率,解决“first visit”问题,Google安全团队在Chrome浏览器中设置了“HSTS preload list”,列表中的域名都会自动的使用HSTS策略。Firefox,Safari以及最新版本的IE浏览器,都会合并使用Chrome的HSTS preload list。

使用HSTS preload可以满足以下要求:

  • 确保了根域名和子域名都被强制使用https;
  • 对所有的子域名都标注了一个策略有效时间和preload标记,标示域名拥有者同意加入preload list中。

对于一些金融机构、政府网站或者社交网络等,HSTS策略可以缓解大量SSL/TLS协议遭受到的威胁。但是HSTS策略并不能低于证书伪造攻击,需要key-pinning策略协同使用。

0x03 多路径证书检测

多路径证书检查策略,核心思想就是不仅仅依赖PKI体系,抛开CA的权威性,通过多个途径和方法检验客户端收到的证书的合法性。

多路径证书检查的方法基本有两种:

  • 公证人辅助证书检查;
  • Tor-Network洋葱网络检查;
  • Social network借助社交网络检查。

这里我们主要介绍前两种方法。

1、公证人辅助证书检查

1.1 Notary简介

公证人协助验证证书,是指通过第三方(Notaries)机构,协助验证证书是否合法有效。最早的出现是Perspectives,Firefox的一个插件,可以将收到的服务器证书与大量的notaries进行对比,这些notaries来自于不同的网络节点,这样即使其中某些节点出现问题,攻击者仍然没办法将所有的notaries攻破。通过对比证书是否相同,判断是否遭受中间人攻击。

图4

图4展示了利用notaries进行证书比对的流程,当客户端收到服务器返回的证书后,向设定好的多个notaries发出请求,根据服务器主机名查找多个notaries中对应的证书,通过返回的证书进行比对,如果有不相同,则认为该证书无效。这些notaries部署在不同的网络环境中。

1.2 Notaries证书获取

最初的Perspectives所对应的Notaries,会定期的主动的扫描全网的主机,从中获取证书所对应的公钥,存储在本地数据库中,当浏览器的Perspectives插件需要进行证书比对时,从该数据库中获取对应主机的证书公钥,返回给客户端进行比对。2011年,Convergence notary提供了类似的功能,不同的是Convergence notary不会主动的进行全网扫描,仅仅当客户端索求一个本地数据库中没有的证书时,才会向对应的主机进行证书索取。目前Perspectives和Convergence是两个权威的notary维护机构,各自维护这多个可以被共用的notaries。

1.3 Notaries的评估

使用Notaries作为第三方,协助进行公钥检查,浏览器可以通过插件完全的依赖所设定的可信Notaries,弱化了以X.509证书为基础的PKI体系。同时,如果某个Notaries被攻破,用户完全可以自行更改设置,选择不同的Notaries。

使用Notaries进行证书验证也有一些缺点:

  • 降低了用户体验,多了一层证书验证流程,会降低网络访问速度;
  • 对于一些Notaries,会获取到用户想要访问哪些网站的隐私;
  • 一些网站可能会有多个证书,导致Notaries误报的情况出现。

2、Tor-Network 网络辅助证书检查

洋葱网络的特点是当用户访问某一个固定的目的端,每次经过的路径是随机的。具体来说,TOR客户端维护一个浏览器一样的代理,其他软件可以使用该代理提供的借口,进入Tor网络,TOR节点在不同次的连接时会选择不同的路径,不会轻易被中间人攻击。利用洋葱网络的这一特点,可以进行多路径证书检查。

洋葱网络辅助证书检查是建立在正常https协议出现证书警告的情况下,通过洋葱网络再次获取证书,比对两次得到的证书是否相同来判断是否遭受中间人攻击。

图5

图5展示了使用Tor-Network进行多路径证书检查的流程:

  • Alice收到https证书警告;
  • 通过洋葱网络代理,接入洋葱网络;
  • 获取目标服务器的证书;
  • 比对两次获取的证书是否相同。

多路径证书检查的思想都是通过多一次的证书获取,与收到的证书进行对比,从而判断是否遭受中间人攻击,提高通信的安全性,但是这种方式势必会增加TLS连接消耗的时间,降低用户体验。

0x04 DNS-based authentication策略

4.1 DANE简介

DANE(DNS-Based Authentication of Named Entities)是一种将域名和密码学要素联合起来的安全标准,2012年8月在RFC 6698中标准化定义。域名拥有者可以控制DNS的配置,能够利用DNS作为单独的一条渠道来加强TLS的安全执行。DANE方便部署,但是仅靠DNS并不能提供任何安全性质,还需要依靠DNSSEC协议。

DNSSEC简言之,就是利用数字签名身份认证技术,在进行域名请求时,验证整个请求链中的每个DNS的身份,确保最终收到的域名信息是正确的没有被篡改过。

目前的认证机制分为两个阶段:一是有一群我们信任的第三方机构为域名真正拥有者签发证书,成为CA;二是客户端(比如浏览器)能够检测某主机名对应的证书是正确的。基于这种分离式的架构是因为通信双方一般是远距离没法碰面的,验证身份容易找到欺骗。而基于DNSSEC协议,DNS请求就可以确保安全性,就可以利用DNS提供身份验证,这样就有一个新的途径同域名拥有者进行通信,从而抛弃掉对CA的依赖性。

简言之,DANE就是在客户端pin主机名对应的的证书,之后通过DNS请求时,获取主机名的证书,通过对比判断证书的可信性。

4.2 DANE作用

  • 安全的部署自签名证书

    现在,自签名证书被认为是不安全的,因为没有一种办法区分自签名证书和中间人攻击伪造的证书,也就是说自签名证书都是一样的。但是,我们可以用安全的DNS去pin一个自签名的证书,这样浏览器就可以知道正在使用的自签名证书是安全的,也可以很容易的区分出中间人攻击伪造的证书。

  • 安全的部署私有根证书 如果可以安全的pin一个服务器证书,那么也可以pin这个服务器证书所在的证书链中的任一证书,也就是说可以构造一个你所拥有的网站的根证书,并让客户端信任这个证书,这种方式对拥有很多网站的开发者来说,更为方便。

  • 支持CA颁发的证书和Public key-pinning DANE无须改变现有的认证架构,同样的可以在客户端pin CA颁发的证书和根证书。

4.3 DANE执行

DANE扩展了一种新的DNS记录类型,叫做TLSA Resource Record(TLSA RR或者叫做TLSA),TLSA包含四个区域:(1) Certificate Usage;(2)Selector;(3)Matching Type;(4)Certificate Association Data。

其中Certificate Usage字段有四种不同的值:

0-CA规范:pin一个CA,在证书链中必须有对应的CA签发的证书;
1-指定TLS证书:TLSA 记录指定应当用于某一域名的准确TLS证书;
2-信任点声明:在客户端pin一个某站点自己的CA,该CA可以不是公共信任的CA;
3-域名颁发证书:在客户端pin一个具体的TLS证书,该证书可以是某主机自己签发的证书

通过后两种值可以看出,DANE可以完美的支持自签名证书,同时也确保使用自签名证书的安全性。

自此,我们讲述了四种目前常见的SSL/TLS协议的加固策略,这四种策略固然各有优劣。其中key pinning可以和HSTS结合使用,确保强制使用https的同时也保证了证书安全性。另外,安全性和用户体验总是会存在一些冲突,在取和舍之间不同的人又有着不同的观点。

本文转载自:乌云知识库