关于加密，我应该知道什么

 您可能听说过加密这个术语在不同的上下文中使用，并与不同的单词相关联。通常，加密是指使消息不可读的数学过程，只有拥有将其解密为可读形式的密钥的人才能读懂。

纵观历史，人们一直使用加密技术相互发送消息，(希望)除了预期的接收者以外，任何人都无法读取这些消息。今天，我们拥有能够为我们执行加密的计算机。数字加密技术已经超越了简单的秘密信息;现在，今天，您可以将加密用于更复杂的目的，例如，验证消息的作者。

加密是我们保护信息免受不良行为者、政府和服务提供商攻击的最佳技术，并且它已经发展到在正确使用时几乎不可能破解。

在本指南中，我们将了解应用加密的两种主要方式:对静态数据和传输中的数据进行加密。

加密静态数据

静止数据是存储在某处的数据:例如移动设备、笔记本电脑、服务器或外部硬盘驱动器上。当数据处于静止状态时，它不会从一个地方移动到另一个地方。

保护静止数据的一种加密形式是全磁盘加密(有时也称为设备加密)。启用全磁盘加密对存储在设备上的所有信息进行加密，并使用密码或另一种身份验证方法保护信息。在移动设备或笔记本电脑上，这通常看起来就像典型的设备锁定屏幕，需要密码、密码或指纹。然而，锁定你的设备(例如:(需要密码才能解锁设备)并不总是意味着启用了全磁盘加密。

智能手机和笔记本电脑都有密码保护的“锁定”屏幕。

请务必检查操作系统如何启用和管理全盘加密。 虽然某些操作系统默认启用了全盘加密，但某些操作系统却没有。 这意味着有人可以通过断开设备锁来访问移动设备上的数据，但不必破坏加密密钥，因为设备本身未加密。 即使使用全盘加密，某些系统仍会在RAM上存储未加密的明文。 RAM是临时存储，这意味着在设备断电后不久，内存通常无法读取，但是复杂的攻击者可能会尝试冷启动攻击并有可能会检索RAM内容。

全磁盘加密可以保护您的设备不受物理访问它们的人的攻击。如果您希望保护您的数据不受室友、同事或雇主、学校官员、家庭成员、合作伙伴、警察或其他执法人员的攻击，那么这是非常有用的。如果你的手机被盗或丢失，比如你不小心把手机落在公共汽车上或餐馆里，它还能保护你手机上的数据。

还有其他方法可以在静止状态下加密数据。一种称为文件加密的选项只加密计算机或其他存储设备上特定的单个文件。另一种选择是驱动器加密(也称为磁盘加密):对设备上特定存储区域上的所有数据进行加密。

您可以组合使用这些不同类型的加密。例如，假设您希望保护医疗文档上的敏感信息。您可以使用文件加密来分别加密存储在您的设备上的单个医疗文件。然后，您可以使用驱动器加密来加密存储此医疗信息的设备部分。最后，如果您在设备上启用了全磁盘加密，那么驱动器上的所有医疗信息以及其他文件(包括计算机操作系统的文件)都将被加密。

加密传输中的数据

此图显示传输中的未加密数据，这通常是Internet服务提供商的默认设置。在左边，一部智能手机向另一部最右边的智能手机发送一条绿色的未加密信息。在这一过程中，一个手机信号塔将信息传递给公司的服务器，然后再传递给另一个手机信号塔，每个塔都能看到未加密的Hello信息。所有传递未加密消息的计算机和网络都能看到该消息。最后，另一台智能手机接收未加密的Hello消息

传输中的数据是指在网络中从一个地方移动到另一个地方的信息。例如，当你在一个消息传递应用程序上发送一条消息时，该消息从你的设备移动到应用程序公司的服务器，再移动到收件人的设备。另一个例子是网页浏览:当你访问一个网站时，网页上的数据从网站服务器传到你的浏览器。

一些流行的应用程序提供了一些似乎可以保护信息的功能，比如撤回消息。然而，仅仅因为交流(如聊天或消息)感觉安全，并不意味着它实际上是安全的。传递您的消息的计算机可能能够查看您的消息的内容。

重要的是要验证您和收件人之间的对话是否加密，并了解它们是通过传输层加密还是端到端加密加密的。

有两种方法可以加密传输中的数据：传输层加密和端到端加密。 服务提供商支持的加密类型可能是决定哪些服务适合您的重要因素。 以下示例说明了传输层加密和端到端加密之间的差异。

传输层加密

图中显示了传输层加密。在左边，智能手机会发送一条绿色的未加密信息:你好。这条信息被加密，然后传送到一个手机信号塔。在中间，公司的服务器能够解密信息，重新加密，并将其发送到下一个手机信号塔。最后，另一台智能手机接收到加密的消息，解密后读取Hello。

传输层加密，也称为传输层安全性(transport layer security, TLS)，保护消息从您的设备到应用程序服务器以及从应用程序服务器到您的收件人设备的传输过程。在中间，您的消息服务提供商或您正在浏览的网站，或您正在使用的应用程序可以看到您的消息的未加密副本。由于您的消息可以被公司服务器看到(通常存储在)，因此如果公司的服务器受到攻击，它们可能很容易受到执法请求或泄漏的影响。

传输层加密示例: HTTPS

您是否注意到浏览器窗口的Web地址部分中ssd.eff.org的Web地址旁边的绿色锁和“https://”？ HTTPS是我们在Web上经常遇到的传输层加密的示例。 它提供比未加密的HTTP更高的安全性。 为什么？ 由于您正在浏览的HTTPS网站的服务器可以看到您在其网站上输入的数据（例如，消息，搜索，信用卡号和登录），但是此信息对于网络上的窃听者来说是不可读的。

如果有人在监视网络并试图查看用户正在访问的网站，则HTTP连接不提供保护。 另一方面，HTTPS连接会隐藏您导航到的网站上的特定页面 - 即“斜杠后”的所有内容。例如，如果您使用HTTPS连接到“https://ssd.eff.org/en/module/what-encryption“窃听者只能看到”https://ssd.eff.org“。

网络趋势正处于向所有网页使用HTTPS的大转变中。 这是因为HTTP缺乏任何有意义的安全性，默认情况下HTTPS是安全的。 通过HTTP访问您的网页容易受到窃听，内容注入，cookie窃取，登录和密码窃取，有针对性的审查以及其他问题的影响。

我们建议使用EFF的浏览器扩展HTTPS Everywhere来获得HTTPS最大程度的保护。HTTPS Everywhere确保，如果我们所知道的网站提供HTTPS和HTTP，您将始终使用安全的HTTPS版本的网站。

传输层加密示例: VPN

VPN：虚拟专用网络是一种将计算机安全地连接到Internet另一端组织网络的方法。 当您使用VPN时，您的所有计算机的Internet通信都打包在一起，加密，然后中继到其他组织，在那里它们被解密，解压缩，然后发送到目的地。 对于组织的网络或更广泛的Internet上的任何其他计算机，您的计算机的请求似乎来自组织内部，而不是来自您的位置。

企业使用VPN来提供对内部资源（如文件服务器或打印机）的安全访问。 它们也被个人用来绕过当地的审查，或者反抗当地的监视。

虚拟专用网络（VPN）是传输层加密的另一个示例。 如果没有VPN，您的流量将通过Internet服务提供商（ISP）的连接传输。 使用VPN，您的流量仍然通过ISP的连接传输，但它将在您和您的VPN提供商之间进行加密。 如果有人在您的本地网络上监视并试图查看您正在访问的网站，他们将能够看到您已连接到VPN，但无法查看您最终访问的网站。ISP可以检测您的VPN提供商是谁。

端到端加密

该图显示端到端加密。在左边，智能手机会发送一条绿色的未加密信息:你好。这条信息被加密，然后传送到手机发射塔和公司服务器。最后，另一台智能手机接收到加密的消息，解密后读取Hello。与传输层加密不同，ISP服务器无法解密消息;只有端点(发送和接收加密消息的原始设备)具有解密消息的密钥。

端到端加密保护从发送方到接收方的传输中的消息。它确保信息由原始发送方(第一端)转换为秘密消息，仅由最终接收方(第一端)解码。没有人，包括你正在使用的应用程序，可以监听和窃听你的活动。

访问设备上应用程序中的端到端加密消息实际上意味着应用程序公司本身无法读取这些消息。这是良好加密的核心特征：即使是设计和部署它的人也不能自己破解它。

在监控自卫方面，我们在“与他人沟通”指南中提供了使用端到端加密工具的指南。

传输层加密或端到端加密

在决定是否需要传输层加密或端到端加密时，需要问的重要问题是:您信任所使用的应用程序或服务吗?你信任它的技术基础设施吗?它保护公民不受执法要求侵害的政策如何？

如果对这些问题中的任何一个回答“否”，那么您需要端到端加密。 如果您对它们回答“是”，那么仅支持传输层加密的服务可能就足够了 - 但通常最好使用支持端到端加密的服务。

我们创建了下面的动画来演示端到端加密和传输层加密是如何对传输中的数据进行加密的。左边是端到端加密聊天工具(一个使用非记录(OTR)即时消息加密协议的聊天框)。右边是一个传输层加密聊天框(通过使用HTTPS的谷歌Hangouts网站加密)。

在GIF中，主要用户在谷歌Hangouts聊天框中键入一条消息：

“嗨！这不是端到端加密的。谷歌可以看到我们的对话。”

此用户还打开了一个Off-the-Record（OTR）聊天框，并启用“私人对话”设置。 在OTR聊天框中，描述性文字说：

“尝试与[gmail帐户]开始私密对话。 已开始与[gmail帐户]进行私密对话。 但是，他们的身份尚未得到证实。“

同时，在Google Hangouts聊天框中，正在交换乱码密文，表明用户现在使用的是非记录( OTR )端到端加密协议。 通过OTR聊天框传递的每条消息也会显示在Google环聊聊天框中，但是，它不是可读的，而是显示为乱码。 另一个用户在OTR客户端中键入消息：

1 2 3 4 5 6 7

“对任何人来说，这看起来都是胡言乱语。” 主要用户写道： “是的，这看起来像胡说八道。” 另一个用户发送一个笑脸表情符号。

传输中的加密不能做什么

加密不是万能的。即使您正在发送加密消息，与您通信的人也会解密该消息。如果您的端点(用于通信的设备)受到危害，您的加密通信可能会受到危害。此外，与你交流的人可以截图或保存你交流的记录(日志)。

如果您自动将加密对话的备份存储到“云”（其他计算机），请注意检查备份是否也已加密。 这可确保您的会话不仅在传输过程中加密，而且还在静止时加密。

如果您加密传输中的数据，它将保护通信内容，但不会加密元数据。例如，您可以使用加密将您和您的朋友之间的消息打乱成乱码，但它不会隐藏。

• 你和你的朋友正在沟通
• 您正在使用加密进行通信。
• 有关您的沟通的其他类型的信息，例如通信的位置，时间和长短。

高度关注监控的人(比如那些担心自己的网络受到主动监控的人)可能会因为只在敏感时期或特定活动中使用加密而处于危险之中。为什么?如果您只是偶尔使用加密，它可以将元数据绑定到重要的日期和时间。因此，尽可能多地使用加密，即使是普通的活动。

此外，如果您是网络上唯一使用加密的人，则此元数据可能会被视为可疑的。这就是为什么许多加密爱好者鼓励每个人只要有能力就使用加密工具:为真正需要加密的人规范加密的使用。

把它们放在一起

总的来说，对传输中的和静止中的数据进行加密将比只使用其中一个提供更全面的安全性。这就是信息安全专家所说的深度防御。通过使用多种方法来保护数据，可以实现更深层次的保护。

例如，如果您从加密的移动设备发送未加密的消息(不加密传输中的数据)(加密您静止的数据)，这些消息仍然很容易受到来自政府、服务提供商或技术熟练的对手的网络窃听和截取。但是，如果没有密码，您的移动设备上的消息记录将受到保护，使物理访问您的移动设备的人无法访问。

相反，如果您在未加密的设备上发送端到端加密消息（加密传输中的数据）（不加密静止的数据），那么这些消息将无法在网络上窥探和窃听。 但是，如果有人可以访问您的移动设备，他们将能够访问和阅读这些消息。

考虑到这些示例，在网络传输过程中加密数据以及在设备上静态加密数据时，非常适合保护自己免受更广泛的潜在风险。

翻译自：https://ssd.eff.org/en/module/what-should-i-know-about-encryption

----------------------------------------------------------------------------------------------

HTTPS如何优化？

由裸数据传输的 HTTP 协议转成加密数据传输的 HTTPS 协议，给应用数据套了个「保护伞」，提高安全性的同时也带来了性能消耗。

因为 HTTPS 相比 HTTP 协议多一个 TLS 协议握手过程，目的是为了通过非对称加密握手协商或者交换出对称加密密钥，这个过程最长可以花费掉 2 RTT，接着后续传输的应用数据都得使用对称加密密钥来加密/解密。

为了数据的安全性，我们不得不使用 HTTPS 协议，至今大部分网址都已从 HTTP 迁移至 HTTPS 协议，因此针对 HTTPS 的优化是非常重要的。

这次，就从多个角度来优化 HTTPS。

---

分析性能损耗

既然要对 HTTPS 优化，那得清楚哪些步骤会产生性能消耗，再对症下药。

产生性能消耗的两个环节：

• 第一个环节， TLS 协议握手过程；
• 第二个环节，握手后的对称加密报文传输。

对于第二环节，现在主流的对称加密算法 AES、ChaCha20 性能都是不错的，而且一些 CPU 厂商还针对它们做了硬件级别的优化，因此这个环节的性能消耗可以说非常地小。

而第一个环节，TLS 协议握手过程不仅增加了网络延时（最长可以花费掉 2 RTT），而且握手过程中的一些步骤也会产生性能损耗，比如：

• 对于 ECDHE 密钥协商算法，握手过程中会客户端和服务端都需要临时生成椭圆曲线公私钥；
• 客户端验证证书时，会访问 CA 获取 CRL 或者 OCSP，目的是验证服务器的证书是否有被吊销；
• 双方计算 Pre-Master，也就是会话密钥；

为了大家更清楚这些步骤在 TLS 协议握手的哪一个阶段，我画出了这幅图：

---

硬件优化

玩游戏时，如果我们怎么都战胜不了对方，那么有一个最有效、最快的方式来变强，那就是「充钱」，如果还是不行，那说明你充的钱还不够多。

对于计算机里也是一样，软件都是跑在物理硬件上，硬件越牛逼，软件跑的也越快，所以如果要优化 HTTPS 优化，最直接的方式就是花钱买性能参数更牛逼的硬件。

但是花钱也要花对方向，HTTPS 协议是计算密集型，而不是 I/O 密集型，所以不能把钱花在网卡、硬盘等地方，应该花在 CPU 上。

一个好的 CPU，可以提高计算性能，因为 HTTPS 连接过程中就有大量需要计算密钥的过程，所以这样可以加速 TLS 握手过程。

另外，如果可以，应该选择可以支持 AES-NI 特性的 CPU，因为这种款式的 CPU 能在指令级别优化了 AES 算法，这样便加速了数据的加解密传输过程。

如果你的服务器是 Linux 系统，那么你可以使用下面这行命令查看 CPU 是否支持 AES-NI 指令集：

如果我们的 CPU 支持 AES-NI 特性，那么对于对称加密的算法应该选择 AES 算法。否则可以选择 ChaCha20 对称加密算法，因为 ChaCha20 算法的运算指令相比 AES 算法会对 CPU 更友好一点。

---

软件优化

如果公司预算充足对于新的服务器是可以考虑购买更好的 CPU，但是对于已经在使用的服务器，硬件优化的方式可能就不太适合了，于是就要从软件的方向来优化了。

软件的优化方向可以分层两种，一个是软件升级，一个是协议优化。

先说第一个软件升级，软件升级就是将正在使用的软件升级到最新版本，因为最新版本不仅提供了最新的特性，也优化了以前软件的问题或性能。比如：

• 将 Linux 内核从 2.x 升级到 4.x；
• 将 OpenSSL 从 1.0.1 升级到 1.1.1；
• …

看似简单的软件升级，对于有成百上千服务器的公司来说，软件升级也跟硬件升级同样是一个棘手的问题，因为要实行软件升级，会花费时间和人力，同时也存在一定的风险，也可能会影响正常的线上服务。

既然如此，我们把目光放到协议优化，也就是在现有的环节下，通过较小的改动，来进行优化。

---

协议优化

协议的优化就是对「密钥交换过程」进行优化。

密钥交换算法优化

TLS 1.2 版本如果使用的是 RSA 密钥交换算法，那么需要 4 次握手，也就是要花费 2 RTT，才可以进行应用数据的传输，而且 RSA 密钥交换算法不具备前向安全性。

总之使用 RSA 密钥交换算法的 TLS 握手过程，不仅慢，而且安全性也不高。

因此如果可以，尽量选用 ECDHE 密钥交换算法替换 RSA 算法，因为该算法由于支持「False Start」，它是“抢跑”的意思，客户端可以在 TLS 协议的第 3 次握手后，第 4 次握手前，发送加密的应用数据，以此将 TLS 握手的消息往返由 2 RTT 减少到 1 RTT，而且安全性也高，具备前向安全性。

ECDHE 算法是基于椭圆曲线实现的，不同的椭圆曲线性能也不同，应该尽量选择 x25519 曲线，该曲线是目前最快的椭圆曲线。

比如在 Nginx 上，可以使用 ssl_ecdh_curve 指令配置想使用的椭圆曲线，把优先使用的放在前面：

对于对称加密算法方面，如果对安全性不是特别高的要求，可以选用 AES_128_GCM，它比 AES_256_GCM 快一些，因为密钥的长度短一些。

比如在 Nginx 上，可以使用 ssl_ciphers 指令配置想使用的非对称加密算法和对称加密算法，也就是密钥套件，而且把性能最快最安全的算法放在最前面：

TLS 升级

当然，如果可以，直接把 TLS 1.2 升级成 TLS 1.3，TLS 1.3 大幅度简化了握手的步骤，完成 TLS 握手只要 1 RTT，而且安全性更高。

在 TLS 1.2 的握手中，一般是需要 4 次握手，先要通过 Client Hello （第 1 次握手）和 Server Hello（第 2 次握手） 消息协商出后续使用的加密算法，再互相交换公钥（第 3 和 第 4 次握手），然后计算出最终的会话密钥，下图的左边部分就是 TLS 1.2 的握手过程：

上图的右边部分就是 TLS 1.3 的握手过程，可以发现 TLS 1.3 把 Hello 和公钥交换这两个消息合并成了一个消息，于是这样就减少到只需 1 RTT 就能完成 TLS 握手。

怎么合并的呢？具体的做法是，客户端在 Client Hello 消息里带上了支持的椭圆曲线，以及这些椭圆曲线对应的公钥。

服务端收到后，选定一个椭圆曲线等参数，然后返回消息时，带上服务端这边的公钥。经过这 1 个 RTT，双方手上已经有生成会话密钥的材料了，于是客户端计算出会话密钥，就可以进行应用数据的加密传输了。

而且，TLS1.3 对密码套件进行“减肥”了，对于密钥交换算法，废除了不支持前向安全性的 RSA 和 DH 算法，只支持 ECDHE 算法。

对于对称加密和签名算法，只支持目前最安全的几个密码套件，比如 openssl 中仅支持下面 5 种密码套件：

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM_8_SHA256
• TLS_AES_128_CCM_SHA256

之所以 TLS1.3 仅支持这么少的密码套件，是因为 TLS1.2 由于支持各种古老且不安全的密码套件，中间人可以利用降级攻击，伪造客户端的 Client Hello 消息，替换客户端支持的密码套件为一些不安全的密码套件，使得服务器被迫使用这个密码套件进行 HTTPS 连接，从而破解密文。

---

证书优化

为了验证的服务器的身份，服务器会在 TSL 握手过程中，把自己的证书发给客户端，以此证明自己身份是可信的。

对于证书的优化，可以有两个方向：

• 一个是证书传输，
• 一个是证书验证；

证书传输优化

要让证书更便于传输，那必然是减少证书的大小，这样可以节约带宽，也能减少客户端的运算量。所以，对于服务器的证书应该选择 椭圆曲线（ECDSA）证书，而不是 RSA 证书，因为在相同安全强度下， ECC 密钥长度比 RSA 短的多。 

证书验证优化

客户端在验证证书时，是个复杂的过程，会走证书链逐级验证，验证的过程不仅需要「用 CA 公钥解密证书」以及「用签名算法验证证书的完整性」，而且为了知道证书是否被 CA 吊销，客户端有时还会再去访问 CA， 下载 CRL 或者 OCSP 数据，以此确认证书的有效性。

这个访问过程是 HTTP 访问，因此又会产生一系列网络通信的开销，如 DNS 查询、建立连接、收发数据等。

CRL

CRL 称为证书吊销列表（Certificate Revocation List），这个列表是由 CA 定期更新，列表内容都是被撤销信任的证书序号，如果服务器的证书在此列表，就认为证书已经失效，不在的话，则认为证书是有效的。

但是 CRL 存在两个问题：

• 第一个问题，由于 CRL 列表是由 CA 维护的，定期更新，如果一个证书刚被吊销后，客户端在更新 CRL 之前还是会信任这个证书，实时性较差；
• 第二个问题，随着吊销证书的增多，列表会越来越大，下载的速度就会越慢，下载完客户端还得遍历这么大的列表，那么就会导致客户端在校验证书这一环节的延时很大，进而拖慢了 HTTPS 连接。

OCSP

因此，现在基本都是使用 OCSP ，名为在线证书状态协议（Online Certificate Status Protocol）来查询证书的有效性，它的工作方式是向 CA 发送查询请求，让 CA 返回证书的有效状态。

不必像 CRL 方式客户端需要下载大大的列表，还要从列表查询，同时因为可以实时查询每一张证书的有效性，解决了 CRL 的实时性问题。

OCSP 需要向 CA 查询，因此也是要发生网络请求，而且还得看 CA 服务器的“脸色”，如果网络状态不好，或者 CA 服务器繁忙，也会导致客户端在校验证书这一环节的延时变大。

OCSP Stapling

于是为了解决这一个网络开销，就出现了 OCSP Stapling，其原理是：服务器向 CA 周期性地查询证书状态，获得一个带有时间戳和签名的响应结果并缓存它。

当有客户端发起连接请求时，服务器会把这个「响应结果」在 TLS 握手过程中发给客户端。由于有签名的存在，服务器无法篡改，因此客户端就能得知证书是否已被吊销了，这样客户端就不需要再去查询。

---

会话复用

TLS 握手的目的就是为了协商出会话密钥，也就是对称加密密钥，那我们如果我们把首次 TLS 握手协商的对称加密密钥缓存起来，待下次需要建立 HTTPS 连接时，直接「复用」这个密钥，不就减少 TLS 握手的性能损耗了吗？

这种方式就是会话复用（TLS session resumption），会话复用分两种：

• 第一种叫 Session ID；
• 第二种叫 Session Ticket；

Session ID

Session ID 的工作原理是，客户端和服务器首次 TLS 握手连接后，双方会在内存缓存会话密钥，并用唯一的 Session ID 来标识，Session ID 和会话密钥相当于 key-value 的关系。

当客户端再次连接时，hello 消息里会带上 Session ID，服务器收到后就会从内存找，如果找到就直接用该会话密钥恢复会话状态，跳过其余的过程，只用一个消息往返就可以建立安全通信。当然为了安全性，内存中的会话密钥会定期失效。

但是它有两个缺点：

• 服务器必须保持每一个客户端的会话密钥，随着客户端的增多，服务器的内存压力也会越大。
• 现在网站服务一般是由多台服务器通过负载均衡提供服务的，客户端再次连接不一定会命中上次访问过的服务器，于是还要走完整的 TLS 握手过程；

Session Ticket

为了解决 Session ID 的问题，就出现了 Session Ticket，服务器不再缓存每个客户端的会话密钥，而是把缓存的工作交给了客户端，类似于 HTTP 的 Cookie。

客户端与服务器首次建立连接时，服务器会加密「会话密钥」作为 Ticket 发给客户端，交给客户端缓存该 Ticket。

客户端再次连接服务器时，客户端会发送 Ticket，服务器解密后就可以获取上一次的会话密钥，然后验证有效期，如果没问题，就可以恢复会话了，开始加密通信。

对于集群服务器的话，要确保每台服务器加密 「会话密钥」的密钥是一致的，这样客户端携带 Ticket 访问任意一台服务器时，都能恢复会话。

Session ID 和 Session Ticket 都不具备前向安全性，因为一旦加密「会话密钥」的密钥被破解或者服务器泄漏「会话密钥」，前面劫持的通信密文都会被破解。

同时应对重放攻击也很困难，这里简单介绍下重放攻击工作的原理。

假设 Alice 想向 Bob 证明自己的身份。Bob 要求 Alice 的密码作为身份证明，爱丽丝应尽全力提供（可能是在经过如哈希函数的转换之后）。与此同时，Eve 窃听了对话并保留了密码（或哈希）。

交换结束后，Eve（冒充 Alice ）连接到 Bob。当被要求提供身份证明时，Eve 发送从 Bob 接受的最后一个会话中读取的 Alice 的密码（或哈希），从而授予 Eve 访问权限。

重放攻击的危险之处在于，如果中间人截获了某个客户端的 Session ID 或 Session Ticket 以及 POST 报文，而一般 POST 请求会改变数据库的数据，中间人就可以利用此截获的报文，不断向服务器发送该报文，这样就会导致数据库的数据被中间人改变了，而客户是不知情的。

避免重放攻击的方式就是需要对会话密钥设定一个合理的过期时间。

Pre-shared Key

前面的 Session ID 和 Session Ticket 方式都需要在 1 RTT 才能恢复会话。

而 TLS1.3 更为牛逼，对于重连 TLS1.3 只需要 0 RTT，原理和 Ticket 类似，只不过在重连时，客户端会把 Ticket 和 HTTP 请求一同发送给服务端，这种方式叫 Pre-shared Key。

同样的，Pre-shared Key 也有重放攻击的危险。

如上图，假设中间人通过某种方式，截获了客户端使用会话重用技术的 POST 请求，通常 POST 请求是会改变数据库的数据，然后中间人就可以把截获的这个报文发送给服务器，服务器收到后，也认为是合法的，于是就恢复会话，致使数据库的数据又被更改，但是此时用户是不知情的。

所以，应对重放攻击可以给会话密钥设定一个合理的过期时间，以及只针对安全的 HTTP 请求如 GET/HEAD 使用会话重用。

---

总结

对于硬件优化的方向，因为 HTTPS 是属于计算密集型，应该选择计算力更强的 CPU，而且最好选择支持 AES-NI 特性的 CPU，这个特性可以在硬件级别优化 AES 对称加密算法，加快应用数据的加解密。

对于软件优化的方向，如果可以，把软件升级成较新的版本，比如将 Linux 内核 2.X 升级成 4.X，将 openssl 1.0.1 升级到 1.1.1，因为新版本的软件不仅会提供新的特性，而且还会修复老版本的问题。

对于协议优化的方向：

• 密钥交换算法应该选择 ECDHE 算法，而不用 RSA 算法，因为 ECDHE 算法具备前向安全性，而且客户端可以在第三次握手之后，就发送加密应用数据，节省了 1 RTT。
• 将 TSL1.2 升级 TSL1.3，因为 TSL1.3 的握手过程只需要 1 RTT，而且安全性更强。

对于证书优化的方向：

• 服务器应该选用 ECDSA 证书，而非 RSA 证书，因为在相同安全级别下，ECC 的密钥长度比 RSA 短很多，这样可以提高证书传输的效率；
• 服务器应该开启 OCSP Stapling 功能，由服务器预先获得 OCSP 的响应，并把响应结果缓存起来，这样 TLS 握手的时候就不用再访问 CA 服务器，减少了网络通信的开销，提高了证书验证的效率；

对于重连 HTTPS 时，我们可以使用一些技术让客户端和服务端使用上一次 HTTPS 连接使用的会话密钥，直接恢复会话，而不用再重新走完整的 TLS 握手过程。

常见的会话重用技术有 Session ID 和 Session Ticket，用了会话重用技术，当再次重连 HTTPS 时，只需要 1 RTT 就可以恢复会话。对于 TLS1.3 使用 Pre-shared Key 会话重用技术，只需要 0 RTT 就可以恢复会话。

这些会话重用技术虽然好用，但是存在一定的安全风险，它们不仅不具备前向安全，而且有重放攻击的风险，所以应当对会话密钥设定一个合理的过期时间。

巨人的肩膀

1. http://www.doc88.com/p-8621583210895.html
2. https://zhuanlan.zhihu.com/p/33685085
3. https://en.wikipedia.org/wiki/Replay_attack
4. https://en.wikipedia.org/wiki/Downgrade_attack
5. https://www.cnblogs.com/racent-Z/p/14011056.html
6. http://www.guoyanbin.com/a-detailed-look-at-rfc-8446-a-k-a-tls-1-3/
7. https://www.thesslstore.com/blog/crl-explained-what-is-a-certificate-revocation-list/
    
   from  https://archive.is/NrUMW#selection-305.0-1289.85
   https://mp.weixin.qq.com/s/n4aoOBfJDeyJebQ6b9raUg