技术笔记

从加密解密演进看 HTTPS 通信(下)——HTTPS 通信流程

2019-10-12  本文已影响0人  Gzw丶南山

前情提要

上一篇文章简单描述了加密解密的演进历史,如果对这部分不感兴趣的小伙伴其实可以跳过那篇文章,不过在讲之前我还是要先做一些知识点铺垫工作,避免文中遇到这些名词时没头绪。

加密主要是分成对称加密和非对称加密,这里会涉及到这些知识点:

HTTPS 通信流程

讲 HTTPS 之前我们先来看看为什么 HTTP 不能满足我们的需求,它都存在哪些问题?当我们了解了它的缺点,我们也就更容易理解,为什么 HTTPS 的通信过程要像现在这样设计了。

HTTP 通信的四类问题

HTTP 通信的四类问题:

那我们能否利用已有知识解决这些问题呢?答案是基本上可以,让我们来看看这些问题具体该如何解决:

那既然我们知道了 HTTP 的信息传输过程中存在的这些问题,那我们接下来就进入正题,看看 HTTPS 如何解决掉这些问题。

HTTPS 介绍

了解通信流程之前,还需要先对 HTTPS 简单做个介绍,为什么 HTTPS 可以保障安全,它和 HTTP 到底有什么区别和联系?

其实 HTTPS = HTTP over SSL / TLS,这样看的话,其实它和 HTTP 的区别就是在于多了 SSL / TLS,所以 HTTPS 的密钥协商、传递、加密解密也肯定都是由 SSL / TLS 完成的。至于 SSL 和 TLS 的区别其实是 TLS 是 SSL 的升级版,一开始 HTTPS 刚出来的时候安全层是 SSL,后来协议标准化,就在 SSL 的基础上进行优化修改并且将其改名为 TLS。

原本 HTTP 的数据是会扔给 TCP 进行处理发送的,而 HTTPS 中成了 HTTP 数据扔给 SSL / TLS 加密处理,然后在由 SSL / TLS 扔给 TCP,对方收到后也是 TCP 扔给 SSL / TLS 进行解密,最后扔给 HTTP。现在像是在这两者之间插入了一层,所以我一般也称 SSL / TLS 为安全层。

HTTP -> TCP(HTTP)
HTTP -> TLS -> TCP(HTTPS)

介绍完了什么是 HTTPS 后,如果只用一句话概括它,其实 HTTPS 的本质就是用非对称加密协商出一套对称加密密钥。然后数据的传递都是通过对称加密去做。这样既保障了安全又保障了效率。

保障效率是因为后续真正的数据传输其实是通过对称加密来完成的,相比之下,非对称加密由于涉及到到大量运算,执行起来比对称加密要慢,而保障安全是因为对称加密密钥的传输是通过非对称加密的方式解决掉的。

HTTPS 通信流程

下面就来看看 HTTPS 的通信流程吧。

先来看下面这张图:


image

TLS 或 HTTP 下层都是 TCP,所以不管怎样我们都需要先通过 TCP 三次握手来建立连接,然后再在这个连接基础上,进行 TLS 的握手。粗略的看话,我觉得 TLS 握手主要包括以下内容:

如果仔细来看的话,我建议看着下面这张图:


图片来自《趣谈网络协议》

那让我们再来详细的展开以下这个 TLS 的握手流程:

这就是我理解的 HTTPS 的通信流程了,不过刚才上面还缺失了重要一环也是证书验证的内容,下面来主要讲讲证书验证。

证书验证

回想一下我们最开始提到的如果爱丽丝想要和鲍勃使用非对称加密进行安全通信的话,那就必须先让爱丽丝拿到鲍勃的公钥才行,有什么办法可以拿到对方的公钥吗?

如果仔细想想的话这两种方式其实都有问题,前者如果中间人伊芙引导你访问了错误的网站就会导致你拿到错误的公钥,而后者伊芙可能在你们公钥传输的过程中对信息进行拦截和篡改,所以爱丽丝想要拿到正确的鲍勃的公钥并不容易。

那这个问题有解决方案吗?就是通过非对称加密的签名来处理,但是鉴于没法拿到正确的鲍勃的公钥所以没法让鲍勃进行签名发送过来,这时就需要一个第三方权威机构,我们都信任它,而它会用自己的私钥对鲍勃的公钥进行签名,然后我们只需要拿到这个第三方权威机构的公钥进行验签即可。

回到实际场景中来,这个第三方机构,就是证书颁发机构,也被称为 CA(后面也都简写为 CA),如果服务端想让 CA 给它颁发证书(信用背书),就会把自己的公钥和身份信息发给 CA,CA 验证没问题后,生成证书信息,并且 CA 会对证书信息做一个摘要算法,就像提取指纹信息一样,然后会对计算出来的 Hash 值进行签名,最后打包下发。

先来粗略看下证书里面都会包含什么信息:

那我们该如何验证签名呢?

但你可能会问,这个过程好像只是验证了给证书签名时的 CA 私钥和我们拿到的 CA 公钥是对的上的,那如果 CA 证书下发过程本身就问题怎么办呢? 我怎么能确认给这个服务端背书的 CA 是否可信呢?

要回答这个问题其实并不难,就是让那个 CA 在找别的更大的更可信的 CA 给他做信用背书,直到找到背后那几个全球最大的 CA 机构,这些 CA 机构也被称为 root CA,这些 CA 就已经是我们无条件要相信的了,这就像你可以不相信同事告诉你的公司消息,但是同事告诉你这个消息是组长告诉我的,你去问了组长还是不相信,组长说这个是经理告诉我的,你去问了经理还是不相信,经理说这个是老板刚发的公司消息,最终你去问了老板并确认了消息,这时这条信任链就已经完整构建起来了。

所以给服务端下发证书的 CA(简称 CA L),它的公钥其实是另一个更大 CA(简称 CA H)用自己的私钥给它签名的,也就是 CA H 会根据 CA L 提供行公钥和身份信息给它颁发证书,然后这样递归下去,直到我们刚刚说的 root CA。

所以验证的顺序也像图中这样,可能看图更好理解,我要验证服务端证书就去找给中介 CA 拿它的公钥进行验签(因为服务端证书是中介 CA 下发的),而中介 CA 证书验证又要去找 root CA 拿它的公钥进行验证(同理中介 CA 的证书是 root CA 下发的),那么 root CA 的公钥在哪里呢?一般在操作系统里面都会有各大 root CA 的信息,当然浏览器或者某些软件(比如支付宝)里也会有。这时我拿到了 root CA 的公钥信息,然后对中介 CA 证书进行验证(证书验证过程上面已经讲到了),验证完成后拿到中介 CA 的公钥再对服务端证书进行验证,这样如果都没问题,就说明整条信任链是通的,而我也可以放心拿服务端证书里的公钥和对方进行非对称加密通信了。

image

补充

image image

总结

到这里 HTTPS 的通信流程也就说完了。

如果只用一句话总结 HTTPS 就是它的本质是通过非对称加密协商出一套对称密钥,而后续真正数据都是使用对称加密进行通信。

这里面的最难搞懂的点可能就是为什么要有证书和证书验证过程。

说多了都是泪,希望看到这里之后 HTTPS 对你来说就不是什么难理解的事情了。

感谢

以上内容参考了扔物线的 HenCoder Plus、极客时间的《趣谈网络协议》、《透视 HTTP 协议》、《全栈工程师修炼指南》及 HTTPS 相关维基百科。

尤其是那两张很全的 HTTPS 流程图都是出自极客时间专栏,黑白的那种出自《趣谈网络协议》,而最后那张彩色的出自《透视 HTTP 协议》。

最后的最后

如果你觉得我写不错,那就通过点赞,点赞,还 tm 是点赞的方式给我反馈吧,感谢你的支持。

上一篇 下一篇

猜你喜欢

热点阅读