💖 欢迎来阅读子豪的博客（JavaEE篇 🤴）
👉 有宝贵的意见或建议可以在留言区留言
💻 欢迎 素质三连 点赞 关注 收藏
🧑‍🚀码云仓库：补集王子的代码仓库

不要偷走我小火车哦~ ~ ~

HTTPS 是什么

HTTPS也是应用层协议, 在HTTP基础带上加了一个安全层
HTTPS -> HTTP + SSL(加密协议)
HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现一些被篡改的情况(运营商劫持, 流量劫持)

由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器, 交换机等), 那么运营商的网络设备就可以解析出传输的数据内容, 并进行篡改.
比如现在我们想下载软件"A"点击 “下载按钮”, 就是在给服务器发送了一个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该 APP 的下载链接. 但是当运营商劫持之后进行数据篡改, 就发现这个请求是要下载的是"A", 结果下载的是"B"

网络上如果明文传输数据,是是非常危险的!!所以就需要对数据加密
HTTPS 就是在 HTTP 的基础上进行了加密, 进一步的来保证用户的信息安全

SSL 对称加密

HTTPS其实主要是涉及到其中的SSL部分 (SSL并非仅仅是在 HTTPS中使用)
进行安全传输,核心就是加密(数学转换), 加密其中一种最简单有效的办法,叫做“对称加密"(同一个密钥既能加密也能解密)


如果像上述方式进行数据传输的话, 由客户端生成密钥, 发给服务器, 此时由于密钥刚刚生成, 服务器还不知道,此处的密钥只能明文传输, 在传输过程中密钥可能就被黑客给截获了, 黑客就做了"中间人", 此时加密就形同虚设了

这种传输虽然成本低, 效率高, 但是安全系数低

SSL 非对称加密

非对称加密要用到两个密钥, 一个叫做 “公钥”, 一个叫做 “私钥”.
公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多.

• 通过公钥对明文加密, 变成密文
• 通过私钥对密文解密, 变成明文

公钥是公开的, 大家都可以用, 但是私钥是事先约定好了的, 只有传输双方有,

客户端使用公钥来对对称密钥进行加密，传输给服务器, 服务器就可以拿事先约定好的私钥来解密得到对称密钥.
此时客户端服务器就可以使用这个对称密钥进行后续传输了(因为对称加密传输速度更快)

重点: 非对称加密只是为了传输对称密钥

中间人攻击

上述的非对称加密看似严密, 但是黑客们想出了, 模仿服务器发送自己的公钥给客户端, 中间人在两遍各自扮演不同的角色, 两遍忽悠!

比如现在想访问百度, 中间人为搜狗:
查询百度服务器请求时可能被中间人搜狗拦截，搜狗就伪造了百度的公钥，换成中间人搜狗的公钥, 同时中间人搜狗也持有搜狗自己的私钥和公钥, 此时再把自己的公钥发给客户端, 客户端再以搜狗的公钥加密key(以后传输信息所需的对称私钥)并发出, 此时中间人搜狗根据自己的公钥解密得出对称密钥key, 之后中间人继续使用服务器的公钥对key重新加密并发给百度服务器, 伪装成客户端给百度服务器发送信息

重点 : 中间人搜狗发送自己的公钥给服务器

证书加密

上述中间人攻击使得我们不得不思考如下两个问题

• 客户端如何获取到服务器公钥?
• 客户端如何确定这个公钥不是黑客伪造的?

解决中间人攻击的关键，在于让客户端能够辨别, 当前这个响应(公钥)是目的服务器真实的公钥

引入一个"证书"就解决了上述漏洞(本质上是引入第三方的公证机构)

服务器(网站)在设立之初, 需要去专门的认证机构, 申请证书(提供一些资质的)审核通过, 就会颁发证书, 服务器生成的公钥就包含在这个证书中
客户端像服务器请求公钥的时候, 此时不是请求单单一个公钥,而是请求整个证书, 客户端拿到证书之后, 可以对证书签名进行校验(验证一下证书的真伪, 有误被篡改)如果发现证书是无效,浏览器就会直接弹框告警!

客户端可以使用认证机构提供的公钥进行解密, 解密之后, 得到"结果1"(类似TCP校验和一个hash值), 再根据证书的其他字段进行同样的校验计算得到"结果2", 再把"结果1"(签名解出来的)和"结果2"(客户端自己解的)对比, 值相同则证明证书有效, 未被篡改

黑客只能拿到公钥操作,哈希值可以解出来,但是不能包装成证书,只有机构可以用私钥包装
认证机构,拥有一组公钥私钥私钥, 用来加密hash值得到签名, 而公钥是客户端拥有, 使用公钥解密签名获取hash值