网络传输中安全流程的体现
加密算法的安全性主要分为两种，一种是保护信息不被泄露的能力（CPA安全），一种是保护信息不被篡改的能力（CCA安全）。
单纯的加密算法是不具备防止篡改的能力的。只有结合消息验证机制的加密算法才能防止篡改。比如AES-CBC with HMAC-SHA256、AES-GCM（主流选择）、ChaCha20-Poly1305等等。
HTTPS中对消息验证作了明确要求，所以本身是具有防篡改能力的。
传输层
Https(SSL/TLS) 保证了传输层请求的完整、不被篡改、加密
第一步：身份认证——CA的自签名数字证书
CA的自签名数字证书是CA的RSA公钥，RSA公钥是明文，预装在PC的操作系统里，所以任何人都可以得到CA的公钥，CA唯一拥有CA的RSA私钥。
当服务器S向客户端C出示数字证书，包括1） CA自签名证书（含有CA私钥签名的指纹）2） CA给S签名的证书 （也含有CA私钥签名的指纹）
由于C拥有CA的公钥，1）验证成功2）用CA的公钥，成功验证是CA私钥的签名，于是信任服务器S的公钥，因为证书2）里包含服务器的公钥
第二步：数据加密——Session Key
S与C协商用于加密数据的session key ，通过两种算法：DH算法和RSA算法
1）DH算法
S 筛选出自己的素数对 S1、S2
C筛选出自己的素数对 C1、C2
S与C交换各自的S2、C2
S拥有了S1、C2，DH可以算出一个master key
C拥有了C1、S2，DH可以算出一个master key
两个master key 完全一样！
2）RSA算法
C随机选取一个master key ，用S 的公钥加密，S解密，得到明文的master key，剩下过程和DH算法类似，不在重复！
FAQ
RSA双方已经共享了master key，为什么还需要DH算出另外一个key呢？如果CA有一天泄密，则千千万万的用户全泄密了，认证、加密相关联。DH则是独立算法，不会因为CA私钥泄密而被破解。
应用层
常说的SSL/TLS加密是传输层加密，如果SSL/TLS加密服务与HTTP服务器位于一台物理服务器上，那SSL/TLS可以提供客户端到服务器端的安全（End To End Security）。
Client ---HTTPS---（HTTP Server + SSL）
而现实情况却往往不是以上的部署方式，而是采用负载均衡（Load Balance）设备先终结客户端的SSL/TLS会话，负载均衡设备然后再与HTTP服务器之间采用明文传输(HTTP)，即使这一段传输位于内部安全域，它依然是一个安全隐患。
Client ---HTTPS---Load Balance ---HTTP---HTTP Server
为了保证端对端的绝对安全，我们需要在应用层增添安全保障，即保证用户数据不被篡改。
这里就用到了HMAC（Keyed Hash Message Authentication Code）
HMAC有三个输入参数：
用户数据
时间戳
Key
前两者会伴随HTTP到达服务器，这个key 却不会，如果一起传输，就没有任何意义了，第三方可以篡改用户数据，然后重新计算HMAC。
这个key 只有客户端（用户）与服务器端知晓，扮演这个key 角色最好人选就是账户密码，
客户端/服务器端分别将账户密码为输入参数，计算出Hash，这个Hash应该是一样的，然后就可以做为Key了。
由于Key只有客户端/服务器知晓，任何篡改数据的企图都会被发现，用户数据不被篡改，用户的交易就是安全的。
备注
SSL也有自己的HMAC，先用SSL会话双方协商到的Master Key，各自推导出同样的session key , hash key ，前者用于加密/解密，后者用于HMAC。
计算好的HMAC的附在data末尾，然后 data + HMAC 一起用session key 加密，传输出去。
对方做逆操作，先解密，后分离 data 与 HMAC，然后再校验数据真伪。
参考资料
HTTPS可以防止中间人篡改内容吗
使用了https后，还有必要对数据进行签名来确保数据没有被篡改吗