为什么需要https？

许多人会倾向于使用复杂的词汇和行话和结论来掩盖他们不明白的东西。问题是我们只在糊弄自己，因为我们不知道自己也不明白。那么我们能否足够直白将一个知识点讲解给一个小孩子听懂呢？

大家好，今天要跟大家谈论的是我们通常所说的HTTPS（SSL、TLS）这样的一些手段如何来保证网络信息传输的安全性。不管你是发送一个邮件，还是每天在浏览器中浏览网页，都使用了https这样一种现代通用的加密手段。在之前我们其实谈论过，在网络当中实际上有OSI七层的网络模型，物理层，链接层，网络层，传输层。

OSI 7层网络模型

在数据包装包与解包的过程中，实际上都是把上一层包封装到下一层中，类似于洋葱一样层层包裹的方式。

数据包-层层包装

当一个数据包到达中间的路由器或者到达了目的地以后，处理器就会把数据包逐个的解析出来。比如mac地址是不是当前的服务器地址，IP应该走哪一个路由网关，端口是哪一个服务的端口等实际上都能够获取到。如果是HTTP协议，进一步的我们还可以获取到HTTP传输的数据。

通过一些抓包工具，例如wireshark，我们能够很容易的看到，其实信息在这样的一个中间服务器当中，都是完全透明的。

wireshark解析HTTP

比如说我们在wireshark中看到的信息就是它层层解析以后，所展现出来的内容。所以你发送的一些密码或者是内容，我都能够捕获到它并且明文解析。

wireshark解析HTTP

随着互联网的发展，传统HTTP的方式实际上面临着很多的困难，这些困难就包括之前提到的，如果你身处不信任的网络中，我们不知道数据包会经历什么样的中间节点，中间人就可能会对我们的数据做一些干扰。

窃听（eavesdropping）、篡改（tampering）、重放(replay) 是HTTP协议面临的3类攻击。

例如下图最上面的例子，中间人捕获到了信息，然后再把信息发送给服务器，但是你可能并不知道这个中间人的存在，他做了什么你完全都不知道。但他实际上已经掌握了你的信息。

HTTP中间人攻击

上图最下面的例子，中间人可以主动的做攻击。比如中间人得到服务器发送给用户的一些信息后做一些其他处理。比如换成钓鱼网站，或者加一些广告在里面。还有一种方式就是捕获到你的信息以后，中间人可以把这个消息给发送很多次，比如一个转账的处理，这就是重放攻击。

所以HTTP确实面临一些困境。我们需要有一些手段，这些手段包括对于信息的加密，中间人就算得到了信息，也不能够对于消息进行解密。但其实加密是远远不够的，在中间人的攻击中，可能不需要解密信息，而是替换掉你的信息。

所以还必须要有一种身份验证的手段。能够确认声明人的身份，比说他说他是A，那我怎么知道他就是A？

现实当中面对面交流的时候，我可能知道他是A，但是如果在互联网上，比如XX找你借钱或者转账，我不知道他是谁的时候，我应该怎么办？这个时候我们需要更多的信息确认或验证他的身份，在HTTPS中采用的是信用链的机制。

出于上诉安全原因，网景公司(Netscape)在90年代初开始研发SSL协议，1995年正式发布SSL2.0版本，由于协议的安全问题，1996年升级到了SSL3.0版本。

1999年 由IEFT协会制定标准，过渡到tls(Transport Layer Security)，实际可看做是SSL3.1版本。

90年代末，网景公司和微软公司正在打浏览器的大战，所以TLS的设计者在后来回忆也讲到。把SSL改名为TLS主要的原因就是考虑到微软的感受。

"so it wouldn't look [like] the IETF was just rubberstamping Netscape's protocol" ————Tim Dierks

06年出了TLS1.1版本,08年出了TLS1.2版本,然后在十年之后的2018年，出了TLS1.3版本。

版本的升级过渡有很多方面的考虑，包括补充了更多的加密协议，丢弃掉老的过时的加密协议。在TLS1.3版本中会更关注降低服务的round trip，也就是在握手的时候我怎么样能够更快速，更短的握手次数。

TLS是在TCP之上的，常见的应用层以下的一层。所以可以把它叫做4.5层。由于改动TCP层已经很难了，它不仅是很多路由协议采用的标准，并且在很多操作系统当中，对TCP的一些处理都是嵌到内核里面处理的，升级改造比较困难。所以很多新的协议都是建立在TCP或者UDP之上的。

TLS的位置和功能

TLS相当于4.5层，目前用的最多的是对HTTP协议的封装。所以说很多人会把它叫做HTTPS，当然这种说法肯定是不准确的，他还包括了对于其他一些应用层协议的封装。包括可以使用TLS做一个隧道，从而让一些其他协议正常的传输。

TLS作为一种协议，协议中字段的含义在服务器与客户端之间达成共识，比如上图中这个消息是什么样的消息。它可能是握手的消息，改变密钥的消息，告警的消息，正常数据传输的消息。还包括数据如何分段传输，数据如何压缩，如何进行加密、鉴权等机制。

首先看一看TLS 1.2当中握手的方式，会更加清晰。TLS 1.3是对TLS 1.2的改进和升级。在TLS1.2当中，握手的方式主要是怎么样的呢？我们知道肯定会首先进行TCP的三次握手对吧？但是我们都知道，在第三次握手的时候，客户端是可以携带消息的，所以说在引用的这张图当中,作者把客户端 ACK这个消息和要发送的TLS的hello消息整合在了一起。

TLS1.2握手

服务器需要回什么消息呢？它需要回hello以及回复版本号信息，公钥等。在这里实际上统一起来信息是一个x.509格式的证书。证书里面包含了很多东西，包括版本号，包括发行人，过期时间，公钥等等。客户端得到这个服务器的证书以后，就会解析证书确认服务器的身份。

确认了以后。客户端和服务器下一步需要对于对称加密的参数进行协商，传递加密的一些参数和对应的加密算法，以及pre_master_secret，随机数等信息。客户端和服务器根据这些信息生成最终对称加密的密钥。

可以看到，TLS1.2 在握手的时候实际上传递证书和对称加密协商，消耗了2个round trip，那么能不能缩减这一过程呢？

TLS1.3通过提前在client hello阶段进行对称加密的协商来做到将握手缩减到1个round trip， 甚至在已经建立了连接之后，能够做到0 round trip 的再次建连。

TLS1.3 降低握手次数

总结

https通过加密与权限验证保证了信息的安全性，其中对于客户端的权限验证使用了x.509公钥证书标准，而传输信息的加密使用了对称加密的机制。

对于TLS握手，在TSL1.2以及以前，一般在TCP握手的基础上还需要2次round trip，而TLS1.3通过提前在client hello阶段进行对称加密的协商来做到将握手缩减到1个round trip， 甚至在已经建立了连接之后，能够做到0 round trip 的再次建连。

那么为什么需要非对称加密和对称加密两种方式？一种够不够呢？下一次我们将对证书的信用链机制和对称加密进行仔细探讨，我们会看到，从直觉入手，这一切演进都是多么自然和美妙。