移动端破解TLS加密的数据的设计思路

  本文主要讲解了破解移动端HTTPS数据的思路，今天跟大家分享一下。

  在上一篇文章中，讲述了如何通过浏览器和wireshark之间的关系，来破解利用浏览器访问的加密数据，在那篇文中曾提到过，中间截获的数据是没有办法解密，其实也不准确。举个栗子，如果在局域网中，能够通过共享等方式拿到那个环境变量为SSLKEYLOGFILE对应的文件，还是能够解密相应的数据流量的，当然还有其他的解决思路，这就是我们这次会涉及到的内容。但是这次的重点是移动端如何破解TLS加密数据，毕竟移动为王。

  由于这块内容比较多，准备用两篇文章来讲解，先讲一讲这个破解移动端的设计思路，然后在讲一讲具体的实现方法。我梳理思路写这篇文章的时候，上网更新了一下很多已经快遗忘的知识点，发现有很多地方是值得分享出来的，以后有时间陆续在写。

  在PC端的网络通信主要集中在浏览器上，因此总体的思路是让浏览器给wireshark提供实时的秘钥。其实这里面有两个方面需要注意：1、我们所使用的浏览器是firefox和chrome，如果使用别的浏览器怎么办？2、如果产生的HTTPS等流量不是来自于浏览器，而是其他应用软件怎么办？PC端所面临的问题也是这次对应移动端所要解决的问题。来分析一下移动端，对应问题一，移动端的浏览器也是多种多样；对应问题二，移动端的网络流量更多的来自于各种各样的app软件。按照这样的想法，如果这次的设计思路能够解决移动端的问题，PC端问题应该是可以解决的。

  对于通过应用软件导出实时秘钥的局限性在于不是所有的浏览器和应用客户端都能够实现导出秘钥的功能。所以思路要切换一下，引入第三方，然后可能会想到网络劫持，然后就是HTTP代理。我们从HTTP代理来寻找相应的解决方案。

  传统的HTTP通信方式经过HTTP代理的时候，面临着用户数据被窃取的风险，这自不必说，那么HTTPS通信经过HTTP代理的时候，会不会存在同样的问题？回答此问题，要从TLS的原理谈起，上一篇文章都有介绍，可以回顾下。TLS握手过程中涉及到了一个叫做证书的东西，可以通过

http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html，对数字证书有一个了解。HTTPS的通信中证书都是都权威的第三方来颁发给服务器（利用CA私钥加密），然后IE和firefox等默认集成了几家可信的根证书（CA的公钥），多提一点firefox和IE是两大体系，至少在我们证书的管理是不一样。我在chrome中查看系统集成的证书如下（调用IE的）：

 

  当然还有中级证书机构等证书，这其实是一个证书链树状结构，http://www.2cto.com/Article/201203/122095.html在这片文章中相关的概念讲的还是比较通俗易懂的。既然证书这个东西是由一些组织颁发的，那么作为HTTP代理服务器也是可以颁发的，只要让取得客户端的认可即可。问题到这里其实已经回到了一个叫做中间人攻击的场景，即HTTP服务器通过伪造证书来解密客户端和服务器之间通信的数据。

  我们知道TLS的握手协商阶段是不加密的（这种说法也不是十分准确，毕竟服务器发送给客户端的公钥是使用CA的私钥加密的），在没有数字证书之前的中间人攻击场景如下图：、

  

 

  按照原本的设计B利用A的公钥加密数据传输给A，因为A并没有告诉任何人A的私钥，因此即使你截获数据，破解也是没有现实意义的。但是C截获了A发送给B的公钥，让A和B在毫不之情的情况下偷梁换柱。

  数字证书的机制是为了应对这种攻击，使得B能够确认收到公钥的合法性，也即是说B能够知道收到的公钥是A的还是C的。这个问题从理论上来说是得到了有效的解决，但是在实际应用过程中，B如果认为A和C是合法的，那么上图的场景会同样的复现。C还是有机会解密数据，就是多了一层马甲，脱掉就是了。至于为什么B会认为C是合法的，举个栗子，找一个没有安装过12306证书的电脑（或者如果有证书，删除），访问显示如下：

   

  点击继续前往，其实就是相当于你信任并这个证书了（本地添加证书机构的公钥），但是chrome比较好的一点是，地址栏会一直打叉提示你，这不是一个权威的证书，点开那个小锁可以看到相应的证书信息，随时可以停用。这里令我费解的是，在chrome浏览器的设置->证书管理里面并没有找到相应的证书。我初步的推测是chrome证书的管理部分是依赖于IE的证书管理，而对于12306的这种情况，chrome应该是做了独立的证书管理机制。毕竟啥都依赖别人，并不好。而firefox有自己的一套证书管理机制，因此，访问12306，做完类似的操作之后（添加例外），firefox证书管理里面是由相关的证书的，如下图所示。

 

  上述的过程说明了我们认为12306是合法的，尽管浏览器开始并不是这么认为的（因为相应的浏览器开始的时候没有集成相关证书），我们添加了相应的证书，然后浏览器就认为其是合法的了。

  根据以上例子的思路，我们可以使用HTTP代理制作证书，通过一些方式让客户端接受，然后HTTP代理就可以获取明文数据了。整体的流程跟上面的中间人攻击场景图是一样的，只是C发给B的公钥放在了C自己颁发给自己的证书之中了，然后B使用已经信任的C的公钥解密……剩下的就顺理成章了。  

  整体的思路就是这个样子，有时间会写出具体的实现方法。再提一点，支付宝在未经用户允许的情况下，私自为用户添加了自己的证书，其相当于给用户添加了一个后门。然后你懂得。当然了，证书始终存在的问题就是颁发证书机构的可信度，其实这是一个相对论，棱镜门之后……