2016-10-27 11:20
最近在调试一个bug的时候没有其它好的办法了，用到了抓包这么个方式才发现问题，不过问题已经解决了
不过在抓包的时候突然想到了，我擦，我用的https也可以被抓到包啊。所以又看了一下https的链接建立的流程（SSL/TLS原理详解）和相关的中间人攻击的流程，想了一下其中的原理。
首先介绍一下在https建立的过程中是如何被中间人抓到包的吧，前提是如果不熟悉https建立连接的过程，先看一下相关资料再接着看本文
1.客户端首先要向远程的服务器发送建立连接的请求，并带有自己的支持的加解密的方式级别，这个过程经过了中间人的窃听，中间人把消息修改后发给了真正的目的地——服务端
2.服务端收到了要建立https链接的请求后，会发送当时从证书签发机构签发的公钥证书。这个过程中中间人又窃听了，然后中间人替换上自己的证书后又转发给了客户端。
3.客户端收到了中间人发过来的公钥证书，验证证书的真伪，并产生随机的对称加密的密钥，用中间人发的公钥加密后发给了中间人。由于刚才客户端收到的公钥证书本身就是中间人产生的，所以中间人用相应的私钥就解开了，拿到了客户端产生的那个随机产生的对称加密密钥。中间人再用刚才服务端返回的公钥证书加密这个客户端产生的用来对称加密的密钥，发给服务端。
4.服务端收到了当时用自己下发的公钥的证书加密的对称加密密钥，用自己的私钥解密，也得到了对称加密的密钥。
以后的通信都使用这个对称加密的密钥加密了。因为客户端，中间人，服务端都有了这个对称加密的密钥，所以都可以用此解密通信的内容。（上面的步骤是穿插了HTTPS建立握手过程和中间人的作用介绍的，属于简洁介绍，明白原理就可以了）。
上面有几个字“验证证书的真伪”标为了红色，其实一般来说这个过程应该是安全的，因为一般的证书都是由操作系统来管理（Firefox自己管理）的，所以只要操作系统没有证书链验证等方面的bug是没有什么问题的，但是为了抓包其实我们是在操作系统中导入了中间人的CA，这样中间人下发的公钥证书就可以被认为是合法的，可以通过验证的（中间人既承担了办法了证书，又承担了验证证书，能不通过验证嘛）。
忘了说了，这个抓包是非常全面的，就是可以抓到你请求的参数，返回值都可以看的非常的清楚。
客户端为了解决这个问题，最好的方式其实就是内嵌证书，比对一下这个证书到底是不是自己真正的“服务端”发来的，而不是中间被替换了。下面就介绍一下解决的步骤吧：
1.问运维要到接口站点的证书（即当初证书机构签完的那个放到nginx里的公钥证书），放到工程里面就可以，AF会自动去查找
2.AFNetworking设置以下代码
AFSecurityPolicy * policy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
_manager.securityPolicy = policy;
AF的安全策略会自动的在bundle里面查找公钥证书，建立https的时候进行比对。不一样直接就失败了。
PS：顺带介绍一下AF的AFSSLPinningMode的三个级别
AFSSLPinningModeNone: (默认级别)，客户端无条件信任任何下发的公钥证书
AFSSLPinningModePublicKey: 客户端本地去验证服务端下发的公钥证书的 public keys部分。如果正确才通过
AFSSLPinningModeCertificate: 客户端本地去验证服务端下发的公钥证书的所有部分。如果正确才通过
这样做了之后，就可以即使手机上安装了抓包工具的CA，抓包工具也不能抓到包了。因为你的客户端在验证“服务端”下发的公钥证书的真伪的时候就不会通过“中间人”下发的公钥证书，也就不会建立起来https的连接了。
其实使用了https，并且在系统没有被攻破或者有证书漏洞的时候就能保证通信过程的安全了。但是这样可以更近一步，以防止竞争对手抓取你们的数据之类的，毕竟数据被别人抓走了总是不好的。在写这个博文的时候尝试了一下可以被中间人抓包工具抓到完整包的有很多，知乎，贴吧，等好多。但是银行的金融类app就抓不到，相对的安全了很多了。
