浅谈网络传输安全

Table of Contents

原文：https://time.geekbang.org/column/article/334958

签名、加密、摘要
#

摘要和加密的区别：

摘要也被叫做是数字摘要（Digital Digest）或数字指纹（Digital Fingerprint）。在 JWT 令牌中，默认的签名信息就是通过令牌头中指定的哈希算法（HMAC SHA256），针对令牌头、负载和密钥所计算出来的摘要值。摘要是不可逆的，而加密是可逆的，逆过程就是解密。

对称加密算法

加密和解密都使用相同的密钥，当通讯的成员数量增加时，为了保证两两通讯都能采用独立的密钥，密钥数量就要与成员数量的平方成正比，会面临密钥管理的难题。

还有一个难题是，如何才能把一个只能让通讯双方才能知道的密钥传输给对方。

非对称加密算法

非对称加密算法把密钥分成了公钥和私钥，公钥可以完全公开，无需安全传输的保证。私钥由用户自行保管，不参与任何通讯传输。

公钥加密，私钥解密，这种就是加密。这样确保了内容既不会被读取，也不能被篡改。
私钥加密，公钥解密，这种就是签名。让所有公钥所有者验证私钥所有者的身份，并能用来防止私钥所有者发布的内容被篡改。但是它不用来保证内容不被他人获得。

非对称加密算法的计算复杂度都相当高，性能比对称加密要差上好几个数量级。因为非对称加密本身的效率所限，难以支持分组，所以主流的非对称加密算法都只能加密不超过密钥长度的数据，这就决定了非对称加密不能直接用于大量数据的加密。

在加密方面，现在一般会结合对称与非对称加密的优点，通过混合加密来保护信道传输的安全。用非对称加密来安全地传递少量数据给通讯的另一方，然后再以这些数据为密钥，采用对称加密来安全高效地大量加密传输数据。这种由多种加密算法组合的应用形式，就被称为“密码学套件”，非对称加密在这个场景中发挥的作用被称为“密钥协商”。

在签名方面，现在一般会结合摘要与非对称加密的优点，通过对摘要结果做加密的形式来保证签名的适用性。只要对摘要的结果进行签名，就相当于对整个输入源进行了背书，这样就能保证一旦内容遭到了篡改，摘要结果就会变化，签名也就马上失效了。

数字证书
#

签名还是无法保证负载中的信息不可篡改、不可抵赖，因为拿到的公钥可能是被篡改的。所以，当我们无法以“签名”的手段来达成信任时，就只能求助于其他途径。

{{ < alert “fire” >}} 公开密钥基础设施（Public Key Infrastructure，PKI）。又称公开密钥基础架构、公钥基础建设、公钥基础设施、公开密码匙基础建设或公钥基础架构，是一组由硬件、软件、参与者、管理政策与流程组成的基础架构，其目的在于创造、管理、分配、使用、存储以及撤销数字证书。

密码学上，公开密钥基础建设借着数字证书认证中心（Certificate Authority，CA）将用户的个人身份跟公开密钥链接在一起。对每个证书中心用户的身份必须是唯一的。链接关系通过注册和发布过程创建，取决于担保级别，链接关系可能由 CA 的各种软件或在人为监督下完成。PKI 的确定链接关系的这一角色称为注册管理中心（Registration Authority，RA）。RA 确保公开密钥和个人身份链接，可以防抵赖。 {{ < /alert >}}

数字证书认证中心（Certificate Authority，CA）即 “权威公证人” 的角色，它是负责发放和管理数字证书的权威机构。CA 作为受信任的第三方，就承担了公钥体系中公钥的合法性检验的责任。

权威的 CA 中心是可数的。“可数的”就意味着可以不通过网络，而是在浏览器与操作系统出厂时就预置好，或者是提前就安装好（如银行的证书）。

证书（Certificate）是权威 CA 中心对特定公钥信息的一种公证载体，你也可以理解为是权威 CA 对特定公钥未被篡改的签名背书。由于客户的机器上已经预置了这些权威 CA 中心本身的证书（可以叫做 CA 证书或者根证书），这样就让我们在不依靠网络的前提下，使用根证书里面的公钥信息，对其所签发的证书中的签名进行确认。

PKI 中采用的证书格式是 X.509 标准格式，它定义了证书中应该包含哪些信息，并描述了这些信息是如何编码的。其中最关键的，就是认证机构的数字签名和公钥信息两项内容。

标准 X.509 格式的 CA 证书

版本号（Version）：指出该证书使用了哪种版本的 X.509 标准
```
Version: 3 (0x2)
```
序列号（Serial Number）：这是由证书颁发者分配的本证书的唯一标识符。
```
Serial Number: 04:00:00:00:00:01:15:4b:5a:c3:94
```
签名算法标识符（Signature Algorithm ID）：它是签证书的算法标识，由对象标识符加上相关的参数组成，用于说明本证书所用的数字签名算法。比如，SHA1 和 RSA 的对象标识符就用来说明，该数字签名是利用 RSA 对 SHA1 的摘要结果进行加密。
```
Signature Algorithm: sha1WithRSAEncryption
```
认证机构的数字签名（Certificate Signature）：这是使用证书发布者私钥生成的签名，以确保这个证书在发放之后没有被篡改过。

认证机构（Issuer Name）：即证书颁发者的可识别名。

Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2

有效期限（Validity Period）：即证书起始日期和时间以及终止日期和时间
```
Validity
    Not Before: Nov 21 08:00:00 2020 GMT
    Not After : Nov 22 07:59:59 2021 GMT
```
主题信息（Subject）：证书持有人唯一的标识符（Distinguished Name），这个名字在整个互联网上应该是唯一的，通常使用的是网站的域名。
```
Subject: C=CN, ST=GuangDong, L=Zhuhai, O=Awosome-Fenix, CN=*.icyfenix.cn
```
公钥信息（Public-Key）：它包括了证书持有人的公钥、算法 (指明密钥属于哪种密码系统) 的标识符和其他相关的密钥参数。

传输安全
#

让用户无感知地实现安全通讯，最合理的做法就是在传输层之上、应用层之下加入专门的安全层来实现。

TLS 1.2 在传输之前的握手过程中，一共需要进行上下两轮、共计四次的通讯。我们来看一下这个握手过程的时序图：

客户端请求：Client Hello
#

客户端向服务器请求进行加密通讯，在这个请求里面，它会以明文的形式，向服务端提供以下信息：

支持的协议版本，比如 TLS 1.2。但是你要注意，1.0 至 3.0 分别代表了 SSL1.0 至 3.0，而 TLS1.0 则是 3.1，一直到 TLS1.3 的 3.4。
一个客户端生成的 32 Bytes 随机数。这个随机数将稍后用于产生加密的密钥。
一个可选的 SessionID。注意，你不要和前面的 Cookie-Session 机制混淆了，这个 SessionID 是指传输安全层的 Session，它是为了 TLS 的连接复用而设计的。
一系列支持的密码学算法套件。比如 TLS_RSA_WITH_AES_128_GCM_SHA256，代表着密钥交换算法是 RSA，加密算法是 AES128-GCM，消息认证码算法是 SHA256。
一系列支持的数据压缩算法。
其他可扩展的信息。为了保证协议的稳定，后续对协议的功能扩展大多都是添加到这个变长结构中。比如 TLS 1.0 中，由于发送的数据并不包含服务器的域名地址，导致了一台服务器只能安装一张数字证书，这对虚拟主机来说就很不方便，所以从 TLS 1.1 起，就增加了名为“Server Name”的扩展信息，以便一台服务器给不同的站点安装不同的证书。

服务器回应：Server Hello
#

服务器接收到客户端的通讯请求后，如果客户端声明支持的协议版本和加密算法组合，与服务端相匹配的话，就向客户端发出回应。如果不匹配，将会返回一个握手失败的警告提示。

这次回应同样是以明文发送的，主要包括以下信息：

服务端确认使用的 TLS 协议版本。
第二个 32 Bytes 的随机数，稍后用于产生加密的密钥。
一个 SessionID，以后可通过连接复用减少一轮握手。
服务端在列表中选定的密码学算法套件。
服务端在列表中选定的数据压缩方法。
其他可扩展的信息。
如果协商出的加密算法组合是依赖证书认证的，服务端还要发送出自己的 X.509 证书，而证书中的公钥是什么，也必须根据协商的加密算法组合来决定。
密钥协商消息，这部分内容对于不同的密码学套件有着不同的价值。比如对于 ECDH + anon 这样的·密钥协商算法组合来说（基于椭圆曲线的 ECDH 算法可以在双方通讯都公开的情况下，协商出一组只有通讯双方知道的密钥），就不需要依赖证书中的公钥，而是通过 Server Key Exchange 消息协商出密钥。

客户端确认：Client Handshake Finished
#

只用 RSA 算法作为密钥交换算法来给你举个例子:

首先，客户端在收到服务器应答后，要先验证服务器的证书合法性。然后，如果证书不是可信机构颁布的，或者是证书中的信息存在问题，比如域名与实际域名不一致、或证书已经过期、或通过在线证书状态协议得知证书已被吊销，等等，这都会向访问者显示一个“证书不可信任”的警告，由用户自行选择是否还要继续通信。

接着从证书中取出服务器的公钥，并向服务器发送以下信息:

客户端证书（可选）。部分服务端并不是面向全公众的，而是只对特定的客户端提供服务，此时客户端就需要发送它自身的证书来证明身份。如果不发送，或者验证不通过，服务端可自行决定是否要继续握手，或者返回一个握手失败的信息。客户端需要证书的 TLS 通讯，也被称为“双向 TLS”（Mutual TLS，常简写为 mTLS），这是云原生基础设施的主要认证方法，也是基于信道认证的最主流形式。
第三个 32 Bytes 的随机数，这个随机数不再是明文发送，而是以服务端传过来的公钥加密的，它被称为 PreMasterSecret，将与前两次发送的随机数一起，根据特定算法计算出 48 Bytes 的 MasterSecret，这个 MasterSecret 也就是为后续内容传输时的对称加密算法所采用的私钥。
编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的哈希值，以供服务器校验。

服务端确认：Server Handshake Finished
#

服务端回应：

编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的哈希值，以供客户端校验。

至此整个 TLS 握手阶段就宣告完成，一个安全的连接就成功建立了

以上的握手过程协商出许多信息，比如一个只有双方才知道的随机产生的密钥、传输过程中要采用的对称加密算法（例子中的 AES128）、压缩算法等，此后该连接的通讯将使用此密钥和加密算法进行加密、解密和压缩。

建立在这层安全传输层之上的 HTTP 协议，就被称为“HTTP Over SSL/TLS”，也即是我们所熟知的 HTTPS。

2018 年，最新的 TLS 1.3（RFC 8446）发布，比起前面版本相对温和的升级，TLS 1.3 做出了一些激烈的改动，修改了从 1.0 起一直没有大变化的两轮四次（2-RTT）握手，首次连接仅需一轮（1-RTT）握手即可完成；在有连接复用支持的时候，甚至可以把 TLS 1.2 原本的 1-RTT 下降到 0-RTT，显著提升了访问速度。