TLS 1.3 比 TLS 1.2对比有什么区别吗？
传输层安全 (TLS) 协议 1.3 版正式获批。TLS 是互联网安全的支柱，保护从网络流量到加密电子邮件的一切。1.3 版通过简化连接过程和删除旧的、不安全的加密方法，对以前的版本进行了改进。TLS 1.3 在安全性、性能和简洁性方面都对TLS 1.2进行了显著改进。它消除了不安全的加密算法，减少了握手延迟，并默认启用了前向安全性，使其成为一个更为安全和高效的协议。对于需要保护敏感数据的网站和服务，TLS 1.3 是更好的选择。
TLS（传输层安全协议）是用于确保互联网通信安全的协议，主要用于加密数据传输。TLS 1.3 是 TLS 1.2 的更新版本，带来了一些显著的改进。以下是 TLS 1.3 与 TLS 1.2 的主要区别：
1. 握手过程的简化
- TLS 1.2: 握手过程较为复杂，通常需要两次往返（两轮数据交换）才能完成连接建立。这导致初始连接时间较长。
- TLS 1.3: 握手过程得到了显著简化，仅需要一次往返（一次数据交换）即可完成握手，减少了延迟，提高了连接速度。
2. 加密算法的改进
- TLS 1.2: 支持多种加密算法，包括一些不再安全的算法，如RC4、MD5和SHA-1。这些算法容易受到攻击，存在安全隐患。
- TLS 1.3: 移除了不安全的加密算法，只保留了现代、强大的加密算法，如AES-GCM、ChaCha20-Poly1305。这使得TLS 1.3更加安全，抵御已知的密码攻击。
3. 前向安全性
- TLS 1.2: 前向安全性依赖于特定的密钥交换算法，如Diffie-Hellman，但不是默认启用。这意味着，如果密钥被泄露，过去的通信可能被解密。
- TLS 1.3: 默认启用了前向安全性（Forward Secrecy），即使长期密钥泄露，也无法解密之前的通信数据，从而提升了整体安全性。
4. 零知识证明
- TLS 1.2: 使用RSA算法时，握手阶段传输的加密信息可能被拦截并用于未来解密数据。
- TLS 1.3: 完全移除了RSA密钥交换，采用基于DH（Diffie-Hellman）的密钥交换方式，这种方式支持零知识证明，进一步增强了安全性。
5. 会话恢复
- TLS 1.2: 使用会话ID或会话票据来恢复会话，但这些方法有时可能会带来安全问题。
- TLS 1.3: 引入了改进的会话恢复机制，称为“0-RTT”，允许会话恢复时无需额外的握手过程，从而显著减少延迟。然而，0-RTT也带来了一些潜在的重放攻击风险，需要谨慎使用。
6. 协议扩展
- TLS 1.2: 对扩展的支持有限，且有些扩展可能增加复杂性和潜在安全风险。
- TLS 1.3: 提供了更灵活和安全的扩展机制，简化了协议设计，使得协议本身更加简洁且易于实施。
TLS 1.3 提供什么？
与前一版本 (TLS 1.2) 相比，主要改进是初始连接速度更快。当使用 TLS 连接到服务器时，首先必须交换用于加密未来消息的加密密钥并协商使用哪种加密协议。此过程称为握手。在 TLS 1.2 中，握手需要向服务器发送两条往返消息：一条用于启动连接，一条用于建立加密会话。使用 TLS 1.3，客户端在其第一条消息中包含服务器创建加密会话所需的数据。这使服务器只需一步即可创建加密会话。这也有助于防止诸如POODLE之类的攻击，恶意攻击者可能会强迫您的浏览器协商使用安全性较低的协议，例如 SSL 3.0。
TLS 1.2 握手
由 Fleshgrinder 和 Tango! Desktop Project 的人员撰写。[公共领域]，来自Wikimedia Commons
由 Fleshgrinder 和 Tango! Desktop Project 的人员撰写。[公共领域]，来自Wikimedia Commons
TLS 1.3 握手
TLS 1.3 还添加了零往返时间恢复（0-RTT）。借助 0-RTT，服务器可以记住最近连接的客户端。下次这些客户端连接到服务器时，它们可以立即开始发送数据，而无需执行握手。在一些测试中，0-RTT 将连接速度提高了 34%。
为什么 TLS 1.3 没有得到更广泛的应用？
TLS 1.3 与 1.2 相比有显著变化。因此，它破坏了与某些旨在拦截或监控 TLS 加密消息的中间件的兼容性。许多中间件在创建时都假设 TLS 协议会随时间发生变化，因此当后续版本打破这些假设时，会导致连接失败。
2017 年初， Chrome 和 Firefox 团队在各自的浏览器中测试 TLS 1.3时发现，他们分别只能在 92.3% 和 96.1% 的时间内连接到网站。为了解决这个问题，OpenSSL 等库添加了兼容模式，将 TLS 1.3 流量修改为看起来像 TLS 1.2 流量。虽然这将成功率提高到 98.8% 和 98.37%，但这两个浏览器仍然默认禁用 TLS 1.3，直到这些兼容层变得更加普及。
与 TLS 1.2 相比的性能
为了了解 TLS 1.3 与 TLS 1.2 的匹配情况，我们在支持 TLS 1.3 的 Nginx 服务器上运行了几项性能测试。测试在https://enabled.tls13.com上进行，这是 TLS 工作组提供的测试站点，使用Sitespeed.io进行。我们在 Chrome 63.0.3293.132 的不同实例上测试了两个版本：一个启用了 TLS 1.3（使用 ECDHE_ECDSA 和 X25519 进行密钥交换），另一个禁用了 TLS 1.3（使用 X25519 进行密钥交换）。在每个浏览器实例中，我们三次调用该站点并重复此步骤三次。
总体指标
|
总响应大小 |
1.4 千字节 |
|
HTML大小 |
702 号 |
|
总请求数 |
2 |
对于以下每个指标，我们显示由 Sitespeed.io 计算的平均值（以毫秒为单位）：
- FirstPaint：浏览器首次开始渲染页面的时间。
- BackEndTime：服务器生成并开始发送 HTML 所需的时间。
- ServerResponseTime：服务器发送响应所需的时间。
- PageLoadTime：页面加载所需的时间，从初始请求到浏览器加载完成。
TLS 1.2
|
公制 |
测试 1 |
测试 2 |
测试 3 |
平均的 |
|
首创油漆 |
486 |
424 |
431 |
447 |
|
后端时间 |
429 |
377 |
389 |
398 |
|
服务器响应时间 |
104 |
95 |
101 |
100 |
|
页面加载时间 |
456 |
401 |
414 |
426 |
TLS 1.3
|
公制 |
检验 1（均值） |
测试 2 |
测试 3 |
平均的 |
|
首创油漆 |
441 |
433 |
410 |
428 |
|
后端时间 |
391 |
385 |
359 |
378 |
|
服务器响应时间 |
109 |
94 |
96 |
100 |
|
页面加载时间 |
420 |
414 |
387 |
407 |
TLS 1.3 平均缩短了 19 毫秒的页面加载时间，即减少了 4-5%。由于服务器响应时间在两次测试中保持一致，因此优势主要集中在加密和交付时间上。测试站点也不支持 0-RTT，这可以进一步提高性能。
启用 TLS 1.3
在加密库默认包含 TLS 1.3 之前，您需要在 Web 服务器中手动启用 TLS 1.3。
阿帕奇
Apache 通过OpenSSL 1.1.1和NSS 3.29库支持 TLS 1.3 。
使用 OpenSSL 时，请将 TLSv1.3 添加到服务器配置的 SSLProtocols 行。如果您希望明确指定要使用的密码套件，请将这些密码套件添加到 SSLCipherSuite 行。或者，您可以使用HIGH别名来包含所有 TLS 1.3 密码套件。
httpd配置文件
… SSLProtocol TLSv1.3 SSLCipherSuite HIGH … 使用 NSS 时，将 TLSv1.3 添加到服务器配置的 NSSProtocol 行。
nss配置文件
…NSSProtocol TLSv1.3…
Nginx
Nginx（自 1.13 版起）通过OpenSSL 1.1.1库支持 TLS 1.3。要启用它，请将 TLSv1.3 添加到服务器配置的 ssl_protocols 行：
nginx.conf
服务器 { … ssl_协议 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3； … }
Nginx 支持 Apache 使用的相同 SSL 密码套件。
结论
TLS 1.3 比 TLS 1.2 提供了重要的安全性和速度改进，但它的采用可能会很慢。不仅浏览器和加密库需要支持它，而且针对旧版本中的怪癖设计的中间盒也需要支持它。该协议已经包含了草案 22 中添加的“中间盒友好”附加功能，但在保证向后兼容性之前，组织不太可能急于部署它。
目前，您可以使用 CloudFlare 的中间盒干扰测试检查您的网络是否已准备好使用 TLS 1.3。您还可以使用 Qualys 的SSL 客户端测试检查您的浏览器是否兼容 TLS 1.3 。如果协议功能框以绿色显示 TLS 1.3，则表示一切就绪。您还可以在服务器上同时启用 TLS 1.3 和 TLS 1.2，不支持最新版本的客户端将回退到兼容版本。