关于Https安全性问题、双向验证防止中间人攻击问题

关于Https安全性问题、双向验证防止中间人攻击问题

最近项目中遇到一个问题，安全测试时反馈出，利用fiddler截取到了客户端与后台的https接口的明文内容，这是一个可怕的问题，那么接下来我从下面几点做一些概述和代码举例。

1、Https比Http安全性？
是的，Https是以安全为目标的Http版本，在Http上使用SSL层，进行加密传输（对称和非对称加密），还具备身份验证的功能（下面会重点说HTTPS的双向验证）。当然，Https是需要配置CA证书的，一般要从某些机构购买。

2、为何Https依然会被截取？
目前的一些抓包工具，fiddler、charles使用了叫做man-in-the-middle（中间人）机制：

著作权归作者所有。 商业转载请联系作者获得授权，非商业转载请注明出处。
作者：连山归藏
来源：知乎
第一步， fiddler向服务器发送请求进行握手， 获取到服务器的CA证书， 用根证书公钥进行解密， 验证服务器数据签名，获取到服务器CA证书公钥。
第二步， fiddler伪造自己的CA证书， 冒充服务器证书传递给客户端浏览器，客户端浏览器做跟fiddler一样的事。
第三步， 客户端浏览器生成https通信用的对称密钥，用fiddler伪造的证书公钥加密后传递给服务器， 被fiddler截获。
第四步， fiddler将截获的密文用自己伪造证书的私钥解开，获得https通信用的对称密钥。
第五步， fiddler将对称密钥用服务器证书公钥加密传递给服务器， 服务器用私钥解开后建立信任，握手完成， 用对称密钥加密消息， 开始通信。
第六步， fiddler接收到服务器发送的密文， 用对称密钥解开，获得服务器发送的明文。再次加密， 发送给客户端浏览器。
第七步， 客户端向服务器发送消息， 用对称密钥加密， 被fidller截获后，解密获得明文。
由于fiddler一直拥有通信用对称密钥， 所以在整个https通信过程中信息对其透明。也就是说fiddler&charles向服务器冒充是客户端，向客户端又谎称自己是服务器。

这就解释了问什么截取到了Https的数据，并且，Https在传输过程加密，所以到了客户端已经不是Https传输加密的范围了，这个时候其实很多人都是这么解决的，对Https数据先自己进行加密（Ex：AES、RSA），再Https传输，这样即使截取到Https数据，也看不到明文。那么有没有方式可以不让fiddler&charles这种家伙截取到Https呢？有，就是Https的双向验证；

3、Https双向验证
服务器端对请求它的客户端要进行身份验证，客户端对自己所请求的服务器也会做身份验证。服务端一旦验证到请求自己的客户端为不可信任的，服务端就拒绝继续通信。客户端如果发现服务端为不可信任的，那么也中止通信。具体怎么做呢？

首先我们需要服务器端到处证书给我们，那我公司举例，后台给我一个.cer文件，我用它导出一个.p12文件，将这两个导入Xcode工程resource目录下：

接下来，有大致三种方式来进行双向认证：
（1）用NSURLConnection，需添加俩delegate

- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace: