HTTPS
文章目录
- HTTPS
-
-
- 加密
- 对称加密
- 非对称加密
- 中间人攻击
- 引入证书
- HTTPS传输过程
-
HTTPS
HTTPS是要比HTTP更安全
HTTP是一个明文传输的协议，本来传的试是啥，实际传的就是啥。
一旦传输过程中，数据被第三方获取到了，可能就会造成一些重要信息的泄露
HTTPS就是在HTTP的基础之上，引入了一个加密层(SSL/TLS),简单来说HTTPS就是由HTTP和SSL组成的
明文：真正要传输的消息
密文：指的就是加密之后的消息
明文 => 密文 称为 “加密”
密文 => 明文 称为 “解密”
密钥就是解密用的
加密
加密的过程中，又分成两种加密方式
对称加密
加密：明文 => 密文 使用一个密钥
解密：密文 => 明文 使用同一个密钥
非对称加密
加密：明文 => 密文 使用密钥1
解密：密文 => 明文 使用密钥2
密钥1和秘钥2是不同的秘钥(虽然这俩秘钥不同，但是存在关联关系的，这两个秘钥是成对出现的)
可以使用密钥1加密，使用密钥2解密；也可以使用密钥2加密，使用密钥1解密
通常会把其中一个密钥给公开出去，别人就可以使用这个密钥来加密了。自己留下另外一个密钥，用来解密。
把公开出去的秘钥称为"公钥"，把自己保留的秘钥称为"私钥"。
这里的公钥和私钥，就可以想象成现实生活中的信箱
公钥就像信箱上的锁，私钥就像这把锁的钥匙。
对称加密
先使用对称加密的方式，针对HTTP中传输的数据加密
对称加密里最关键的就是这个密钥，客户端和服务器需要约定好密钥是啥
如果是客户端生成了密钥，就需要通过网络告知服务器，密钥是啥
密钥本身也在网络上文明传输，也容易被黑客获取，一旦被黑客获取到了了，后续的加密就失去了意义。
正确的手段，是针对这个对称密钥，进行加密
非对称加密
引入非对称加密，使用非对称加密来对对称密钥进行加密
一个网站，生成一对公钥和私钥，把公钥公开出去，自己保留私钥
客户端就先拿这个网站的公钥来对自己的 对称密钥 进行加密，然后传输密文给服务器，服务器拿私钥解密，也就得到了密钥的明文。
只要有了个密钥，后续就可以直击使用对称加密来进行传输
既然都有非对称加密了，为啥还非得用对称加密呢？
对称加密，成本是比较低(机器资源消耗少)，速度也是很快的
非对称加密，成本比对称加密高很多(机器资源消耗的多)，速度也慢
中间人攻击
通过非对称加密的手段，确实是可以更安全的进行数据传输，但是还有点问题，就是客户端是如何获取到公钥的？
如何保证客户端获取到的公钥是真实可靠的，而不是黑客伪造的？
任何人都可以生成一对 公钥和私钥，网站服务器能生成，黑客也一样能生成。
黑客就想到一招，狸猫换太子
如果黑客入侵了网路设备，在客户端向服务器获取公钥的时候，把自己生成的公钥和私钥进行了替换，那么此时客户端拿到的公钥就会是黑客伪造的公钥。
引入证书
为了解决中间人攻击的问题，就可以引入证书来反制黑客伪造公钥这个问题
客户端和服务器连接的时候，客户端不是简单的索要公钥了，而是直接索要一个"证书"，公钥就包含在这个证书里面
然后这个证书不是服务自己生成的，而是第三方机构颁发的
然后客户端拿到证书之后，就可以根据证书中提供的信息，去第三方机构进行认证，来校验证书是否合法。
证书如果合法，那么就可以信任其中的公钥。
服务器开发中在搭建服务器的时候要去第三方机构来进行认证，申请证书
证书也是可以伪造的，浏览器会对拿到的证书进行校验，如果校验不通过浏览器就会有错误提示，提示该网站证书非法，继续访问存在安全风险
浏览器上面还会有一个按钮"继续访问"，技术再怎么牛逼保证安全，也担不住用户犯蠢去点击。
HTTPS传输过程
- 客户端先从服务器获取到证书，证书中包含了公钥
- 客户端对证书进行校验
- 客户端生成了一个对称密钥，使用公钥对对称密钥进行加密，发送给服务器
- 服务器得到这个请求之后，使用私钥解密，得到对称密钥
- 客户端发出后续的请求，后续的请求都是使用这个对称密钥加密的
- 收到的数据也都是使用这个对称密钥解密的
这个过程其实描述的是 SSL/TLS 的握手过程
但凡使用了SSL/TLS 的协议/工具/组件，都是类似的握手过程
