分析两种实现SSL会话劫持的典型技术
分析两种实现SSL会话劫持的典型技术
本文由CSDN-蚍蜉撼青松【主页：http://blog.csdn.net/howeverpf】原创，转载请注明出处！
自SSL问世以来，在其应用范围越来越广泛同时，多种针对SSL协议本身的缺陷或者其不规范引用的SSL会话劫持方法也随之出现，下面将详细分析两种典型的SSL会话劫持的实现原理和实现条件。【读者如果想要参考SSL中间人的实际案例，可以阅读因特尔开发人员专区的这篇文章《针对SSL的中间人攻击》】
一、利用伪造的X.509证书
1.1 会话劫持原理
当SSL客户端与SSL服务端建立连接时，在正常的连接握手阶段，客户端必定会要求服务端出示其X.509公钥证书，并根据以下3个要素验证服务器证书的有效性：
a）该公钥证书的subject name(主题名)和所访问的服务器站点的名称是否一致；
b）该公钥证书的是否过期；
c）该公钥证书及其签发者证书链中的证书的数字签名是否有效（层层验证，一直验证到根CA证书为止）。
当SSL客户端访问一个基于HTTPS的加密Web站点时，只要上述三个要素有一个验证没有通过，SSL协议就会发出告警，大多数浏览器会弹出一个提示框，提示服务器证书存在的问题，但不会直接断开SSL连接，而是让用户决定是否继续。图1-1展示了IE浏览器弹出的安全警报提示框。
图1-1 IE浏览器验证服务器证书失败后弹出的提示框
大多数浏览器在验证到服务器证书存在问题后的处理方式是存在巨大隐患的，因为用户往往由于缺乏安全意识或者图方便而选择接受不安全的证书，这就使得伪造一个和合法证书极为相似的“伪证书”骗取SSL 客户端用户信任的手段成为可能。【要伪造证书就必然要先获取真正的证书，手工获取方法可参见我去年写的一篇博文《怎样手工获取我们所感兴趣网站的公钥证书？ 》】图1-2展示了这种SSL会话劫持的主要流程（图中，C为SSL客户端，M为监测主机，S为SSL服务端）
图1-2 基于伪造证书进行劫持的流程
文字描述如下：
- 主机M通过数据流重定向技术，使得主机C与主机S之间的通信流量都流向主机M，主机C本欲与主机S建立SSL连接，但发送的连接建立请求被重定向到了主机M；
- 主机C首先与主机M建立TCP连接，然后向主机M发起SSL连接请求；
- 主机M收到来自主机C的连接请求后，首先与主机S建立TCP连接，然后向主机S发起SSL连接请求；
- 主机S响应主机M的请求，由此主机M与主机S之间成功建立SSL连接，主机M同时获得主机S的X.509公钥证书Certificate_S；
- 主机M根据Certificate_S中的关键信息（主要是subject name、有效期限等）伪造一个极相似的自签名证书Certificate_S’,并以此证书响应第②步中，来自主机C的SSL连接请求；
- 主机C的浏览器验证Certificate_S’的有效性，发现subject name与请求的站点名称一致，证书还在有效期内，但是并非由信任的机构颁发。于是弹出提示框，让用户选择是否继续。由于Certificate_S’与Certificate_S从外表上几乎看不出来差别，大部分用户会选择继续（这是SSL会话劫持可以成功的关键），由此主机C与主机M成功建立SSL连接。
- 这样以后，主机C发往SSL服务端的数据，主机M可以捕获并解密查看；主机S返回给SSL客户端的数据，主机M也可以捕获并解密查看。至此，主机M实现了完整的SSL中间人监测。
经过以上步骤，主机M成功实现了主机C（SSL客户端）与主机S（SSL服务端）之间的会话劫持，并可以对明文形式的会话内容进行监测。
1.2 成功的必要条件
这种类型的SSL会话劫持成功的必要条件如下：
- a） 能够通过ARP欺骗、DNS欺骗或者浏览器数据重定向等欺骗技术，使得SSL客户端C和服务端S之间的数据都流向中间人监测主机；
- b） SSL客户端在接收到伪造的X.509证书后，用户选择信任该证书，并继续SSL连接；
- c） SSL服务端未要求对SSL客户端进行认证。
二、利用HTTP与HTTPS之间跳转的验证漏洞
2.1 会话劫持原理
用户浏览网页时，使用SSL协议的方式一般有两种。一种是在浏览器地址栏输入网址时直接指定协议类型为HTTPS，另一种是通过HTTP响应的302状态将网页重定向到HTTPS 链接。2009年2月在美国拉斯维加斯举行的BlackHat黑客大会上，安全研究人员Moxie Marlinspike演示了通过自己研发的SSLstrip工具劫持SSL会话来截获注册数据的方法，为SSL会话劫持提供了新思路。
SSLstrip使用了社会工程学的原理：许多人为了图方便省事，在输入网址时一般不考虑传输协议，习惯上只是简单输入主机名，浏览器默认在这种情况下会使用HTTP协议。例如用户为了使用Gmail邮箱，直接输入accounts.google.com，浏览器会给谷歌服务器发送一个HTTP 请求，谷歌服务器认为电子邮件属于应加密的重要事务，使用HTTP不恰当，应改为使用HTTPS，于是它返回一个状态码为302的HTTP 响应，给出一个重定向网址https://accounts.google.com/ServiceLogin?passive=1209600&continue=https%3A%2F%2Faccounts.google.com%2FManageAccount&followup=https%3A%2F%2Faccounts.google.com%2FManageAccount，浏览器再使用这个重定向网址发出HTTPS 请求。一个原本应该从头到尾使用HTTPS加密会话的过程中混入了使用明文传输的HTTP会话，一旦HTTP会话被劫持，HTTPS会话就可能受到威胁。SSLstrip 正是利用这一点，通过劫持HTTP 会话劫持了SSL会话，如图2-1所示。
图2-1 SSLstrip原理示意图
下面具体阐述基于SSLstrip的SSL会话劫持流程（阐述中依然以主机C为SSL客户端，主机M为监测主机，主机S为SSL服务端）：
- 主机M通过ARP重定向技术，使得主机C所有与外网的通信流都会从主机M处经过。
- 主机C向主机S的一个HTTPS页面发出一个HTTP请求，主机M监听这个请求并转发给主机S。
- 主机S返回一个状态码为302的HTTP 响应报文，报文消息头中Location头域以及消息实体中都给出了重定向网址，形式分别为，“Location: https://***.com/…”与“
- 主机M解析来自主机S的响应报文，将其中所有的https替换成http，指定主机M另一个未使用的端口为通信端口（假设为8181端口），并且记录修改过的url。需要做的替换包括：消息头中的“Location: https://***.com/…”替换成“Location: http://***.com:8181/…”；消息实体中链接“< a href=”https://***.com/…”>”替换成“
- 主机C解析经过篡改后的HTTP响应报文，经过重定向与主机M的8181端口通过HTTP方式建立了连接，二者之间通信数据明文传输。
- 主机M冒充客户端与主机S建立HTTPS会话，二者之间的通信数据通过密文传输，但主机M可以自由地解密这些数据。
- 经过以上步骤，主机M成功实现了主机C（SSL客户端）与主机S（SSL服务端）之间的会话劫持，并可以对明文形式的会话内容进行监测。
2.2 成功的必要条件
这种类型的SSL会话劫持成功的必要条件如下：
- a） 能够通过ARP欺骗、DNS欺骗或者浏览器数据重定向等欺骗技术，使得SSL客户端和服务端S之间的数据都流向中间人监测主机；
- b） 客户端访问的Web页面存在http页面至https页面的跳转；
- c） SSL服务端未要求对SSL客户端进行认证。
三、两种典型SSL会话劫持技术的对比小结
传统的基于伪造X.509证书的SSL会话劫持方式，其最大的问题就在于客户端浏览器会弹出警告提示对话框，这个提示是如此醒目，以至于只要用户有一定的安全意识和网络知识，劫持成功的概率就会大大降低。随着网络知识的慢慢普及，这种技术的生存空间会越来越小。
基于HTTP与HTTPS之间跳转验证漏洞的SSL会话劫持方式，是近几年新出的一种技术。在此种方式下，客户端浏览器不会有任何不安全的警告或提示，只是原先的HTTPS连接已经被HTTP连接所替换，迷惑性大大增强。一般为了进一步加强欺骗效果，监测主机还可以一个银色的“安全锁”图案显示在非安全的网址前面。但其缺陷也很明显，一旦用户在浏览器地址栏的输入中指定使用HTTPS协议，就会发现网页根本无法打开。因此只要用户养成良好的上网习惯，这种方式的会话劫持就会失败。
------本文由CSDN-蚍蜉撼青松【主页：http://blog.csdn.net/howeverpf】原创，转载请注明出处！------