Java HTTP(3)

HTTPS的工作过程
明文+密钥=>密文
密文+密钥=>明文

有的场景 加密和解密 使用的是相同的密钥 “对称加密”
有的场景 加密和解密 使用的是不同的密钥 “非对称加密”

生成一对密钥 公钥和私钥
可以使用公钥加密 私钥加密
也可以使用私钥加密 公钥解密

最简单的保证安全的做法,引入对称密钥,针对传输的数据(HTTP的header和body)进行加密

如果黑客入侵了路由器截获了请求内容
黑客截获到的数据 是加密后的数据 黑客手里没有对称密钥 无法进行解密

每个客户端 都需要有一把自己的对称密钥(不同客户端的密钥的不同)如果客户端生了密钥 就需要把密钥传给服务器

如果在传输密钥的过程中被黑客截获密钥 后续使用这个密钥加密传输 数据还是能被黑客解密的

所以此时我们还需要想办法 把密钥安全的传输到对面 需要对于这个密钥进行加密 此时如果继续使用对称加密 (针对刚才密钥进行加密) 无论进行几层都是不安全的

此时就需要进行非对称加密

客户端使用公钥加密 服务器生成一堆公钥和私钥 私钥服务器自己留着 公钥发送给客户端(这里的私钥是绝不会轻易泄露的) 所以黑客在传输过程中能拿到公钥 但是没有私钥 使用公钥加密 就必须使用私钥解密 所以就算黑客能拿到公钥 也无法进行解密

此处使用非对称加密只是用来针对密钥加密 而不会加密http header body 后续加密使用对称密钥的 (非对称密钥 运输量很大 效率低)

中间人攻击问题

针对上述的过程 还存在一个严重的问题 中间人攻击 黑客可以使用中间人攻击的方式 仍然获得对称密钥

解决中间人攻击问题的关键 需要让用户能够确认当前收到的公钥 确实是服务器返回的 而不是黑客伪造的
所以 引入了证书机制 需要有一个第三方 认证机构 通过第三方机构保证 来确认当前公钥是有效的

当前HTTPS也是一样需要第三方机构对当前公钥进行认证

任何服务器 需要申请一个证书 资质审核通过就可以颁发证书了
大概流程

所以这里就阻止了黑客获取公钥 也无法从其他路径获取私钥

但是黑客也可以伪装自己成认证机构 骗用户安装自己的公钥 此时就可以光明正大的换掉数字签名了

所以网络安全 是道高一尺魔高一丈 无穷尽也