HTTP 的缺陷 ： 不安全
- 通信使用明文，内容可能会被窃听
- 不验证通信方的身份，因此有可能遭遇伪装
- 无法证明报文的完整性，所以有可能被人篡改
加密的方式
-
通信加密：建立安全的通信线路 。虽然HTTP 没有加密机制，但是可以通过 SSL（安全套接层） 、TLS（安全传输协议) 的包装，然后再去与TCP通信
-
内容加密：对内容本身加密。把 HTTP 报文中所含的内容进行加密
由于 http 协议无法证明通信的报文完整性，所以如果有攻击者篡改数据也毫无防备。
如何防止篡改
虽然 可以使用 HTTP 协议确定报文的完整性，比如 MD5/SHA-1通过散列值校验的方法，但是这些方法并不是 100% 可靠，所以就引出了 HTTPS = HTTP + 加密 + 认证 + 完整性保护
加密技术
-
使用两把密钥的公开密钥加密：一共两把密钥，一把用来加密（公开），一把用来解密（私有），公开密钥可以在网络上流传，但是私有密钥只能不能让任何人知道，公开密钥和私有密钥必须是一对才可以解开。这样做的理由是 ： 即使攻击者拿到了公开密钥也无法解密。
-
HTTPS 采用混合加密机制：就是共享密钥 和 公开密钥结合使用，首先使用公开密钥加密方式安全交换 待会在共享密钥方式所使用的密钥，然后再确保交换的密钥是安全的前提下 使用共享密钥的方式进行通信，因为 共享密钥的效率高，但是安全性不高，公开密钥的安全性高，但是效率低，所以先让通信变的安全，然后在让通信变的高效。
现在还有一个问题就是：万一公开密钥在传输的过程中被劫持、替换掉，这个应该怎么确认呢？
这个时候 数字证书认证机构 就大显身手了，由它出面来对密钥进行颁发证书，这样客户端就几乎可以确认这个密钥是不是真实的。整个的操作流程是：
- 服务器把自己的公开密钥登录到数字证书认证机构，目的就是提出公开密钥的申请。
- 机构用自己的私有密钥向服务器的公开密钥部署数字签名，并颁发公钥证书，将公开密钥放入了公钥证书后绑定在一起，
- 服务器将这个公钥证书发送给客户端（多数浏览器在内部已经植入了公开密钥，不需要服务器发送，因为还可能被劫持）此时的公钥是经过威严的第三方确认的，想造假几乎很难。
- 当客户端接收到证书后，使用公开密钥对证书上的数字签名进行验证，一旦验证通过就证明了 服务器的公开密钥是真实的。使用该密钥对报文进行加密处理再发送。
HTTPS 的安全通信机制的流程
第一次SSL握手
- 客户端发送 Client Hello 报文 开始 SSL 通信，报文中包含着 客户端支持的 SSL 指定版本、加密组件、列表（所使用的的加密算法、密钥长度）
- 服务器 以 Server Hello 报文作为响应，报文中包含着 SSL 版本以及加密组件，这些加密组件是通过客户端发送过来的组件删选的，为的就是找到 既满足服务器又满足客户端的 SSL版本。
- 服务器发送 Certificate（证书） 报文，里面包含着 公开密钥的证书。
- 紧接着 服务器发送 Server Hello Done 报文通知客户端最初的 SSL 握手协商部分结束。
第一次握手结束
- 客户端以 Client Key Exchange 报文作为回应，报文中包含着 通信加密中使用的 随机密码串。(此时这条已经在使用公开密钥 进行加密了）
- 接着客户端继续发生 报文，报文提示服务器在此报文之后的通信使用Pre - master secret 密钥加密
- 客户端再次发生 Finished 报文，里面包含着 连接至今全部报文的整体校验值，如果服务器正确加密了该报文，则表示这次握手协议成功
- 服务器发送 Change Cliher Sper 报文
- 服务器发送 Finished 报文
- 当服务器和客户端的Finished 报文交换完毕后，SSL 连接建立完成，通信会受到SSL的保护。
从此处开始，进行应用层协议使用 HTTP 请求
…
最后由客户端断开连接，发送close_notify 报文。
然后再发送 TCP 中的 FIN 报文来关闭TCP的通信
SSL 的缺点
虽然安全，但是他的通信效率会 HTTP 的慢 2 -100 倍，在建立SSL通信的过程中消耗网络资源与内存资源，占用大量的CPU 。
来源：https://blog.csdn.net/qq_43763344/article/details/98677491