正常HTTPS握手过程
第一步：客户端发起明文请求：将自己支持的一套加密规则、以及一个随机数（Random_C）发送给服务器 第二步：服务器选出一组加密规则和hash算法，并将自己的身份信息以证书（CA：包含网站地址、加密公钥、证书颁发机构等信息）和一个随机数（Random_S）发给客户端 第三步：客户端接到服务器的响应验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等）。如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。 如果证书受信任，或者是用户接受了不受信的证书，客户端做以下事情：
- 生成密码：浏览器会生成一串随机数的密码（Pre_master），并用CA证书里的公钥加密(enc_pre_master)，用于传给服务器。
- 计算协商密钥：enc_key=Fuc(random_C, random_S, Pre-Master)
- 生成握手信息：使用约定好的HASH计算握手消息，并使用协商密钥enc_key及约定好的算法对消息进行加密。
- 发送以下信息到服务器： 用公钥加密过的服务器随机数密码enc_pre_master 客户端发给服务器的通知，”以后我们都要用约定好的算法和协商密钥进行通信的哦”。 客户端加密生成的握手信息。
第四步，服务器接收客户端发来的数据要做以下四件事情：
- 私钥解密：使用自己的私钥从接收到的enc_pre_master中解密取出密码Pre_master。
- 计算协商密钥：enc_key=Fuc(random_C, random_S, Pre-Master)
- 解密握手消息：使用协商密钥enc_key解密客户端发来的握手消息，并验证HASH是否与客户端发来的一致。 生成握手消息使用协商密钥enc_key及约定好的算法加密一段握手消息，发送给客户端。这里要发的数据有两条：
- 服务器发给客户端的通知，”听你的，以后我们就用约定好的算法和协商密钥进行通信哦“。 服务器加密生成的握手信息。
第五步，客户端拿到握手信息解密，握手结束。 客户端解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束。
第六步，正常加密通信 握手成功之后，所有的通信数据将由之前协商密钥enc_key及约定好的算法进行加密解密。 这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码和hash算法，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。 从握手过程，我们可以得知：
- 通过CA可以确认网站的合法性
- 通过enc_key来加密解密，在传输过程中，为了保证enc_key不被解破，在客户端用公钥加密后，在服务器端用私钥解密，私钥只有服务器端有，所以即使报文被截获，也无法破解。
Fiddler获取HTTPS请求过程
第一步， fiddler向服务器发送请求进行握手， 获取到服务器的CA证书， 用根证书公钥进行解密， 验证服务器数据签名， 获取到服务器CA证书公钥。
第二步， fiddler伪造自己的CA证书， 冒充服务器证书传递给客户端浏览器， 客户端浏览器做跟fiddler一样的事。
第三步， 客户端浏览器生成https通信用的对称密钥， 用fiddler伪造的证书公钥加密后传递给服务器， 被fiddler截获。
第四步， fiddler将截获的密文用自己伪造证书的私钥解开， 获得https通信用的对称密钥。
第五步， fiddler将对称密钥用服务器证书公钥加密传递给服务器， 服务器用私钥解开后建立信任， 握手完成， 用对称密钥加密消息， 开始通信。
第六步， fiddler接收到服务器发送的密文， 用对称密钥解开， 获得服务器发送的明文。再次加密， 发送给客户端浏览器。
第七步， 客户端向服务器发送消息， 用对称密钥加密， 被fidller截获后， 解密获得明文。由于fiddler一直拥有通信用对称密钥， 所以在整个https通信过程中信息对其透明。
踩过的坑
手机和Fiddler都正常安装SSL证书，依旧显示”Tunnel to……443”
- 手机未绑定Fiddler证书（IOS为例） 设置->通用->描述文件与设备管理，查看证书是否存在，如图：
- 证书未认证 设置->通用->关于->证书信任设置，查看证书是否认证，如图：
- 证书过期 检查手机系统当前时间是否正确，由于测试机为公用，并且某些特殊需求需要调整系统时间，所以建议检查系统时间，如图：
- 服务器支持 访问测试服务器查看nginx.conf配置，如图：
- Windows根证书无效 Fiddler开启HTTPS证书设置后，Windows根证书不信任，如图：
