上次分享了破解手机端加密数据的思路，就是使用中间人代理进行破解，网络安全把这种做法叫做man-in-the-middle，今天讲一下如何来实现。
恰巧2016年3月2号，360推送了一则关于代号溺亡的漏洞的消息，其本质讲的就是我们这篇文章所讨论的问题，但是我们干的是正经事。
既然涉及到中间人，我需要一个代理软件充当中间人的角色，这里我们选用软件fiddler，该软件是一个轻量级的抓包软件，但其同时实现了中间代理的的功能。抓包软件还是使用wireshark。至于为什么不直接使用fiddler来直接抓包分析，是因为fiddler毕竟是轻量级的（或者哥就是爱用wireshark），很多功能不如wireshark支持的广泛，比如长连接的功能，而且我们这里也只是使用其作为代理以及制作证书的功能。当然fiddler也有很多自身的优点和不足，后续我们会一点点看到。
本次实验的软件是全球最大的正版音乐服务平台spotify，使用该软件进行测试的原因是在测试中我需要确认其中的加密流是否为音频流。
在前面的文章中已经对SSL等相关知识以及解密原理已经做了详细的阐述，忘记的可以回顾一下。
这篇文章要分两个方面来讲移动端和PC端，整体的思想都是一样，实现会略有差别。
先说说移动端，通常的抓包环境如图1所示：
图1
即手机连上路由设备，在转发设备上部署Libpcap抓取手机IP的报文。
而现在我们需要在PC上部署代理软件，即fiddler，因为数据会走代理服务器PC，因此在PC上安装wireshark进行抓包，不再使用转发机器上的Libpcap抓包环境。
现在要做以下几件事情：
1，设置fiddler，如下图
安装完fiddler之后做如图2，图3所示的设置：路径Tools->FiddlerOptions
图2
图3
图4
HTTPS选项勾选上CaptureHTTPS，选择from remote clients only(实际过程中并不能过掉本机的报文，汗)；Connection选项选择allow remote compute to connect。HTTPS那个页面有关证书可能跟你的不一样，我在图4所示的页面下载了fiddler的一个插件进行证书而生成和私钥的导出，因为fiddler自带的证书生成器，不支持导出私钥功能，下载后在windows上安装即可。
2，给手机设置代理，长摁住所连接的wifi->显示高级->然后设置代理，如图5：
图5
图6 图7
代理服务器主机名就是你要链接的代理服务器IP地址；因为fiddler默认端口是8888，因此这里面代理服务器的端口设置为8888.
在手机浏览器输入PC IP加上端口号，进入相关页面下载证书，图中蓝色的Fiddler RootCertificate，安装，证书用途为app。如果你的手机没有设置密码策略，在安装证书的时候可能会提示你设置密码，设置即可。如图6和图7所示。
3，设置wireshark和fiddler进行关联，在Preferences->Protocols->ssl中新建，如图8
图8
图9
其中的mypem.txt文件是fiddler给出的私钥，具体制作的步骤是，当你做好1,2步的设置后，使用手机去访问该APP的时候，在fiddler的log页面会自动生成私钥（这就是第一步中安装插件的作用），将图9中红线部分标出的私钥存储在一个文本文件中即可，但是格式如下，用私钥把中间哪一行替换掉：
-----BEGIN PRIVATE KEY-----
Base64 encoded private key here
-----END PRIVATE KEY-----
至此，完成设置，重启fiddler，打开wireshark，为减少杂包的干扰，我们只抓8888端口的报文，如图10所示：
图10
使用wireshark抓取解密报文如图11所示
图11
我们可以看到绿色的http报文即为解密后的报文，在TLS握手之后。如果没有解密，这个包是加密的，颜色是灰色的TLS报文。这是直观上的感受。判断捕获的数据有没有解密，可以看TLS握手中的client key exchange报文，图12中红线表示的部分为解密后的数据，图13中红线表示的部分为没有解密的数据。
图12
图13
图14解释了为什么抓取8888端口的原因。因为只有手机和fiddler之间的通信(代理前)是经过解密的，因此要抓取这两者之间通信的报文，而fiddler使用8888端口和手机进行通信，因此使用8888端口。而fiddler和Server之间通信是没有解密的，fiddler端口也是随机的，因此没有必要获取这部分数据。其实同一份数据经过网卡两遍，一遍加密了，一遍没有加密，这也是抓取8888端口，过滤无用数据的原因。
图14
这种方式破解加密数据并不是一直有效，原因之一，
先了解SessionId的用处，即流关联。可参考相关文章。如果你所抓的第一个SSL加密包有相应的SessionID的话，表明这条流重用了前一个流协商的参数，而fiddler不知道这些从参数，那么相关数据就没法解密，图15是没有重用的情况，Session ID 为0，如果重用，会有一长串的字符。当然不能解密的原因还有很多，希望大家多多共享。
图15
移动端的就是这么多，PC端和移动端思路是一致的。但是实现方面略有差别，我这里面简单说一下。如果将PC软件和fiddler部署在一台PC机上面，如图14所示，应用软件和fiddler的通信，是进程间的通信，使用的是回环地址127.0.0.1，是不经过网卡的，也就是说wireshark是无法获取相应的解密数据包的。那么解决思路如下：
1，将wireshark的默认winpcap删除，安装Npcap进行抓包，原因就是windowsTCP/IP协议栈没有实现网络回环接口，详情参考https://wiki.wireshark.org/CaptureSetup/Loopback，不做过多解释。
2，使用两台PC机器，这里面和手机端抓包就对应上了，其中一台PC最为fiddler代理，另外一台PC相当于手机，具体参考手机的1,2,3步设置，PC代理设置应该都会。
整体的架构如图16：
图16
以上内容就是对移动端和PC端解密SSL流量的实际实现做了说明，其实是非常粗略和简单的。为什么这么说，是因为在实际的抓包过程中，我发现使用fiddler代理之后只抓到加密的图片报文，相应音频wireshark没有捕获到，经过排查，确立的原因是这部分流量不走HTTP代理，也就是说HTTP代理不支持这部分流量的转发，因此8888端口也就捕获不到。所以如果想要类似于这种流量的加密数据，那么可以将fiddler替换成sock代理，当然，相应的代理机器需要安装证书制作软件了。如果谁有兴趣，可以分享一下。
其实上述的内容给了我们一个启示，就是走代理并不安全，即使你的数据是加密的，常见的场景的我们很多人喜欢翻墙。你可能觉得，解密数据需要给你下证书，其实下证书可以神不知鬼不觉，当然也不尽然，下证书的策略基本可以利用到安全中的社会学攻击，本质可以理解为人性的弱点吧，我发现自己摇身一变成为了哲学家。大家看看这篇文章http://my.oschina.net/CasparLi/blog/488298?fromerr=NqwEdtDw，看完之后别太愤青。大家开始的时候都是流氓，有的人有了钱变得绅士了，有的人还是老样子，面对流氓有办法吗。
以上内容如有错误之处还请指出。