中间人攻击流程：
注意事项说明：中间人用的伪证书，这个证书可能就是从CA官方申请的，客户端一般都会信任这类证书，这就是可以进行中间人攻击的原因所在。
注释：在上述流程结束后，就形成了下面的情况，以后客户端- - 中间人 - - 服务端 三者之间的加密内容，用的是2组密钥，所以中间人能看到双方的通信内容。
二、关键：为什么伪造证书是可以实现中间人攻击的？
1.答案就在于用户让ios系统信任了不应该信任的证书(安装了证书)。用户设置系统信任的证书，会作为锚点证书(Anchor Certificate)来验证其他证书。当返回的服务器证书是锚点证书，就被信任。
2.如果从CA申请证书打包到App中，把这个证书作为Anchor Certificate来保证证书链的唯一性和可信性。只相信app里面的锚点证书，也就只会验证通过由这些锚点证书签发的证书。这样就算被验证的证书是由系统其他信任的锚点证书签发的，也无法验证通过。
3.做法：选择哪个证书打包到app里面，很多开发者会直接选择叶子证书。其实对于自建证书来说，选择哪一节点都是可行的。而对于由CA颁发的证书，则建议导入颁发该证书的CA机构证书或者是更上一级CA机构的证书，甚至可以是根证书。这是因为：
1) 一般叶子证书的有效期都比较短
2) 越往证书链的末端，证书越有可能变动；
总结一句：就是在流程的第8步时，客户端检测系统的证书以外，还检测证书和客户端里面的证书是否一致，如果是，就是ok，不是，就拒绝连接。
三、iOS解决方案
AFSecurityPolicy * securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate]; //1
securityPolicy.allowInvalidCertificates = NO;//2
securityPolicy.validatesDomainName = YES;//3
//1.
a. AFSSLPinningModeNone : 你不必將憑證跟你的 APP 一起打包，完全信任伺服器的憑證
b. AFSSLPinningModeCertificate :（注意：如果用这个选项，必须把证书打包进去，不然他会直接返回NO，整个请求就) App本地打包证书，需要使用SecTrustSetAnchorCertificates（），这个函数在AFNetworking里面，就是这个AFSSLPinningModeCertificate状态里面的。
c. AFSSLPinningModePublicKey : 目前没有用到
//2 . allowInvalidCertificates 是否允许无效证书（也就是自建的证书），默认为NO 如果是需要验证自建证书，需要设置为YES
//3. validatesDomainName 是否需要验证域名，默认为YES；
//假如证书的域名与你请求的域名不一致，需把该项设置为NO；如设成NO的话，即服务器使用其他可信任机构颁发的证书，也可以建立连接，这个非常危险，建议打开。 置为NO，主要用于这种情况：客户端请求的是子域名，而证书上的是另外一个域名。因为SSL证书上的域名是独立的，假如证书上注册的域名是www.google.com，那么mail.google.com是无法验证通过的；当然，有钱可以注册通配符的域名*.google.com，但这个还是比较贵的。如置为NO，建议自己添加对应域名的校验逻辑。
//AFNetworking爆出HTTPS校验漏洞， AFSecurityPolicy 内的参数 validatesDomainName 默认为NO，这会导致校验证书的时候不会校验这个证书对应的域名。即请求返回的服务器证书，只要是可信任CA机构签发的，都会校验通过，这是非常严重的漏洞。
