网络协议 13 - HTTPS 协议:加密路上无尽头

时间:2022-01-03 00:40:45

系列文章传送门:

  1. 网络协议 1 - 概述
  2. 网络协议 2 - IP 是怎么来,又是怎么没的?
  3. 网络协议 3 - 从物理层到 MAC 层
  4. 网络协议 4 - 交换机与 VLAN:办公室太复杂,我要回学校
  5. 网络协议 5 - ICMP 与 ping:投石问路的侦察兵
  6. 网络协议 6 - 路由协议:敢问路在何方?
  7. 网络协议 7 - UDP 协议:性善碰到城会玩
  8. 网络协议 8 - TCP 协议(上):性恶就要套路深
  9. 网络协议 9 - TCP协议(下):聪明反被聪明误
  10. 网络协议 10 - Socket 编程(上):实践是检验真理的唯一标准
  11. 网络协议 11 - Socket 编程(下):眼见为实耳听为虚
  12. 网络协议 12 - HTTP 协议:常用而不简单

    之前说了 HTTP 协议的各种问题,但是它还是陪伴着互联网、陪伴着我们走过了将近二十年的风风雨雨。现在有很多新的协议尝试去取代它,来解决性能、效率等问题,但它还还能靠着“多年的情分”活的滋润。然而,近些年,因为致命的安全问题,它不得不升级成 HTTPS 了。

    就拿我们叫外卖来说,我们点外卖的数据包被黑客截获,然后在服务器回复你之前给你回复一个假消息:“好啊,你该付款了,把银行卡号、密码拿来。”,这时如果你真的把卡号和密码发给他,那你的钱包就真的危险了。

    为了解决这些问题,我们给 HTTP 引入了加密,变成了 HTTPS。大家千万不要以为 HTTPS 是个新的协议,它实际上就是:

HTTPS = HTTP + SSL 层

    这里的 SSL 层的主要工作就是加密。加密方式一般分为两种:对称加密非对称加密

    这两种加密算法,对称加密要比非对称加密的效率要高很多,性能也好很多,所以交互的场景下多用对称加密。

对称加密

    在对称加密算法中,加密和解密的密钥是相同的。也就是说,加密和解密使用的是同一个密钥。因此,使用者一定要做好保密功能,不能让第三方知道。

    假设叫外卖的你和第三方约定了一个密钥 A,你发送请求的时候用 A 进行加密,外卖网站也用 A 进行解密,这样就算黑客截获了你们的请求,但是没有正确的密钥,还是破解不了。

    看起来很好的解决了黑客的问题。但是这里又引入了一个问题,你和外卖网站怎么来约定这个密钥呢?如果这个密钥在互联网上传输,就必须还得用 B 密钥来加密,否则被黑客获取到 A,你们的交互还是不安全,而且,你们又怎么约定 B 呢?所以,只能通过线下传输

    线下传输的话,看过《肖申克的救赎》的博友应该知道,安迪越狱前给瑞德约定了一个地点,让他去那里拿一个信封,里面写着他的住处。

    那我们和外卖网站也可以用这样的骚操作,偷偷约定时间地点,它给你一个纸条,上面写着你们两个的密钥,然后就用这个密钥在互联网定外卖。

    打住打住,上面这个操作想想都不可思议,如果最初的互联网是这样发展的话,那相信肯定活不久。

    相信你也发现了,只有对称加密,就会陷入密钥安全问题的死循环里,这时候,就需要非对称加密了。

非对称加密

    在非对称加密中 ,加密和解密过程中使用两个不相同的密钥。一个是公开的公钥,另一个是谁都不给的私钥。公钥加密的信息,只有私钥才能解密,而私钥加密的信息,也只有公钥才能解密

    放到外面上面的叫外卖过程中,非对称加密的私钥由外卖网站保存,不会再网上传输,这样就保证了私钥的私密性。与之对应的公钥是可以在互联网上随意传播的,只要外卖网站把这个公钥给你,你们就可以安全的互通了。

    还是来看我们点外卖的过程。我们用公钥加密,说“我要豆浆加油条”。黑客在中间截获了这个数据包,但是他没有私钥,没法解密数据,因此可以顺利到达外卖网站。而外卖网站用私钥把这个报文解出来,然后回复,“我知道了,你付款吧,给我卡号和密码”。

    整个过程好像很安全,再也不怕黑客了。但是,先别太乐观,你的银行卡是安全了,但是外卖网站可还是有危险的。黑客有外卖网站的公钥,可以模拟发送“我要定外卖”这个信息。

    为了解决这个问题,看来一对公钥私钥是不够的,客户端也需要有自己的公钥和私钥,并且客户端也要把自己的公钥给外卖网站。

    这样,客户端给外卖网站发送信息的时候,用外卖网站的公钥加密,而外卖网站给客户端发送消息的时候,使用客户端的公钥。这样就算有黑客企图模拟客户端获取一些信息,或者半路截获回复信息,但是由于它没有私钥,这些信息它还是打不开。

    说了那么多,相信你也发现了,非对称加密也会有同样的问题,如何将不对称加密的公钥给对方?这时有两种可行方式,一种是放在一个公网的地址上,让对方下载,另一种就是在建立连接的时候传给对方。

    这两种方法也有相同的问题。作为普通网民,你怎么鉴别别人给你的公钥是对方的,而不是被黑客冒充的?要知道,每个人都是可以创建自己的公钥和私钥的,创建过程如下:

# bash
// 创建私钥:
openssl genrsa -out httpsprivate.key 1024 // 根据私钥获取公钥
openssl rsa -in httpsprivate.key -pubout -out httpspublic.pem

HTTPS 证书

    可以看到,通过工具,我们可以很容易的创建公钥和私钥,那么黑客也是可以创建的,咱们怎么知道外卖网站传过来的公钥是不是真的就是外卖网站的呢?这时候,就需要第三方机构来当这个中间人了。

    这就像我们的户口本一样,每个人都可以打印出来,说是真的户口本,但是去使用的时候,人家就只认有*局盖章的户口本。这个由权威部门颁发的称为**证书(Certificate)。

    HTTPS 证书里面应该有以下内容:

  • 公钥:这是最重要的;
  • 所有者:说明证书是属于谁的,就像户口本上的姓名和身份证号,来证明这个户口本是你的;
  • 证书发布机构:看看你的户口本上有没有某某*局的字样?
  • 证书有效时间:这个和咱们身份证有效期是一个意思。

    说完了证书的内容,就到了下一步,怎么获取证书?这就像家里添了个小公举,去哪里上户口呢?恐怕大家都知道去*局。与之对应的,HTTPS 也有专门负责派发证书的机构,这个机构我们称为 CA(Certificate Authrity)。而证书则可以通过下面这个命令生成:

openssl req -key httpsprivate.key -new -out httpscertificate.req

    将这个请求发给 CA,CA 会给这个证书“盖”一个章,我们称为签名算法。这个签名用到 CA 的私钥进行签发,来保证签名不被伪造。

    签名算法大概是这样工作的:一般是对信息做一个 Hash 计算,得到一个 Hash 值,这个过程是不可逆的,也就是说无法通过 Hash 值还原回原来的信息内容。再把信息发出时,把上面得到的 Hash 加密后,作为一个签名和信息一起发出去。CA 给整数签名的命令是:

openssl x509 -req -in httpscertificate.req -CA cacertificate-pem -CAkey caprivate.key

    这个命令会返回 Signature ok,而 httpscertificate.pem 就是签名过的整数。CA 用自己的私钥给外卖网站的公钥签名,这就相当于给外卖网站背书,形成了外卖网站的证书。我们可以通过下面这个命令查看证书内容:

openssl x509 -in httpscertificate.pem -noout -text

    证书会显示以下内容:

  • lssuer:证书颁发者;
  • Subject:证书颁发给谁;
  • Validity:证书期限;
  • Public-key:公钥内容;
  • Sinature Algorithm:签名算法

    通过这种方式,我们访问外卖网站时,得到的不再是一个公钥,而是一个整数。这个证书里有发布机构 CA,你只要通过这个 CA 的公钥去解密外卖网站证书的签名,解密成功,Hash 对的上,就说明外卖网站的公钥是真实可信的。

    上述整个过程中,都有一个前提,CA 是可信的。但是,我们又怎么确定 CA 的公钥就是对的呢?这就像有的人在偏远农村搞了个假*局一样(应该没人这么干吧),我们怎么知道*局是不是假的呢?然后我们就会想到,我去县*局确认下当地*局的信息不就好了。没错,CA 也是这么干的。

    CA 的公钥也需要更牛的 CA 给它签名,然后形成 CA 的公钥。要想知道某个 CA 的证书是否可靠,要看 CA 的上级证书的公钥能不能解开这个 CA 的签名。这样追根溯源,直到全球皆知的几大著名 CA,我们称为Root CA,做最后的背书。正是通过这种层层授信背书的形式,保证了非对称加密模式的争吵运转。

    除此之外,还有一种证书, 称为Self-Signed Certificate,就是自己给自己签名。这个就给人一种“我就是我,不一样的烟火,你爱信不信”的感觉,有兴趣的博友可以自行搜索了解。

HTTPS 的工作模式

    上面说了对称加密和非对称加密的原理,我们知道了非对称加密在性能上远不如对称加密,那在 HTTP 中,能否将两者结合起来呢?例如,公钥私钥主要用于传输对称加密的密钥,而真正的双方大数据量的通信都是通过对称加密进行

    是的,HTTPS 协议的思路就是这样的。如下图:

网络协议 13 - HTTPS 协议:加密路上无尽头

    图比较长,整个过程最后的目标是生成在后续通信过程中使用的对称密钥,以及约定使用的加密算法。整体过程如下:

  1. 客户端明文发送 TLS 版本信息、加密套件候选列表、压缩算法候选列表等信息,另外还会发送一个随机数,在协商对称密钥的时候使用(你好,我想定外卖,但你要保密我点了什么。这是我的加密套路列表,还有一个随机数 A,你留着);
  2. 服务器返回 Server Hello 消息,告诉客户端,服务器选择使用的协议版本、加密套件、压缩算法等,还有一个随机数 B,用于后续进行密钥协商(你好,保密没问题,就按套路 2 来吧,我也给你一个随机数 B,你留着);
  3. 服务器给客户端证书;
  4. 客户端从自己信任的 CA 仓库中,拿 CA 的证书里面的公钥去解密服务器传来的证书。解密成功,说明外卖网站是可信的。这个解密过程,客户端可能胡不断往上追溯 CA、CA 的 CA、CA 的 CA 的 CA,直到一个授信的 CA 为止;
  5. 证书验证可信后,客户端会计算产生随机数字 Pre-master,发送Client Key Exchange,用证书中的公钥加密,再发给服务器;

    到此时,无论是客户端还是服务端,都有了三个随机数,分别是:A、B、Pre-master。通过这三个随机数,客户端和服务端可以产生相同的对称密钥。

    约定好对称密钥和加密算法,就可以用对称加密的形式进行加密通信了,后续的通信除了多了一步密钥校验的过程,HTTP 协议里的那些过程都不会少。

    不过上面的过程中只包含了 HTTPS 的单向认证,也就是客户端验证服务端的证书,这也是最常见的场景。不过在更加严格要求通信安全的情况下,也可以启用双向认证,双方互相验证证书。

    通过上面的整个过程,我们可以看出,HTTPS 协议并不是一个新的协议,它只是 HTTP 协议与一些加密算法的组合,用来保证通信的安全。

    虽然上面介绍的非对称加密方式,在现在看来是完美不可解的,但未来谁知道呢?正所谓“道高一尺魔高一丈”,加密安全路上永无尽头。

小结

  • 加密分对称加密非对称加密。对称加密效率高,但存在密钥传输的问题;非对称加密可以解决密钥传输的问题,但效率较低。
  • 非对称加密需要通过证书权威机构来验证公钥的合法性。
  • HTTPS 是综合了对称加密和非对称加密算法的 HTTP 协议。既保证了传输安全,也保证了传输效率。

参考:

  1. 百度百科 - htps 词条;
  2. 刘超 - 趣谈网络协议系列课;