ssl pinning mode
https抓包的问题，工作的一个小争论引发的，不相信https可以抓包分析数据，非要我演示一次。https抓包其实早就已经烂大街，本着用事实说话的方式，安装了Charles，发现竟然有部分如淘宝，支付宝的包无法解析，jd的是正常的，好奇的查了一下，才知道现在有ssl pinning mode这个东西。
简述一下https的连接过程
上图中实线部分是必须的，虚线部分是可选的。该流程完成了两个任务：服务器身份的验证、加密传输对称加密密钥。
1、client hello和 server hello表示双方要建立一个加密会话。
2、服务器把数字证书传输给客户端，证书中包含服务器公钥，客户端用公钥解析证书中的数字签名，可以验证服务器的身份。
3、Server Hello Done表示hello 流程结束。
4、客户端生成一个对称加密密钥，用于实际数据的加密传输，并用服务器的公钥加密，把对生成的密钥传递给服务器。同时携带一个用刚刚生成的加密密钥加密的“client finished”。
5、服务器收到对称加密密钥，并尝试用该密钥解密加密字段，如能得到明文“client finished”，认为该密钥有效，可以用于之后的数据加密传输。同时用该密钥加密“server finished”，传递给客户端。
6、客户端用对称机密密钥解密，如能得到明文“server finished”，客户端认为该服务器已经正确的接收到对称密钥。
7、加密数据传输开始。
虚线部分是服务器端要求验证客户身份,和双向认证有关。
解决的问题
- 内容加密。浏览器到百度服务器的内容都是以加密形式传输，中间者无法直接查看原始内容。
- 身份认证。保证用户访问的是百度服务，即使被DNS劫持到了第三方站点，也会提醒用户没有访问百度服务，有可能被劫持
- 数据完整性。防止内容被第三方冒充或者篡改。
带来的问题：中间人攻击（MITM）
- 客户端首先要向远程的服务器发送建立连接的请求，并带有自己的支持的加解密的方式级别，这个过程经过了中间人的窃听，中间人把消息修改后发给了真正的目的地——服务端
- 服务端收到了要建立https链接的请求后，会发送当时从证书签发机构签发的公钥证书。这个过程中中间人又窃听了，然后中间人替换上自己的证书后又转发给了客户端。
- 客户端收到了中间人发过来的公钥证书，验证证书的真伪，并产生随机的对称加密的密钥，用中间人发的公钥加密后发给了中间人。由于刚才客户端收到的公钥证书本身就是中间人产生的，所以中间人用相应的私钥就解开了，拿到了客户端产生的那个随机产生的对称加密密钥。中间人再用刚才服务端返回的公钥证书加密这个客户端产生的用来对称加密的密钥，发给服务端。
- 服务端收到了当时用自己下发的公钥的证书加密的对称加密密钥，用自己的私钥解密，也得到了对称加密的密钥。
用Charles来搞是比较常见的，网上的教程也是一把一把的，大部分https的数据包都的可以解析出来，但是阿里系的不行。