SSL/TLS 及其加密系统的完整概述

1.什么是 SSL/TLS？

2. SSL/TLS的历史

3. TLS 在哪里使用？

4.为什么我们需要TLS？

5.TLS 如何工作？

6.为什么TLS同时使用对称和非对称加密？

7.对称密码学

8.椭圆曲线密码学

9.非对称加密

10. TLS 1.3握手协议

我想你们很多人都了解 HTTPS，有些人可能已经为自己的 Web 服务器设置了 SSL/TLS。但是，你们中有多少人真正理解 SSL/TLS 的工作原理呢？

你知道吗：

TLS 握手期间到底发生了什么？
TLS 使用什么加密算法来保护数据？
客户端和服务器如何交换密钥？
Diffie-Hellman 临时密钥交换如何工作？
为什么我们需要数字证书？
为什么需要由证书颁发机构签名？
什么是数字签名？如何签名和验证？
完美前向保密是什么意思？
AEAD、MAC、HKDF、0-RTT 如何工作？
什么是椭圆曲线密码学？
与 TLS 1.2 相比，TLS 1.3 有哪些新功能？

有很多问题，我不想只谈皮毛。所以，这篇文章会非常详尽地讲解 SSL/TLS 的一切，它是互联网安全极其重要的基石。

1.什么是 SSL/TLS？

SSL 代表安全套接字层。它是 TLS 的前身。

TLS 是传输层安全性的缩写，是一种通过计算机网络提供安全通信的加密协议。

2. SSL/TLS的历史

以下是 SSL 和 TLS 的一些历史：

SSL 最初由 Netscape 开发，于 1995 年首次发布 2.0 版本
由于存在一些严重的安全漏洞，SSL 1.0 版本从未公开发布。
1996 年，SSL 3.0 版本发布，对该协议进行了彻底的重新设计。
三年后，TLS 1.0 首次由 IETF 在 RFC 2246 中定义，作为 SSL 3.0 版的升级
花了 7 年时间才于 2006 年升级到 TLS 1.1
TLS 1.2 于 2008 年随即问世。
经过 10 年的努力，我们终于在 2018 年推出了具有巨大改进的 TLS 1.3。

那么目前还存在哪个 SSL/TLS 版本？

SSL 2.0 已于 2011 年弃用
SSL 3.0 已于 2015 年弃用
最近，在2020年3月，TLS 1.0和TLS 1.1也已失效。这意味着只有TLS 1.2和1.3仍然有效。

3. TLS 在哪里使用？

首先，它在网络上被广泛使用。所有你使用 HTTPS 访问的网站都受到 TLS 的保护，或者我们常说的 HTTP over TLS。

同样，采用SMTPS协议的电子邮件实际上就是SMTP和TLS。

那么安全文件传输协议FTPS也是FTP加TLS。

TLS 还有许多其他应用，我没有足够的时间提及。

4.为什么我们需要TLS？

因为 TLS 为我们提供了 3 样东西：

验证
- TLS 验证通信方的身份，通常是客户端和服务器。
- 借助非对称加密，TLS 确保我们访问的是真实的网站，而不是虚假的网站。
保密性
- TLS 通过使用对称加密算法对交换的数据进行加密，保护数据免遭未经授权的访问。
正直
- TLS 通过检查消息认证码来识别传输过程中数据的任何更改，我们稍后会了解这一点。

5.TLS 如何工作？

基本上，TLS 由两个阶段或两个协议组成：

握手协议

在此阶段，客户端和服务器将：
- 协商协议版本
- 选择加密算法（或密码套件）
- 通过非对称加密相互认证
- 建立一个共享密钥，用于下一阶段的对称加密。
因此握手的主要目的是进行身份验证和密钥交换。
记录协议

在此阶段：
- 所有传出的消息都将使用握手中建立的共享密钥进行加密。
- 然后将加密的消息传输到另一端。
- 他们将进行验证，以查看传输过程中是否有任何修改。
- 如果不是，则使用相同的对称密钥解密消息。
因此我们将在此记录协议中同时实现机密性和完整性。

并且由于此阶段加密的数据量很大，因此通常称为批量加密。

6.为什么TLS同时使用对称和非对称加密？

为什么不只使用一个来实现所有目的呢？

嗯，很容易看出对称加密无法提供身份验证。由于客户端和服务器都只有一个密钥，因此它们彼此之间没有任何信息需要验证。更不用说，如何在不泄露的情况下获得相同的密钥，这本身就很困难。

非对称加密怎么样？听起来是个不错的选择。可惜的是，它比对称加密慢得多。我说的“慢”是指慢 100 倍甚至 10000 倍。所以它显然不适合批量加密。

7.对称密码学

好了，现在我们来进一步了解对称密码学。我想你已经了解了一些基础知识。

首先，Alice 有一条想要发送给 Bob 的纯文本消息，但不想让公共区域的任何人阅读它。

于是她用之前彼此分享过的密钥加密了这条消息，然后通过公共互联网将加密后的消息发送给了Bob。

收到加密消息后，Bob 可以轻松使用相同的密钥对其进行解密。

由于加密和解密使用相同的密钥，因此它是一种对称的，所以我们称之为对称密码学。

现在可能有一个叫哈利的黑客，他可以在公共网络上截获他们交换的信息。然而，该信息已经加密，而哈利没有密钥，所以他无法解密。

但他仍然可以改变它！

7.1 位翻转攻击

有一种称为位翻转攻击的技术，其工作原理如下：

假设这次 Alice 不是在和 Bob 对话，而是在和她的网上银行对话。她想给某人汇 100 美元。这条消息会用密钥加密，并通过互联网发送给银行。

现在，哈利截获了加密信息。虽然他无法解密，但他可以将部分比特位从 1 翻转为 0，再从 0 翻转为 1，然后将修改后的信息转发给银行。

现在，当银行解密时，他们将获得不同的明文内容。在这种情况下，它变成了 900 美元，而不是 100 美元。

所以这非常危险。这就是为什么我们需要确保加密信息在传输过程中没有被篡改。

但怎么做呢？

7.2 认证加密（AE）

一种方法是使用认证加密。其理念是不仅加密，还要验证加密消息。

第一步是加密。

Alice 的明文消息经过对称加密算法，例如 AES-256-GCM 或 CHACHA20。

该加密算法同样以共享密钥和随机数（或初始化向量 (IV)）作为输入，并返回加密消息。

第二步是身份验证。

加密消息、密钥和随机数成为 MAC 算法的输入，例如，如果使用 AES-256-GCM，则为 GMAC；如果使用 CHACHA20 加密算法，则为 POLY1305。

该 MAC 算法的作用类似于加密哈希函数，其输出是 MAC，即消息认证码。

现在，这个 MAC 会与加密消息一起被标记，最终结果会发送给 Bob。因此，我们有时将此 MAC 称为认证标记。

添加一些相关数据（AD）

在 TLS 1.3 中，除了加密消息之外，我们还需要验证一些相关数据，例如：地址、端口、协议版本或序列号。这些信息是未加密的，并且通信双方都知道。

因此关联数据也是 MAC 算法的输入。因此，整个过程被称为带关联数据的认证加密（Authenticated Encryption with Associated Data），简称AEAD。

解密和MAC验证

现在让我们看看 Bob 如何检查加密消息在传输过程中是否被更改。

这只是一个相反的过程。从带有 MAC 的加密消息开始，我们从加密消息中取消 MAC 的标记。

然后，加密消息将与共享密钥和随机数 (nonce) 一起进入 MAC 算法。请注意，这里使用的随机数与加密过程中使用的随机数相同。通常，在发送给接收方之前，会将随机数填充到加密消息中。

相关数据也将进入MAC算法，其输出将是另一个MAC。

现在，Bob 只需比较这两个 MAC 值即可。如果它们不同，则他知道加密消息已被更改。否则，他可以安全地解密该消息并使用它，并且确信它与 Alice 发送的明文消息相同。

7.3 密钥交换

但是，有一个问题：Bob 和 Alice 如何在不向公众泄露密钥的情况下相互共享密钥？

答案是：他们需要使用非对称加密或公钥加密来实现这一目的。具体来说，他们可以使用 Diffie-Hellman Ephemeral 或椭圆曲线 Diffie-Hellman Ephemeral。

7.3.1 Diffie-Hellman密钥交换

让我们看看 Diffie Hellman 密钥交换是如何工作的！

首先，Alice 和 Bob 就两个数字达成一致：底数 g 和模数 p。这些数字是公开的。

然后他们各自秘密选择一个私有数字。Alice 的私钥是数字a，Bob 的私钥是数字b。

然后 Alice 计算她的公钥并将其发送给 Bob：



A = (g^a) mod p

类似地，Bob 计算他的公钥并将其发送给 Alice：



 B = (g^b) mod p

然后 Alice 将会收到 Bob 的公钥B，而 Bob 将会收到 Alice 的公钥A。

现在奇迹发生了！

Alice 计算：



S = (B^a) mod p

Bob计算：



S = (A^b) mod p

这两个值神奇地等于同一个数字 S。

为什么？我们来算一下：



(B^a) mod p = (g^b)^a mod p = ( g^(b*a) ) mod p
(A^b) mod p = (g^a)^b mod p = ( g^(a*b) ) mod p

因此，Alice 和 Bob 得出了相同的秘密数字 S，但并未将其泄露给公众。

7.3.2 密钥派生函数 - KDF

每种加密算法可能需要不同长度的密钥。因此，为了生成密钥，Alice 和 Bob 必须将 S 放入同一个密钥派生函数 (KDF) 中，最终输出一个所需长度的共享密钥。

在 TLS 1.3 中，我们使用基于 HMAC 的密钥派生函数，因此得名HKDF。

通常，KDF 接受以下输入：

输入密钥材料（或 IKM）。在我们的例子中，IKM 是数字S。
我们希望输出键有多长，例如128-bit。
加密哈希函数，例如HMAC-SHA256。
可选一些上下文或特定于应用程序的信息
可选的盐。

通过所有这些输入，KDF 将生成所需长度的密钥。

7.3.3 陷门函数

现在让我们回到 Diffie-Hellman 密钥交换。

我们知道这些p, g, A, B是众所周知的，这意味着黑客哈利也可以访问这些号码。

我们可能会想：这种密钥交换机制安全吗？或者，给定p, g, A, B，哈利能解出秘密数字吗a, b, S？

幸运的是，如果我们选择好的值，这些函数就会成为陷门p, g, a, b。

例如：

选择p一个2048-bit素数，
选择g作为原根模p，
并选择a, b随机256-bit整数。

陷门函数的基本含义是，它在某种程度上很容易计算，但在另一种情况下却很难计算。例如：

给定p, g, a，就很容易计算A。
但考虑到p, g, A，计算起来非常困难a。

很容易看出，A计算速度相当快，O(log(a))时间复杂度也相当高。这是一个著名的模幂运算问题。

a另一方面，计算则困难得多。这是一个离散对数问题，需要我们当代的计算机花费很长时间才能解决。

因此，至少目前我们是安全的，或者直到下一代强大的量子计算机出现为止。

不过，就目前而言，“需要很长时间才能解决”并不意味着无法解决，对吧？

7.3.4 静态密钥还是临时密钥？

如果 Alice 和 Bob 使用相同的私钥a，并且b对于他们通信的每次会话，那么 Harry 可以记录所有这些会话，并a从会话 1 开始解决问题。

虽然他需要很长时间才能解决，但假设在会话结束后N，他获得了正确的a。现在他可以用它来计算秘密数字S，从而能够解密所有记录的对话。

听起来很可怕吗？我们该如何预防呢？

答案是临时密钥。顾名思义，我们每次会话都会使用不同的私钥。所以，即使 Harry 能解开某个会话的私钥，他也无法在其他会话中使用它。

这在 TLS 中被称为完美前向保密。

现在你明白了 Diffie-Hellman Ephemeral 的含义了。它就是带有短暂密钥的 Diffie-Hellman。

椭圆曲线 Diffie-Hellman Ephemeral 怎么样？

8.椭圆曲线密码学

椭圆曲线密码学（或 ECC）是一种非对称密码学方法，其算法类似，但使用不同的陷门函数。

陷门函数基于椭圆曲线的代数结构，因此得名。

椭圆曲线密码学的一大优势在于：它只需要更小的密钥就能提供同等的安全级别。你可以在这张与 RSA 的对比图中看到这一点。

美国国家安全局（NSA）过去常常使用 ECC 384 位密钥来保护其最高机密，该密钥提供与 RSA-7680 位密钥相同的安全级别。

听起来很神奇，对吧？

然而，椭圆曲线密码体制更容易受到量子计算攻击。Shor算法可以在假想的量子计算机上破解ECC，所需的量子资源比破解RSA所需的资源要少。

强大的量子计算机可能还需要几十年才能真正被制造出来并投入使用。但我们为此做好了什么准备吗？是否存在任何抗量子算法？

是的，有超奇异同源Diffie-Hellman密钥交换算法，它也是基于椭圆曲线密码学的。

但那是另一个故事。

9.非对称加密

现在让我们回到非对称加密！这是一项应用范围广泛的出色技术。

我们已经探索了它的一个应用，即使用 Diffie-Hellman Ephemeral 和 Elliptic-Curve Diffie-Hellman Ephemeral 进行对称密钥交换。

事实上，RSA算法在过去也被用于密钥交换，但由于各种攻击和没有前向保密能力，它在TLS 1.3中被删除了。

非对称加密也用于加密系统中。以下是非对称加密算法：

具有最佳非对称加密填充的 RSA（RSA-OAEP）。
采用公钥加密标准 1 (RSA-PKCS1) 的 RSA，最新版本为 2.2
Elgamal加密算法。

最后，非对称加密的另一个重要特性是数字签名，TLS 广泛使用它进行身份验证。

TLS 中使用的一些流行的数字签名算法是：

具有概率签名方案的 RSA。
椭圆曲线数字签名算法。
Edwards-Curve 数字签名算法。

我们很快就会学习数字签名。但在此之前，我们先来了解一下非对称加密系统的工作原理。

9.1 非对称加密

与对称加密类似，Alice 有一条想要发送给 Bob 的纯文本消息。

但这次没有共享密钥。相反，Alice 用 Bob 的公钥加密消息，并将加密消息发送给 Bob。

当鲍勃收到消息时，他使用他的私钥对其进行解密。

虽然公钥和私钥不同，但它们仍然通过某种陷门函数连接在一起，就像我们在 Diffie-Hellman 算法中看到的那样。

其思想是：密钥成对出现，只有同一对中的私钥才能解密用其公钥加密的消息。

因此，即使黑客 Harry 可以访问 Alice 的加密消息和 Bob 的公钥，他也无法使用该公钥解密消息。

9.2 公钥共享

公钥共享非常简单。Bob 只需通过公共互联网直接将密钥发送给 Alice，而不必担心密钥会被用来解密任何消息。

密钥是公开的，所以任何人都可以使用它来加密只有Bob才能读取的消息，即使他们之前从未通信过。这真是令人难以置信，不是吗？

然而，生活并没有那么容易！

9.3 中间人交换密钥

虽然我们知道Harry无法用Bob的公钥解密消息，但他仍然可以干扰公钥共享，并用自己的公钥替换Bob的公钥。

现在，当 Alice 收到密钥时，她仍然认为这是 Bob 的公钥，但实际上这是 Harry 的。所以，如果 Alice 用这个密钥加密了她的消息，Harry 就能用他的私钥解密。

发生这种情况的原因是，密钥只是一个数字，并且没有身份信息可以告诉我们谁是它的主人。

那么我们能做什么呢？显然，我们应该把密钥和一些身份信息结合起来。而这，无非就是数字证书。

9.4 数字证书

因此，Bob 把他的密钥放在他的证书里，证书上写着他的姓名和其他身份信息。证书就像现实世界中的护照一样。

但是我们怎么知道真正拥有这个证书的确实是Bob呢？怎么才能阻止Harry用Bob的公钥伪造证书呢？

嗯，就像在现实世界中一样，护照必须经过身份验证后由护照颁发机构签发。在数字世界中，证书必须由证书颁发机构验证并签名。

该证书颁发机构和护照颁发机构是值得信赖的第三方，可以帮助我们防止创建伪造的护照和数字证书。

证书签名

证书签名过程如下：

鲍勃有一对公钥和私钥。
第一步，他创建一个证书签名请求（CSR）。该 CSR 包含他的公钥和一些身份信息，例如姓名、组织和电子邮件。
然后第二步，他用自己的私钥签署CSR，并将其发送给证书颁发机构。
证书颁发机构将验证证书中Bob的身份。如有必要，他们可以联系Bob并要求提供更多证明。
然后，他们使用 Bob 证书中的公钥来验证他的签名。这是为了确保 Bob 确实拥有与证书中的公钥配对的私钥。
如果一切有效，CA 将使用自己的私钥签署证书，并将其发送回 Bob。

证书共享

现在 Bob 将与 Alice 共享此包含其公钥的证书，而不是像以前一样只发送公钥。

收到证书后，Alice 可以使用证书颁发机构的公钥轻松验证其真实性。

因此，Harry 无法再用自己的密钥替换 Bob 的公钥，因为他没有 CA 的私钥来签署伪证书。

请注意，这只有在我们都信任证书颁发机构的情况下才有效。如果CA不值得信任，比如他们把私钥给了Harry，那我们就有大麻烦了！

9.5 证书颁发机构——信任链

实际上，存在一个证书颁发机构链。

最顶层是根证书颁发机构，它签署自己的证书，同时也签署下属证书颁发机构（中级证书颁发机构）的证书。

该机构可以签署其他中间机构的证书，或者他们可以签署最终实体证书（或叶证书）。

每个证书都会引用其更高级别颁发机构的证书，直至根证书。

您的操作系统和浏览器会存储受信任的根证书颁发机构的证书列表。这样，它们就可以轻松验证所有证书的真实性。

9.6 数字签名

我们已经讨论了很多有关签署数字签名的内容，那么让我们看看它到底是如何工作的！

签署文件：

签名者首先需要对其进行哈希处理。
然后使用签名者的私钥对哈希值进行加密。
结果将是数字签名。
然后该签名将附加到原始文件上。

签名过程就是这样。现在我们如何验证签名是否有效？

好吧，我们只需做一个相反的过程：

首先，我们从文档中分离签名
使用签名者的公钥对其进行解密，得到哈希值。
然后，我们使用与签名过程中相同的哈希算法对文档进行哈希处理。
结果是另一个哈希值。
然后我们只需比较这两个哈希值。
如果它们相同，则签名有效。

10. TLS 1.3握手协议

好的，现在我们已经掌握了所有知识，让我们仔细看看它们在 TLS 握手协议中是如何使用的。

10.1 完整握手

TLS 1.3 完整握手始于客户端向服务器发送的 hello 消息。实际上，这条消息包含很多内容，这里我仅列出一些重要的信息：

首先，客户端支持的协议版本列表。
然后是受支持的 AEAD 对称密码套件列表。本例中有两个选项：AES-256-GCM 或 CHACHA20-POLY1305
之后，会列出支持的密钥交换组。例如，此客户端同时支持有限域 Diffie-Hellman 临时密钥和椭圆曲线 Diffie-Hellman 临时密钥。
因此，客户端也共享了它的两个公钥：一个用于 Diffie-Hellman 算法，另一个用于椭圆曲线 Diffie-Hellman 算法。这样，无论服务器选择哪种算法，它都能计算出共享密钥。
客户端在此消息中发送的最后一个字段是其支持的签名算法列表。这用于服务器选择使用哪种算法来对整个握手进行签名。我们稍后会了解它的工作原理。

服务器收到客户端的hello消息后，也会发回自己的hello消息，该消息包含：

所选协议版本 TLS 1.3
所选密码套件：AES-256-GCM
所选的密钥交换方法：Diffie-Hellman Ephemeral
以及所选方法的服务器公钥。
下一个字段是客户端证书的请求，它是可选的，只有当服务器想要通过其证书对客户端进行身份验证时才会发送。
通常在 HTTPS 网站上，只有服务器端需要将其证书发送给客户端。该证书将在此消息的下一个字段中发送。

下一个字段是证书验证 (certificate verify)，它实际上是到目前为止整个握手过程的签名。它的生成方式如下：从握手开始到证书请求的整个数据称为握手上下文 (handshake context)。我们将此上下文与服务器的证书连接起来，对其进行哈希处理，然后使用客户端支持的签名算法之一，用服务器的私钥对哈希值进行签名。
类似地，服务器端通过连接握手上下文、证书和证书验证来生成，对其进行哈希处理，然后将哈希值放入所选密码套件的 MAC 算法中。结果即为整个握手的 MAC。

这里，服务器证书、证书验证和服务器完成被称为身份验证消息，因为它们用于对服务器进行身份验证。借助整个握手过程的签名和 MAC，TLS 1.3 可以抵御多种类型的中间人降级攻击。

现在客户端收到服务器的hello消息后，会以root权限验证服务器的证书，并检查整个握手的签名和MAC，确保没有被篡改。

如果一切顺利，则客户端将发送其完成消息，其中包含到目前为止整个握手的 MAC，并且如果服务器请求，还可以选择发送客户端的证书和证书验证。

这就是整个 TLS 握手的整个流程。

10.2 带 PSK 恢复的简短握手

为了提高性能，客户端和服务器并不总是进行完整的握手。有时，它们会使用预共享密钥恢复来执行简短的握手。

其思想是：经过前一次握手之后，客户端和服务器已经相互认识，因此不需要再次进行身份验证。

因此，服务器可能会向客户端发送一个或多个会话票据，这些票据可在下次握手时用作预共享密钥 (PSK) 身份。它附带票据有效期以及其他一些信息。

现在在下一次握手中，客户端将发送一个简单的 hello 消息，其中包含：

从上次握手中获得的 PSK 身份（或票据）列表
PSK 密钥交换模式，可以是仅 PSK，也可以是带有 Diffie-Hellman 的 PSK。
如果使用 Diffie-Hellman 模式的 PSK，则客户端还需要共享其 Diffie-Hellman 公钥。这将提供完美的前向保密性，并允许服务器在需要时回退到完全握手。

当服务器收到此客户端 hello 消息时，它会发回以下 hello 消息：

选定的预共享密钥身份
服务器的可选 Diffie-Hellman 公钥
服务器就像完整的握手一样完成。

最后，客户端发回其完成，这就是 PSK 恢复的结束。

如您所见，在此简短握手中客户端和服务器之间没有证书认证。

这也为零往返时间（0-RTT）数据提供了机会，这意味着客户端无需等待握手完成即可将其第一个应用程序数据发送到服务器。

10.3 0-RTT握手

在 0-RTT 中，客户端会将应用程序数据与客户端 hello 消息一起发送。该数据使用从票证列表中第一个 PSK 派生的密钥进行加密。

它还增加了 1 个字段：早期数据指示，以告知服务器正在发送早期应用数据。

如果服务器接受此 0-RTT 请求，它将像在正常 PSK 恢复中一样发回服务器 hello，并且还可以选择发回一些应用程序数据。

客户端将以包含 MAC 和早期数据结束指示符的消息结束。这就是 TLS 1.3 中 0 往返时间的工作原理。

它的优点是将延迟减少一个往返时间。但缺点是存在潜在的重放攻击威胁。这意味着黑客可以复制并多次向服务器发送相同的加密 0-RTT 请求。为了避免这种情况，服务器应用程序必须以能够抵御重复请求的方式实现。

11. 比较 TLS 1.3 与 TLS 1.2

现在，在我们结束之前，让我们快速比较一下 TLS 1.3 和 TLS 1.2，看看有什么新内容！

TLS 1.3 具有更安全的密钥交换机制，其中易受攻击的 RSA 和其他静态密钥交换方法被删除，只留下短暂的 Diffie-Hellman 或椭圆曲线 Diffie-Hellman，从而实现了完美的前向保密性。
TLS 1.3 握手比 TLS 1.2 至少快 1 个往返。
TLS 1.3 中的对称加密更安全，因为 AEAD 密码套件是强制性的，并且它还从列表中删除了一些弱算法，例如分组密码模式 (CBC)、RC4 或三重 DES。
TLS 1.3 中的密码套件也更简单，因为它只包含 AEAD 算法和一个哈希算法。密钥交换算法和签名算法被移到了单独的字段中。而在 TLS 1.2 中，它们被合并到了密码套件中。这使得推荐的密码套件数量变得过多，如果我没记错的话，TLS 1.2 中有 37 个选项。而在 TLS 1.3 中只有 5 个。
其次，TLS 1.3 还为我们提供了更强大的签名，因为它对整个握手进行签名，而不仅仅是像 TLS 1.2 那样覆盖其中的某些部分。
最后但同样重要的一点是，椭圆曲线密码算法在 TLS 1.3 中得到了极大的关注，并添加了一些更好的曲线算法，例如 Edward 曲线数字签名算法，它在不牺牲安全性的情况下速度更快。

这就是我想在这篇文章里和大家分享的全部内容。感谢阅读，下篇文章再见！

如果您喜欢这篇文章，请订阅我们的 Youtube 频道并在 Twitter 上关注我们，以便将来获取更多教程。

如果你想加入我目前在 Voodoo 的优秀团队，请查看我们的职位空缺。你可以远程办公，也可以在巴黎/阿姆斯特丹/伦敦/柏林/巴塞罗那现场办公，但需获得签证担保。

文章来源：https://dev.to/techschoolguru/a-complete-overview-of-ssl-tls-and-its-cryptographic-system-36pd