还记得上一篇咱们唠的 HTTP 不?这货虽然是互联网的 “交通基本法”,但属实是个 “心大的主儿”—— 数据都明晃晃地在网上跑,就像把钱包敞着口逛街。 你是不是也遇过这种糟心事儿:想下某个软件,结果下回来的是 “全家桶”;刷个网页,突然蹦出和你搜索内容八竿子打不着的广告?这都是 HTTP “明文传输” 给的机会 —— 你传的内容,像没锁门的快递箱,谁路过都能扒拉两下。 但这还只是 “小亏”:要是你传的是账号密码、支付信息,那可就是把钱包直接递到别人手里了。 所以今天这篇,咱们就来扒透 “HTTP 的保镖”——HTTPS 是怎么给数据 “上锁” 的:从 “对称加密为啥防不住黑客”,到 “非对称加密的坑在哪”,再到黑客最阴的 “中间人攻击” 是咋被 “证书” 按死的…… 保证把这些绕人的安全逻辑,讲成你能听懂的 “反套路手册”~
注意:本文充满了“但是”与反转,大家可以着重关注一下哦!
不知道大家小时候在电脑上下载软件的时候有没有过这种遭遇: 我想下载某一个软件,结果点击下载之后却是另一个软件。我这么一说大家可能想不起来,但是我举这个例子大家肯定深有感触:在手机浏览器上下载软件,大多数情况下都会给你下载一个应用宝的安装包,每次误下删除之后还有!也没办法,有时候就是想下载一些应用市场确实没有的东西,也只能去浏览器下载… 这就是臭名昭著的“ 运营商劫持”了,由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器, 交换机等), 那么运营商的网络设备就可以解析出你传输的数据内容, 并进行篡改。 其实就是因为我们的数据是明文传输 的,这种做法其实很危险,HTTPS就是在HTTP的基础上进行了加密,进一步保证了用户的信息安全~~~
加密就是把 明文 (要传输的信息)进行⼀系列变换, 生成密文 . 解密就是把 密文 再进行⼀系列变换, 还原成明文. 在这个加密和解密的过程中, 往往需要⼀个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为 密钥 (正确发音 yue 四声, 不过大家平时都读作 yao 四声)
对称加密:加密和解密使用同一个密钥 非对称加密:加密和解密使用不同的密钥 非对称加密的两个不同密钥之间存在着一种关联关系,实际上是通过一个算法得出的,但是很难根据一个密钥去猜测另一个密钥是什么。一般来说,两个密钥一个是公钥,一个是私钥。公钥会被公开出去让大家都知道,私钥由自己保存好。可以使用公钥加密私钥解密,也可以私钥加密公钥解密。
使用HTTPS之前(明文传输):

引入密钥之后:

此时黑客如果截获到了数据,但是不知道密钥是啥,所以也就无法解密,因此不知道真实请求是什么了。 但是没那么简单 ,如果每个客户端都使用同一个密钥加密,那么黑客只需要自己访问一下服务器然后简单在自己电脑上操作一下就能拿到所有人的密钥了。因此,比较理想的做法, 就是能在客户端和服务器建立连接的时候, 双方协商确定这次的密钥是啥~

不过嘛~肯定还没有那么简单 ,上面这个图片展示的交互过程看似简单实则暗藏玄机!黑客确实没法直接拿到你的业务数据, 但是密钥是明文传输啊,我先截取你的密钥然后再解密你的内容不就行了??
因此还需要对密钥进行加密~~~ 此时,我再加一个新的对称密钥加密这个密钥,发现我新加入的密钥还需要再加密,于是我又加了一个密钥… … … 无论多少层,还是会有一个密钥是明文传输的。 怎么办???
引入非对称加密,就是为了解决密钥明文传输的安全问题的。 我们可以采用私钥解密,公钥加密的方法来加密密钥,此时:

黑客如果截取到了数据,由于自己没有私钥解密,所以无法知道用户告知服务器的约定的对称密钥是啥,服务器就可以安心解密,继而安全的传输业务数据了~~~
不过此时有人会说:感觉这个非对称密钥很好用啊,为什么不直接使用非对称密钥传输业务数据嘞? 非对称加密虽然好用,但是运算速度慢,开销大,加密小的数据还可以,加密大量数据会非常耗时~~~ 反之对称加密运算速度快开销小,适合加密大量数据
但是就目前来看,好像已经万事大吉啦~我们完美的实现了数据的传输,战胜了黑客这个大BOSS! 啧啧啧,道高一尺魔高一丈,黑客的手法高明着呢~
现在,最阴的来啦!!!

在此场景之下,服务器首先自己有一对公钥私钥,分别为pub1,pri1。客户端先发起请求,询问服务器公钥是什么,服务器将公钥传回去。这个时候黑客自己也生成一对公钥私钥为pub2,pri2。 由于最开始传递公钥的消息是明文传输的,pub1就被黑客拦了下来,改成了pub2。客户端不知道中间被替换了,以为就是pub2,于是直接拿着pub2加密了对称密钥。这时候黑客用自己的私钥解密,拿到了对称密钥key之后,再把这个key使用原来的pub1加密,服务器这边可以正常解密,因此也不知道中间被替换了一遍。。。。。。 接下来就是黑客使用偷来的key来解密业务数据了。 不得不说,能想出这么一个偷梁换柱的方法的人真的是个天才!关键是自己不仅拿到了数据,并且服务器端和客户端甚至不知道自己的数据被偷了!
呜呜呜,怎么办,黑客好聪明啊,我们还是做不到吗… … …
没关系!遇到问题解决问题。我们目前最大的困难就是客户端无法区分收到的公钥是否是服务器真实的公钥,还是被黑客篡改过的。所以我们只要想办法验证一下就行了。 这时,就可以引出我们的证书了。
颁发证书的机构是一个可信任的公正的机构。服务器在早期搭建的时候,需要向证书机构申请一次证书,将自己的基本信息发送过去,得到的证书会被保存。 这个证书是虚拟的,数字的,这个数字证书上包括:证书的颁布机构是谁,证书的有效期是什么时候,服务器的公钥是多少,服务器的域名是多少,证书的数字签名是多少等。此处的数字签名的作用是验证身份,本质上是一个被加密的校验和,这个校验和是将要检验的数据带入一个固定的公式得到的一个数字。并且输入的值相同,得到的校验和相同,输入的值不相同,得到的校验和大概率不相同 。我们可以认为,校验和不相同,就说明输入的初始值不相同。
证书上的校验和在一开始就被第三方认证机构使用私钥加密了,并且,公钥被内置到了操作系统中,电脑内部就可以拿到(不会被篡改)。黑客就算拿到了校验和,也无法重新加密(私钥在认证机构手中),只要修改了证书内容,用户就会知道。 因此,用户端在收到消息之后,可以这样验证公钥:证书上的关键信息(包括公钥)作为输入生成校验和,与认证机构最开始算的校验和做对比,只要不一致,就是被入侵。
图解:

其实看上去,好像黑客还有翻身之地~ 1.如果黑客篡改了证书的明文怎么办? 2.如何黑客整个把证书掉包了怎么办? 首先,这两种办法都没用!!
1.如果黑客修改了公钥,重新计算出了校验和,再把新的校验和写上去,此时,黑客没有加密用的私钥,如果传到用户那边,用户没法用公钥解密数字签名,就会意识到这个证书被修改了,因此拒绝访问。 2.如果黑客整个把证书掉包了,自己去申请一个新的证书替换上去。由于计算要用的信息包括域名等唯一性的数据,计算出来的校验和不可能跟之前的一致,所以这种办法也没用。
客户端服务器交互完整流程:
