HTTPS 加密
简单描述一下 HTTPS 加密
加密的种类
Hash 加密
哈希算法，是一种从任意文件中创造小的数字「指纹」的方法。
常见算法：
1、MD5（128 位）
2、SHA-1（160 位）
3、SHA-2（包括 SHA-224、SHA-256、SHA-384、SHA-512）特点：
1、正向快：根据原始可以快速计算哈希值
2、逆向难：基本不可能通过哈希值反推出原始数据
3、抗修改性：原始数据有一点改动，哈希值就会产生很大差别
4、强抗碰撞：找到两个相同哈希值的数据很难用途：
1、数据一致性验证
2、数字签名
3、安全访问认证
对称加密
对称加密，也叫私钥加密，指加密和解密使用相同密钥的加密算法。
常见算法：
1.DES
2.3DES
3.AES
4.TDEA
5.Blowfish
6.RC5
7.IDEA特点：
1、只有一个密钥
2、速度快
3、效率高用途：
大量数据的加密
非对称加密
公钥和私钥配对的加解密，公钥加密+私钥解密，或者，私钥加密+公钥解密。
常见算法：
1、RSA
2、ECC特点：
1、相比对称加密，安全性更强
2、加密速度慢用途：
1、少量数据的加密
对加密的应用
数字信封
- 发送端：
使用 对称密钥 加密 数据，得到 数据密文
使用 私钥 加密 对称密钥，得到 密钥密文
发送数据密文和密钥密文
- 接收端：
接收数据密文和密钥密文
使用 公钥 解密 密钥密文，得到 对称密钥
使用 对称密钥 解密 数据密文，得到 数据
数字签名
- 发送端：
对 签名明文 使用 哈希算法，得到 签名摘要
使用 私钥 加密 签名摘要，得到 签名摘要密文
发送签名明文和签名摘要密文
- 接收端：
接收到签名明文和签名摘要密文
对签名明文 使用 签名内的哈希算法，得到 签名摘要 1
使用 公钥 解密 签名摘要密文，得到 签名摘要 2
验证 签名摘要 1 与 签名摘要 2 是否一致
HTTPS
HTTPS 是对 HTTP 协议的扩展。
HTTPS 协议传输数据大致分为三部分
- TCP 协议 — 通信双方通过三次握手建立 TCP 连接
- TLS 协议 — 通信双方通过四次握手建立 TLS 连接
- HTTP 协议 — 客户端向服务端发送请求，服务端发回响应
TCP
TCP 三次握手
- 客户端向服务端发送带有 SYN 的数据段以及客户端开始发送数据段（Segment）的初始序列号 SEQ = 100
- 服务端收到数据段时，向客户端发送带有 SYN 和 ACK 的数据段
- 通过返回 ACK = 101 确认客户端数据段的初始序列号
- 通过发送 SEQ = 300 通知客户端，服务端开始发送数据段的初始序列号
3.客户端向服务端发送带有 ACK 的数据段，确认服务端的初始序列号，其中包含 ACK = 301
TLS
TLS 的作用是在可靠的 TCP 协议上构建安全的传输通道，其本身是不提供可靠性保障的，我们还是需要下层可靠的传输层协议。
- TLS 握手过程
客户端向服务端发送 Client Hello 消息，其中携带客户端支持的协议版本、加密算法、压缩算法以及客户端生成的随机数；
服务端收到客户端支持的协议版本、加密算法等信息后；
- 向客户端发送 Server Hello 消息，并携带选择特定的协议版本、加密方法、会话 ID 以及服务端生成的随机数；
- 向客户端发送 Certificate 消息，即服务端的证书链，其中包含证书支持的域名、发行方和有效期等信息；
- 向客户端发送 Server Key Exchange 消息，传递公钥以及签名等信息；
- 向客户端发送可选的消息 CertificateRequest，验证客户端的证书；
- 向客户端发送 Server Hello Done 消息，通知服务端已经发送了全部的相关信息；
客户端收到服务端的协议版本、加密方法、会话 ID 以及证书等信息后，验证服务端的证书；
- 向服务端发送 Client Key Exchange 消息，包含使用服务端公钥加密后的随机字符串，即预主密钥（Pre Master Secret）；
- 向服务端发送 Change Cipher Spec 消息，通知服务端后面的数据段会加密传输；
- 向服务端发送 Finished 消息，其中包含加密后的握手信息；
服务端收到 Change Cipher Spec 和 Finished 消息后；
- 向客户端发送 Change Cipher Spec 消息，通知客户端后面的数据段会加密传输；
- 向客户端发送 Finished 消息，验证客户端的 Finished 消息并完成 TLS 握手；
- 总结
TLS 的四次握手，目的是为了交换三个信息
加密通信协议
就是双方商量使用哪一种加密方式，假如两者支持的加密方式不匹配，则无法进行通信；
数字证书
该证书包含了公钥等信息，一般是由服务器发给客户端，接收方通过验证这个证书是不是由信赖的 CA 签发，或者与本地的证书相对比，来判断证书是否可信；
假如需要双向验证，则服务器和客户端都需要发送数字证书给对方验证；
三个随机数
这三个随机数构成了后续通信过程中用来对数据进行对称加密解密的“对话密钥”。
首先客户端先发第一个随机数 N1（明文）;
然后服务器回了第二个随机数 N2（明文），这个过程同时把之前提到的证书发给客户端；
第三个随机数 N3（Premaster secret），客户端用数字证书的公钥进行非对称加密，发给服务器；服务器用只有自己知道的私钥来解密，获取第三个随机数。
这样，服务端和客户端都有了三个随机数 N1+N2+N3，然后两端就使用这三个随机数来生成“对话密钥”，在此之后的通信都是使用这个“对话密钥”来进行对称加密解密。
在 TLS 握手的过程中，服务端的私钥只用来解密第三个随机数，从来没有在网络中传输过，只要私钥没有被泄露，那么数据就是安全的。
HTTP
在已经建立好 TCP 和 TLS 通道上传输数据是比较简单的事情，HTTP 协议可以直接利用下层建立的可靠的、安全的通道传输数据
