前言
http协议属于明文传输协议，交互过程以及数据传输都没有进行加密，通信双方也没有进行任何认证，通信过程非常容易遭遇劫持、监听、篡改，严重情况下，会造成恶意的流量劫持等问题，甚至造成个人隐私泄露（比如银行卡卡号和密码泄露）等严重的安全问题。
就像坐在教室里，想传纸条给另一位同学，在建立TCP之后，便开始传纸条，这时候要面对第一个问题是，途径的每个同学都能知道纸条上的内容。第二个问题是，如果某个同学篡改了其中的内容也是正常。
这时候就需要一个加密方式来把内容加密 —— 对称加密（****https协议的第一部分内容****）
对称加密
对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。
常用的加密算法是 AES 算法
image.png
- 发送方利用密钥123456，加密明文“我是小灰”，加密结果为TNYRvx+SNjZwEK+ZXFEcDw==。
- AES支持三种长度的密钥：128位，192位，256位
- AES256安全性最高，AES128性能最好，本质是处理轮数不同[1]
- 加密速度快，适合经常发送数据的场合。缺点是密钥的传输比较麻烦。
此时，内容加密方式已经确定了，下一步就是如何把密钥共享，传递密钥 —— 非****对称加密（****https协议的第二部分内容****）
非对称加密
密钥传递，需要协商，如果这个过程被“中间人”“嗅探”到了，拿到了唯一密钥，那后面的加密内容传递 无异于明文传递。
所以这一协商过程必须发生在TLS握手阶段，对上面的密钥做非对称加密后再进行传输
这种加密指的是可以生成一对密钥 (公钥k1, 私钥k2)， 私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。常用 RSA[2]
image.png
公钥每个人都可以有，但是私钥只有服务器才有，所以似乎只需要此时将用公钥加密内容密钥，发送给服务端，服务端再用私钥解密即可。
但这样并不安全，有一种更恶劣的行为是专门针对上述方式的， 就是“中间人攻击”
image.png
<u>中间人攻击</u>
- 客户端发起https请求到达中间人，中间人请求服务端，服务端返回 服务端的公钥（服）
- 中间人 拿到 公钥（服）后， 生成自己的 公钥（中）和私钥（中），同时返回给客户端 公钥（中）
- 客户端 拿到 公钥（中）后，加密密钥 ，再发给中间人，
- 中间人用自己的 私钥（中）解密后，记住 密钥 明文，再用 公钥（服）加密后 发给 服务器
- 服务器 拿到 后解密，确认 内容密钥
为了解决此问题，从而引入了CA（数字证书）的概念
数字证书
数字证书就是通过数字签名实现的数字化的证书, 数字签名就是对非对称加密和摘要算法的一种应用
image.png
- 服务器首先生成公私钥，将公钥提供给相关机构（CA），CA将公钥放入数字证书并将数字证书颁布给服务器
- 此时服务器就不是简单的把公钥给客户端，而是给客户端一个数字证书（公钥(服)，数字签名，签名算法）。
- 数字证书中加入了一些数字签名的机制，保证了数字证书一定是服务器给客户端的。
- 如果中间人发送伪造的证书，不能够获得CA的认证， 客户端和服务器就知道通信被劫持了。
- 如果中间人不伪造证书，则因没有服务端的私钥，而无法解析客户端的信息
客户端如何验证证书
- CA证书验证维护在客户端浏览器和操作系统中
- 客户端拿到证书后根据数字证书上的方法自己生成一个数字签名，如果生成的数字签名与证书上的数字签名相同，那么说明这个证书是真实的。
CA参与的TLS过程
image.png
- 客户端给出协议版本号、一个客户端生成的随机数1（Client random），以及客户端支持的加密方法。
- 服务端确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数2（Server random）。
- 客户端确认数字证书有效，然后生成一个新的随机数3（Premaster secret），并使用数字证书中的公钥加密这个随机数3，发给服务端。
- 服务端使用自己的私钥，获取客户端发来的随机数3（即Premaster secret）。
- 客户端和服务端根据约定的加密方法（对称加密），使用前面的三个随机数（随机数123），生成"对话密钥"（session key），用来加密接下来的整个对话过程。
注意
- 生成对话密钥一共需要三个随机数。
- 握手之后的对话使用"对话密钥"加密（对称加密），服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），无其他作用。
- 服务器公钥放在服务器的数字证书之中。
SessionID恢复
session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。
网友评论