早上看了一篇文HTTPS就安全了吗？会被抓包吗？看完这篇你有对答如流，本文是基于此文的总结。
先默读这张图5分钟：
浏览器证书验证过程
关于这个问题知乎有个自称专业认识的回答浏览器如何验证HTTPS证书的合法性？，咱也不是专业认识，就做个简单的总结：
- 权威机构的证书才会被浏览器认可，这是业界规范。权威机构颁发的证书结合浏览器接收到的服务端发送来的公钥即可验证服务端https证书的合法性。
- 浏览器会被强制安装权威机构的根证书。当然，更复杂的是还存在证书链，如根域名证书的子域名证书。
- 浏览器会从本地CRL(证书吊销列表)或者访问OCSP(在线证书检查)实时获取证书的有效期或者吊销状态。
- 浏览器针对不合法的证书作出提示。
随机数生成
随机数由客户端生成，用来作为对称加密的秘钥。
随机数的传输，采用的是非对称加密算法。
客户端：服务端公钥+随机数+加密算法 = 加密后的随机数
服务端：加密后的随机数+服务端私钥+ 解密算法 = 随机数
传输过程，只有服务端公钥是公开的，随机数只有客户端知道，服务端也只能通过私钥获得随机数。中间劫持者即使知道加解密算法，也无法解密出随机数。即可以保证之后的传输内容是无法被解密出明文的。
加密传输
采用随机数加密传输内容是为了提高通信效率。
非对称加解密算法复杂，执行耗时长，不利于双方通信。所以，https的核心是如何生成一个只有通信双方知道的秘钥。原来这一堆证书其实都是为这个随机数存在的。
那么问题来了，https建立在http的基础上，断开后再次连接随机数是否会重新生成呢？
多次尝试发现，针对https资源请求，每次重新建立tcp连接时，Initial connection和SSL总是同时存在的，如下图：
所以，tcp握手连接和SSL过程是一连串的动作，每次tcp连接建立过程会重新生成随机数。
下图是完整的https握手过程：
fiddler如何对https连接抓包
https的作用是避免传输过程被未知的第三方劫持以及篡改数据。浏览器只认权威的证书，造假的证书是不会被浏览器信任的，所以理想情况下可以避免中间人篡改传输内容：
但是，如果中间人是客户端使用者已知的且手动信任的第三方呢？fiddler就是这样的存在。当你想对https请求代理的时候，它会生成一个证书，名为DO_NOT_TRUST_FifflerRoot，让你下载安装它，并标记为可信任。
浏览器告诉你：“这个家伙给了我一个野鸡证书，不靠谱，我劝你小心点”
你： “哦哦，你说的是fiddler啊，它我很熟的，你放心好了”
然后浏览器就不吭声了，心里mmp： “你爱咋咋地，反正我已经提醒过你了”。
fiddler基于被客户端使用者信任的能力，可以拦截并自定义任何请求任何返回内容。如线上代码调试，fiddler可以在代码返回之前在特定位置插入调试代码，或者直接返回包含调试代码的本地代码。
fiddler作为一个超级工具，你还知道它的其它妙用吗？
参考资料
- https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
本文使用 mdnice 排版
