网络通信，有3点是必须要保护的：
- 通信内容必须保密，不能被第三方看到
- 通信内容必须完整，不能被第三方篡改
- 通信双方身份必须确认，不能被第三方“截胡”
怎么才能做到以上3点了？
1、通信内容必须保密，不能被第三方看到
这个简单，加密呗！有对称加密和非对称加密。对称加密消耗的算力远比非对称加密小，所以这里首选对称加密；目前业界最流行的对称加密是AES，这里不妨选择AES试试；
那么问题又来了：对通信数据加密的初衷是因为通信链路不安全，传输的数据随时可能被窃取和篡改，此时如果直接通过不安全的公网传输对称密钥，被中间人截取、篡改了怎么办?
2、密钥交换（这种交换的思路和算法很重要，后续我们分析xxxx的mmtls协议时无时无刻无不用到这种思路，请一定要牢记并理解！）
第1点已经阐明了通信时加密密钥直接传输的风险了，怎么才能让对方知道对称加密的密钥了？--Diffie-Hellman算法！算法过程如下：
（1）甲随机选一个素数，比如p=509，随机选一个底数g=5，随机生成一个数a=123，计算A；然后把p、g、A发给乙；
（2）乙接收到p、g、A后，随机生成b=456，计算B和s，然后把B发给甲
（3）甲收到B后计算出s，发现和乙自己计算的s一模一样，后续双方就用s作为对称加密的密钥！
（4）纵观整个过程：s并未在网络上传输，只要自己保密工作做好，不要泄露了s，双方后续在网络上传输密文就是安全的！
不难发现，Diffie-Hellman算法的本质：双方各自生成自己的密钥对（甲的是A和a，乙的是B和b），把公钥发给对方，私钥自己留着，然后根据对方的公钥和自己的私钥生成对称加密的密钥！
Diffie-Hellman算法很好地解决了密钥“交换”的问题；至此，甲乙双方互相通信的所有的问题都解决了？
3、显然还没有！仔细回顾Diffie-Hellman算法，确实解决了双方互相“交换”对称密钥的问题，但还有一个严重的问题没解决：身份鉴权和认证！上述整个流程中，甲是无法确认和他通信的一定就是乙的，万一是丙了？ 再说直白一点：我们平时用浏览器上网，输入baidu的时候，怎么确认访问的就是百度，而不是白度了？
不难看出，Diffie-Hellman算法没法确认对方身份的根本原因是没法确认对方发过来的公钥是不是第三方的！比如甲乙通信，丙在中间截取了甲发送的P、g、A，换成自己的，乙是不知道的，还是会继续按照协议接受这些数据，并且生成B再发给丙，丙在中间就能窃听甲乙之间的通信了！怎么确保乙接收到的公钥就是甲发过来的了？--- 数字证书
双方无法解决的问题，就需要第三方强势介入了！于时诞生了世界上最权威的机构--认证中心！
- 网站先找到认证中心，把自己的公钥和其他信息打包做成证书提交给认证中心。认证中心用他们自己私钥加密网站的证书，然后把证书发给网站（这里一定要把认证中心的密钥对、网站证书的密钥对、对称加密的密钥分开，三种密钥的作用是不一样的）；
- 网站把证书发给client；
- 由于client的操作系统、浏览器出厂的时候内置了认证中心的公钥，client只要知道是哪家认证中心认证的证书，就用该中心的公钥解密证书，拿到网站的公钥；此时就确保了client拿到的公钥确实是网站的，而不是第三方伪造的！
- 自己随机生成对称加密的密钥，然后用网站的公钥加密，随后发个网站；
- 网站用自己的私钥解密后，得到对称加密的密钥，随后用该密钥加密application data！
以上便是https核心通信过程！通过第三方认证的证书鉴别身份；通过对称加密确保双方通信的application不被第三方查看和篡改！
4、上面讲了很多理论知识，现在用wireshark抓包实战，看看client和server之间是怎么互相发密钥和建立连接的！
用浏览器访问百度，wireshark抓包后用ip地址过滤一遍，握手流程如下：
（1）客户端主动给服务端打招呼，把自己生成的随机数、session id、cyphersuit发给服务端：
（2）服务器响应，也生成一个随机数、自己能接受的加密算法都发给客户端
（3）为了验明正身，服务器把自己的证书发给客户端，客户端用认证中心的公钥解密，然后对比细节信息，看看是不是吻合的；
（4）如果验证通过，客户端就用服务端证书的公钥加密后续用于对称加密的密钥，发给服务端；只有服务端自己的私钥能解开看到这个对称加密的密钥；看看，是不是用的刚才说的DH算法呀？这里多说一句：用服务器公钥加密的对称密钥这里是看不到的（或则说加密了，看不到明文的）！
（5）服务端开始用对称加密的密钥给服务端发数据了
其实https、数字证书、TLS这些已经非常成熟了，网上各种资料到处都是，为啥还要花篇幅介绍了？ 前面介绍了xxxx这种国民级软件的逆向分析流程，但是还没抓到聊天的数据包。从xxxx公开的资料看，其用了自研的通信协议，这个协议基于TLS 1.3改进的，用wireshark抓包后截图如下：
- 既然是基于tls 1.3改的，wireshark自然没法识别，只能识别到tcp
- 比较好奇：xxxx的服务器还是80端口，这是为了和网页版的xxxx保持一致么？
- 偶尔能看到http协议给sz的xxxx服务器发数据，当然数据本身也是加密的。这里客户端的名字是MicroMessager Client；既然用http协议，应该是短连接，用完就释放，避免占用资源
- 剩下的全是这种无法识别的tcp包，所有数据加密后都放在tcp的payload了，wireshark根本无法识别
后续会深入分析xxxx的通信协议，争取通过代码复现！
参考：
https://juejin.cn/post/6844903958863937550 超详细https握手与数字签名讲解
https://www.jianshu.com/p/a3a25c6627ee Https详解+wireshark抓包演示