Https

Https

Https 为了解决http风险,http数据是明文发送

  1. 窃听风险

    窃听http中的数据,中间人可以获取通信内容。

  2. 篡改风险

    中间人篡改明文内容,再发送对方。

  3. 冒充风险

    中间人冒充对方,进行通信 钓鱼网站

安全通信的四大原则

机密性、完整性,身份认证和不可否认。

  • 机密性:即对数据加密,解决了窃听风险,因为即使被中间人窃听,由于数据是加密的,他也拿不到明文;
  • 完整性:指数据在传输过程中没有被篡改,不多不少,保持原样,中途如果哪怕改了一个标点符号,接收方也能识别出来,从来判定接收报文不合法;
  • 身份认证:确认对方的真实身份,即证明“你妈是你妈”的问题,这样就解决了冒充风险,用户不用担心访问的是某宝结果却在和钓鱼网站通信的问题;
  • 不可否认: 即不可否认已发生的行为,比如小明向小红借了 1000 元,但没打借条,或者打了借条但没有签名,就会造成小红的资金损失。

HTTPS 通信原理简述

对称加密:HTTPS 的最终加密形式。

既然 HTTP 是明文传输的,那我们给报文加密不就行了,既然要加密,我们肯定需要通信双方协商好密钥吧。一种是通信双方使用同一把密钥,即对称加密的方式来给报文进行加解密。

如图示:使用对称加密的通信双方使用同一把密钥进行加解密。

对称加密具有加解密速度快,性能高的特点,也是 HTTPS 最终采用的加密形式。但是这里有一个关键问题:对称加密的通信双方要使用同一把密钥,这个密钥是如何协商出来的?如果通过报文的方式直接传输密钥,之后的通信其实还是在裸奔,因为这个密钥会被中间人截获甚至替换掉,这样中间人就可以用截获的密钥解密报文,甚至替换掉密钥以达到篡改报文的目的。

有人说对这个密钥加密不就完了,但对方如果要解密这个密钥还是要传加密密钥给对方,依然还是会被中间人截获的,这么看来直接传输密钥无论怎样都无法摆脱俄罗斯套娃的难题,是不可行的。

非对称加密:解决单向对称密钥的传输问题

直接传输密钥无论从哪一端传从上节分析来看是不行了,这里我们再看另一种加密方式:非对称加密。

非对称加密即加解密双方使用不同的密钥,一把作为公钥,可以公开的,一把作为私钥,不能公开,公钥加密的密文只有私钥可以解密,私钥加密的内容,也只有公钥可以解密。

注:私钥加密其实这个说法其实并不严谨,准确的说私钥加密应该叫私钥签名。因为私密加密的信息公钥是可以解密的,而公钥是公开的,任何人都可以拿到,用公钥解密叫做验签。

这样的话对于 server 来说,保管好私钥,发布公钥给其他 client, 其他 client 只要把对称加密的密钥加密传给 server 即可。如此一来由于公钥加密只有私钥能解密,而私钥只有 server 有,所以能保证 client 向 server 传输是安全的,server 解密后即可拿到对称加密密钥,这样交换了密钥之后就可以用对称加密密钥信了。

但是问题又来了, server 怎么把公钥安全地传输给 client 呢。如果直接传公钥,也会存在被中间人调包的风险。

数字证书,解决公钥传输信任问题

如何解决公钥传输问题呢?从现实生活中的场景找答案。员工入职时,企业一般会要求提供学历证明,显然不是什么阿猫阿狗的本本都可称为学历,这个学历必须由第三方权威机构(Certificate Authority,简称 CA)即教育部颁发。同理,server 也可以向 CA 申请证书,在证书中附上公钥,然后将证书传给 client,证书由站点管理者向 CA 申请,申请的时候会提交 DNS 主机名等信息,CA 会根据这些信息生成证书。

这样当 client 拿到证书后,就可以获得证书上的公钥,再用此公钥加密对称加密密钥传给 server 即可。


文章作者: 凌云
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 凌云 !
  目录