Java Web 实战 20 - HTTP PK HTTPS ? HTTPS 大获全胜 ?

最新推荐文章于 2024-11-10 18:11:02 发布

加勒比海涛

最新推荐文章于 2024-11-10 18:11:02 发布

阅读量305

点赞数 8

分类专栏： JavaWeb 实战文章标签： http java 前端

本文链接：https://blog.csdn.net/m0_53117341/article/details/134492413

版权

JavaWeb 实战专栏收录该内容

23 篇文章 1 订阅

订阅专栏

HTTP VS HTTPS

一 . HTTPS

Hello , 大家好 , 好久没有更新 JavaWeb 模块的内容了 .
博主这篇文章主要给大家讲解一下 HTTPS 以及与 HTTP 的区别
那接下来的知识点无疑都是面试重灾区 , 举几个常见例子
HTTP / HTTPS : HTTPS 加密的过程
Servlet : Cookie 和 Session 的区别
Linux : 常见的 Linux 指令
JVM : JVM 内存区域划分、垃圾回收机制、双亲委派模型
那希望大家跟紧步伐 , 站稳脚跟 !

大家也可以订阅 JavaWeb 专栏 , 点击即可跳转
准备好 , 我们要开始发车了 !

一 . HTTPS

HTTPS 和 HTTP 相比 , 只是多了一个 “加密层”
HTTP 传输数据都是明文传输的 , 很容易被别人获取或篡改

1.1 臭名昭著的运营商劫持

这种不属于该页面的弹窗广告 , 就是运营商劫持

或者像这样 , 要下载天天动听 , 结果自动下载了 QQ 浏览器 , 也是运营商劫持

这种运营商劫持在以前是非常猖狂的
由于我们通过网络传输的任何的数据包都会经过运营商的网络设备 (路由器 , 交换机等) , 那么运营商的网络设备就可以解析出你传输的数据内容 , 然后进行篡改.
正常情况下点击 “下载按钮” , 其实就是在给服务器发送了一个 HTTP 请求 , 获取到的 HTTP 响应其实就包含了该 APP 的下载链接 . 运营商劫持之后 , 就发现这个请求是要下载天天动听 , 那么就自动的把交给用户的响应给篡改成 “QQ浏览器” 的下载地址了 .

互联网上其实是非常不安全的 , 你觉得你没遇到过这些事 , 但其实你可能已经中招了

你的电脑这边没啥值钱的东西 , 没人盯着你
你的电脑其实已经中招 , 你不知道
你的电脑的杀毒软件 / 防火墙把你保护的很好

之后买了云服务器之后 , 感受就更加明显了

那既然运营商能够进行劫持 , 黑客也肯定能进行劫持咱们的数据
比如 , 黑客黑入了某个路由器 , 这个时候就可能获取到所有经过路由器的网络数据报

运营商路由器可能会受到攻击
公共场合的 wifi 也是活靶子

此时如果你继续在网络上按照明文传输信息 , 你的账号密码就要被窃取了
如何保证数据不被窃取呢 ?
无法阻止黑客入侵路由器 , 但是可以想办法对数据进行加密 , 即使被窃取 , 他也不知道是啥意思

1.2 加密是什么 ?

例子来源于这篇文章 : https://mp.weixin.qq.com/s/OkDstEG5Fu9QhNU65tgBeQ

小学上课的时候，都传过小纸条吧？传纸条的时候每个拿到纸条的同学都会忍不住看一眼，毫无隐私可言。
假设班花想对我表白，又不想在传的过程中让别人发现她的情意绵绵。
就会在课间十分钟里告诉我，“每个字母向左移动一位，就是我想对你说的话”。
然后在上课的时候，递出纸条，上面写了 eb tib cj。每个帮助传递纸条的同学看了之后，都暗骂“谜语人，你给我滚出哥谭镇”。
嘿嘿，你们不懂，我懂。
我拿到纸条后，将每个字母向左移动一位，得到 da sha bi。
什么话，这是什么话。
坏女人想要毁我向道之心？我果断拒绝了她的表白。

现在回忆起来，感动之余，会发现，像这种，将一段大家看得懂的信息（明文）转换为另一段大家看不懂的信息（密文），其实就是加密。
像这种“左移”的加密方法，其实就是所谓的秘钥(密钥)。
而这种加密和解密用的都是同一个秘钥的加密形式，就叫对称加密。

对称加密
那既然有对称加密，那就有非对称加密。
不同点在于，非对称加密，加密和解密用到的不是同一个秘钥，而是两个不一样的秘钥，分别是公钥和私钥。

非对称加密

密钥是用来 “加密” 和 “解密” 的关键数据
明文通过密钥变成密文这个过程就是"加密" , 密文通过密钥变成明文这个过程就是"解密"
如果加密和解密过程中 , 使用的密钥是同一个就叫做 : “对称加密”
如果加密和解密过程中 , 使用的是不同的密钥 , 就叫做 : “非对称加密”

1.3 HTTPS 的加密过程

对称加密

加密中最典型的办法 , 就是对称加密
加密和解密使用的是同一个密钥

非对称加密

如果加密和解密过程中 , 使用的是不同的密钥 , 就叫做 : “非对称加密”
非对称加密用来加密解密的密钥是一对有关联的整数 (通过数学上面的一些方法来生成的)

拿两个很大的素数 , 很容易得到乘积 , 但是知道乘积 , 没法还原回这两个素数

把这一对密钥 , 其中一个公布出来(公钥) , 另一个自己藏着(私钥)
就可以使用公钥来加密 , 私钥来解密
或者也可以私钥来加密 , 公钥来解密

可以这样理解 : 小区楼下有邮箱
每一户有自己的邮箱 , 有一个钥匙
邮递员手里有一把小锁头 (邮递员有很多个 , 这样的锁头也有很多 , 但是钥匙都是同一把)
邮递员可以通过这个锁 , 把你的信锁进去 [使用公钥加密]
你就可以拿着钥匙来开锁获取到信了 [使用私钥解密]

既然非对称加密这么香 , 为啥还要用对称加密呢 ?
非对称加密的加密和解密的开销 , 都是非常大的 , 就不如对称加密轻量
为了让安全和效率同时都具备 , 那我们就二者结合使用

但是上述的过程并非是无懈可击 , 黑客仍然有办法解决这个问题 , 叫做 : 中间人攻击

引入 “证书” 机制

先给大家讲解一下 , 什么是 “中间人攻击”
举个栗子 : 我们看电视剧经常会看到黑帮大佬们进行交易
易烊千玺和王源要进行交易 , 但是他们两个彼此都不认识 , 这时候王俊凯就可以浑水摸鱼
跟易烊千玺进行交易的时候 , 王俊凯假装是王源进行交易
跟王源进行交易的时候 , 王俊凯就假装自己是易烊千玺
这样 , 王俊凯就是一个中间人的操作 , 将易烊千玺和王源一网打尽
无标题.png
那如何解决中间人攻击的问题呢 ?
我们就需要让客户端有能力鉴别传过来的公钥到底是不是服务器传过来的公钥 , 有没有被动过手脚
HTTPS 就引入了一个证书机制

那 Fiddler 是如何实现抓包 HTTPS 呢?
Fiddler 其实就是在进行中间人攻击
首次勾选 Fiddler 的 Https , 提示是否要安装一个 xxxx 证书
这个是 Fiddler 为了实现中间人攻击 , 自己生成的证书
得安装了这个证书 , 浏览器才会信任 Fiddler , 浏览器才不会弹框