Https校验证书防止抓包
iOS9.0之后苹果爸爸要求支持https，why?先看下http的缺点
HTTP请求的缺点
1. 通信使用明文（不加密），内容可能会被窃听
由于HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使用HTTP 协议通信的请求和相应的内容）进行加密。窃听通信并非难事，只需要收集在互联网上流动的数据包（帧）就行了。对于收集来的数据包解析的工作，可以交给抓包工具（Charles）
2. 不验证通信方的身份就可能遭遇伪装
任何人都已发起请求，HTTP 协议通信时，不存在确认通信方的处理步骤。服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的IP 地址和端口号没有被Web 服务器设定限制访问的前提下）
3. 无法证明报文完整性，可能已遭篡改
完整性是指信息的准确度，若无法证明其完整性，通常也就意味着无法判断信息是否准确。
比如，从某个Web 网站上下载内容，是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的。文件内容在传输途中可能已经被篡改为其他的内容。即使内容真的以改变，作为接收方的客户端也是觉察不到的，这个情况称为中间人攻击
Https
https是在http的基础上加了一层SSL，通过证书验证，非对称加密密钥和对称加密数据实现数据安全传输。
Https如何实现数据安全传输的？
怎么配置呢？
然后在AFHTTPSessionManager写
之前天真认为，这都是后台干的事，自己只需要在info.plist和改下改下AFHTTPSessionManager不进行证书校验这个就行了。
这是谁？谁说的？谁告诉你的？跟之前的我划清界限
----------------------------------------------------------------------------————————————————————
先看下证书的三种校验方式：
AFSSLPinningModeNone: 代表客户端无条件地信任服务器端返回的证书。
AFSSLPinningModePublicKey: 代表客户端会将服务器端返回的证书与本地保存的证书中，PublicKey的部分进行校验；如果正确，才继续进行。
AFSSLPinningModeCertificate: 代表客户端会将服务器端返回的证书和本地保存的证书中的所有内容，包括PublicKey和证书部分，全部进行校验；如果正确，才继续进行。
服务器是使用的HTTPS协议传输，并且买了权威机构的CA证书。但是客户端在发送请求时，未使用证书验证方式，这样就会存在中间人攻击的可能。所以说之前我的那种做法是不安全的。
单向验证
单向认证：保证server是真的，通道是安全的（对称密钥），校验证书，不可以抓包。
流程：
1.客户端向服务器端发送SSL协议版本号、加密算法种类、随机数等信息。
2.服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书。
3.客户端使用服务端返回的信息验证服务器的合法性，包括
证书是否过期
发行服务器证书的CA是否可靠
返回的公钥是否能正确解开返回证书中的数字签名
服务器证书上的域名是否和服务器的实际域名相匹配
验证通过后，将继续进行通信，否则，终止通信
4.客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择。
5.服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
6.服务器将选择好的加密方案通过明文方式返回给客户端。
7.客户端接收到服务器端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的秘钥，使用服务器端返回的公钥进行加密，将加密后的随机码发送至服务器。
8.服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密秘钥。
9.在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
准备
向我们亲爱的后台小伙伴要下他们申请的证书，.crt或者.pem的都可以，然后转成.cer证书，将.cer文件导入工程。
在AFHTTPSessionManager中按照上图进行写。注意AFHTTPSessionManager要用initWithBaseURL初始化，这样，单项验证就完了。
双向验证
保证client和server是真的，通道是安全的（对称密钥）
流程
.客户的浏览器向服务器传递客户端SSL协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。
2.服务器向客户端传送SSL协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。
3.客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括
证书是否过期
发行服务器证书的CA是否可靠
发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”
服务器证书上的域名是否和服务器的实际域名相匹配
如果合法性验证没有通过，通讯将断开，如果合法性验证通过，将继续进行第四步。
4.用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤2终端服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。
5.如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。
6.如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：
客户的证书使用日期是否有效
为客户提供证书的CA是否可靠
发行CA的公钥能否正确解开客户证书的发行CA的数字签名
检查客户的证书是否在证书废止列表（CRL）中。
检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。
7.服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于SSL协议的安全数据通讯的加解密通讯。同时在SSL通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。
8.客户端向服务器端发出信息，指明后面的数据通讯将使用步骤7中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。
9.服务器向客户端发出信息，指明后面的数据通讯将使用的步骤7中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。
10.SSL的握手部分结束，SSL安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。
差异：从单向认证和双向认证的流程来看，单向认证只要求站点部署了SSL证书就行，任何用户都可以去访问（IP被限制除外等），只是服务器端提供了身份认证。而双向认证则是需要服务端需要客户端提供身份认证，只能是服务端允许的客户能去访问，安全性相对要高一些。
双向验证的实例代码：
一般应用都是采用单向认证的，原因很简单，用户数目广泛，且无需做在通讯层做用户身份验证，一般都在应用逻辑成来保护用户的合法登入。但如果是企业对应对接，情况就不一样，可能会要求对客户端做身份验证。这时就需要做双向认证。
参考实例代码：
http://blog.csdn.net/guobing19871024/article/details/53841373
