https加密过程

自苹果要求使用https以来，项目中全部换用https请求了。平时开发中对https理解的也不是很深入，只是知道客户端和服务端都对数据进行了加密，在传输过程中是密文。最近面试过程中被询问到了，回答的不是很好，在这里做一下记录

• 第一步客户端发起一个请求，把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）发送给服务端
• 第二步 服务端，接收到客户端所有的Cipher后与自身支持的对比，如果不支持则连接断开，反之则会从中选出一种加密算法和HASH算法，以证书的形式返回给客户端 证书中还包含了 公钥 颁证机构 网址 失效日期等等。
• 第三步
  • 这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值（也就是私钥）。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
  • 然后再把证书加密后的随机值，让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值(私钥)来进行加密解密了。
• 第四步 服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

最后，客户端和服务端传输数据，都是用这个私钥进行数据的加密和解密。这样即使数据被抓取到了，因为不知道私钥，破解难度就上去了。

那到这里还有一个疑问，为什么我们平时可以通过Fiddler或者Charles进行抓包呢。
下面以Fiddler为例

因为我们在手机上事先安装了一个Fiddler的根证书，每次发起http请求时候，先和Fiddler建立了上面几步的联系，这样客户端发出的消息，Fiddler都会通过验证并知道内容。然后Fiddler再以客户端的身份，和服务器再建立上面所说几步的步骤，等于Fiddler相当于一个中转者的身份。每次把真正客户端发出的消息解密后再转发给服务器。
所以等于是我们自己提供了漏洞，允许Fiddler当做中间人。