简单了解HTTP和HTTPS
HTTP的安全问题？
我们都知道HTTP是不安全的，而HTTPS是安全的，那HTTP有哪些安全问题呢？（考虑传输过程以及响应方）
- 明文传输，有窃听风险：HTTP协议无法加密数据，所有通信数据都在网络中明文传输，通过网络的嗅探设备及一些技术手段，就可轻易窃听并还原HTTP报文内容。
- 无法验证数据完整性，有篡改风险：HTTP协议无法证明通信的报文完整性，发送方发出的请求和接收方接收到的响应是前后相同的，没有被篡改的。
- 无法验证通信方身份，有冒充风险：在请求或响应到达接收方这段时间内，请求或响应被第三方拦截伪造之后再次发出，通信双方也无法知晓。
HTTPS如何解决的？
- 混合加密明文解决窃听风险
- 摘要算法为数据生成一个唯一的指纹，通过指纹验证报文完整性，解决篡改风险
- 将服务器公钥放入到数字证书中，并把证书注册到CA，解决了冒充风险。
混合加密
HTTPS采用了非对称加密和对称加密结合的方式：
- TLS握手期间采用非对称加密交换交换随机数生成会话密钥
- 此后的通信过程采用对称加密的会话密钥进行加密
为什么用混合加密？
对称加密虽然加密、解密的运算速度快，但是如果在HTTP明文传输密钥，那密钥可能会被窃取，也就相当于没有加密；
所以在对称加密之前，用非对称密钥加密随机数生成一个对称加密的会话密钥，保证这个会话密钥不会被窃取。【安全】
那为什么不直接用非对称密钥加密来进行通话的数据加密呢？
那是因为非对称密钥加密、解密的运算速度会比对称加密慢，对于数据通信我们自然不希望加密、解密的运算速度比传输的RRT还长。
非对称加密和对称加密的区别？
- 非对称加密：发送方用接收方的公钥加密，接收方用私钥解密；或者发送方用自己的私钥加密，接收方用自己的公钥解密
- 对称加密：双方用同一对密钥进行加密和解密
摘要算法
以下的指纹、hash值都是一个意思。
为了保证传输的内容不被篡改，我们需要对内容计算出一个「指纹」，这个哈希值是唯一的，且无法通过哈希值推导出内容。然后同内容一起传输给对方，接收方再次计算数据的hash值，和指纹比对，相同说明数据没有被篡改，但是不能说明内容和hash值没有一起被篡改（也就是消息来源是正确的吗？），这时候就要用到非对称加密：
- 公钥加密，私钥解密。这个目的是为了保证内容传输的安全，保证只有私钥拥有者才能获取到数据【用于服务端公钥加密发送Ramdom】
- 私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，保证消息来源是正确的【用于CA认证】
对指纹用私钥加密，然后客户端有对应的公钥，就可以解密，比对数据的hash值和指纹，相同则说明内容没有被篡改。
数字证书认证机构（CA）
万一公钥是被伪造的呢？这时候就需要有第三方的验证。
CA是第三方权威机构，服务端把「个人信息 + 公钥」打包成一个数字证书，放到CA，CA会用自己的私钥加密数字证书得到一个数字签名，客户端收到数字证书后先去CA验证是否合法（用CA的公钥解密，比对hash值），如果验证成功，就可以获取到服务端的公钥。
HTTPS建立连接流程
TLS握手在TCP三次握手之后，那RSA算法举例，主要分为以下几个步骤：
- 客户端发送请求，询问服务端用哪些密码套件和TLS版本
- 服务端ACK确认密码套件和TLS版本，同时会向客户端发送自己的数字证书（有服务端的公钥），客户端收到之后进行验证数字证书有效，从中获取到服务端公钥，用公钥加密一个随机数发送给服务端，服务端收到后用自己的私钥解密得到随机数，用这个随机数生成一个对称的会话密钥
- 客户端发送请求，请求之后的会话都用这个会话密钥，服务端响应ACK
- 服务端发送请求，请求之后的会话都用这个会话密钥，客户端响应ACK
- TLS握手完成，HTTPS建立连接完成
如何验证数字证书有效？
正如前面的摘要算法以及CA提到的，会对原文生成一个指纹，CA用私钥加密这个指纹得到数字签名，服务端同样对原文生成一个指纹，用CA公钥解密数字签名得到一个hash值，比对hash值和指纹，如果相同则说明验证成功。
CA的公钥不直接包含在服务器的数字证书中，而是通过一系列的中间证书和根证书来间接验证。根证书中的公钥预先内置在客户端的信任库中，而中间证书则由服务器在连接建立时发送，形成完整的证书链来验证服务器的真实性。
HTTPS真的安全吗？
当有第三方在客户端和服务端中间，第三方伪造服务端和客户端TLS握手，同时第三方伪造客户端和服务端TLS握手，不就会产生问题吗？
换个问题表述，可以理解为第三方冒充的问题，主要是数字证书的信任问题，当你点击一个有风险的连接，浏览器会弹出警告，这时候如果你点击拒绝访问，自然TLS握手失效，也就不会有后面的数据通信过程；或者是电脑中病毒了，被第三方恶意植入了它的证书，浏览器不会弹出风险警告，那么通信也不再安全。