HTTPS前瞻
网络传输的安全性
由于 HTTP 天生“明文”的特点，整个传输过程完全透明，任何人都能够在链路中截获、修改或者伪造请求 / 响应报文，数据不具有可信性。
黑客，代理可在数据传输的任意节点对数据进行拦截，因为HTTP是明文传输，只要拦截成功，就可以修改请求或者响应报文
对称加密与非对称加密
- HTTP协议：不安全，未加密
- HTTPS协议：安全，对请求报文和响应报文做加密
加密的方式有对称加密和非对称加密。
对称加密
顾名思义：加密和解密使用同一把密钥
- 特点：
- 加密使用相同密钥
- 高效，适用于大量数据加密的场景
- 算法公开，安全性取决于密钥大小，但是密钥越大效率越低，需要在安全以及效率角度做权衡
- 缺点：
- 算法本身安全，但是应用场景不安全，因为加密和解密使用的是同一个密钥
如果使用对称加密算法，浏览器在第一次请求的时候，就需要携带密钥，将密钥告知服务端，此过程，黑客仍然科技截胡，获得密钥。
在之后的请求与响应中，黑客已经获得了密钥，同时也可以获得密文，加密多此一举，黑客仍然可以解密。
非对称加密
使用匹配的一对密钥来分别进行加密和解密，这两个秘钥是公开密钥(public key，简称公钥)和私有密钥(private key，简称私钥)
算法:RSA、ECC、Elgamal、背包算法、Rabin、D-H等
- 特点:
- 安全性高
- 公钥加密的数据只能用对应的私钥解密，同理，私钥加密的数据只能用对应的公钥解密
- 缺点:加解密复杂，效率低，耗时较长，不适用于大量数据加密的场景
- 用法概要:
- 加密:对数据做加密。
- 签名:证明数据是谁发的
非对称加密的使用
首先需要生成一对匹配的公钥和私钥（公钥只能由私钥生成，私钥不公开）
公开公钥
当然，黑客也可以拿到公钥，但是公钥的用途是进新加密，无法进行解密。
公钥加密
场景：用来对数据进行加密传输
注意：
- 因为公钥加密数据只有对应的私钥才能解密，所以密文很安全
- 如果在网络上互相发送密文，可以让对方也发送其自身的公钥，用对方的公钥来加密。
私钥签名
完成身份认证。
场景：将公钥公布后，同时需要证明公钥是自己发的
第一步：服务端用自身的私钥对明文的hash值进行加密，把密文（签名）和明文一起发送给客户端
第二步：客户端用服务端的公钥进行解密，解密后的明文hash值（使用和服务端同样的哈希算法，计算明文的hash会得到同样的结果）和接收到的明文的hash值进行对比，如果一样则是服务端发的
HTTPS协议
如果服务端生成的公钥通过响应报文传递，结果是这样的：
如何解决？
牵扯到认证方式的问题。
认证机构
就毕业就业问题来举例：
当我们入职时，入职hr会查看我们的学历是否造假，这就需要一个权威的平台来对我们自身的身份进行认证，这个权威的平台就是学信网。
在HTTPS中，这个权威平台叫做认证机构（根节点）（全球所有企业都认为其是有权威的）
- 认证机构在全球只有几家，单由这几家公司是管理不过来的，所以其下会有一级二级的节点，这些节点都通过这些认证机构认证过（可以理解为代理商）
浏览器为了确认数据时服务端发送的， 会去认证机构去确认，具体的确认过程见下。
具体文字描述：
前提条件：服务端的公钥A和私钥A，认证机构的公钥B和私钥B，客户端会话密钥
- 公司将服务器的域名，服务器公钥A，认证时长等信息提交给认证机构
- 认证机构使用私钥B将服务端提交的信息加密，生成证书
- 认证机构将公钥B交给客户端
- 客户端发送预请求，向服务端请求证书
- 服务端发送证书
- 客户端利用公钥B将证书解密，拿到服务端域名、服务端公钥A等信息
- 客户端使用公钥A，对会话密钥进行加密
- 客户端将加密后的会话密钥发送给服务端
- 服务端利用私钥A对加密的会话密钥进行解密，拿到会话密钥
- 服务端告知客户端收到会话密钥
- 双方使用会话密钥进行对称加密的数据请求与响应