跳转到主要内容

热门内容

今日:


总体:


最近浏览:


Chinese, Simplified

category

在当今数字化互联的世界中,通信安全和隐私仍然是一个主要问题。第一个在互联网上提供安全和加密连接的协议是安全套接层(SSL),它使用公钥密码学。1999年,SSL升级到版本3,并标准化为传输层安全版本(TLS)1.0。这些协议现在被更安全的TLS 1.2和1.3版本所取代。

传输层安全是确保公共互联网上的所有通信保持安全和防篡改的标准。它提供机密性、身份验证、完整性和防止重放攻击的保护。

本文探讨了TLS 1.2与1.3在TLS 1.3中的变化和改进。

TLS 1.2与1.3——差异总结


TLS 1.2于2008年发布,并记录在RFC 5246中。升级包括几个增强功能,用更强的密码替换较弱的密码套件。TLS 1.3在2018年1.2版本发布十年后发布。IETF在RFC 8446中对最新版本进行了标准化。1.3与1.2相比的重大变化包括以下内容:

 

握手过程


这两种协议都始于握手过程,该过程使用非对称和对称加密的组合在客户端和服务器之间创建安全/加密的隧道。实际的数据传输发生在握手完成之后。

TLS 1.2握手过程延长且耗时。TLS 1.3使其更高效,增强了安全性。

TLS 1.2


TLS 1.2握手需要客户端和服务器之间的两次往返(2-RTT)或消息交换才能完成。过程如下。

客户问候


客户端通过客户端Hello消息发起TLS握手,该消息包括:

  • 客户端支持的TLS版本
  • 客户端支持的密码套件
  • 一个随机数,将在后续步骤中用于生成加密密钥。
  • 如果客户端希望恢复与服务器的先前会话,则提供非空会话ID。
     

服务器问候


如果Client Hello的会话ID非空,服务器将搜索之前缓存的会话并恢复。如果为空,服务器会生成一个新的随机会话ID。然后,它会返回一条server Hello消息,其中包括:

  • 从客户端Hello中包含的列表中选择TLS版本。
  • 从客户端Hello中包含的列表中选择的密码套件。
  • 在后续步骤中,服务器为加密密钥生成了随机数。
  • 会话ID
  • 包含服务器公钥的签名SSL/TLS证书。


然后,服务器向客户端发送服务器Hello Done消息

密钥交换


在收到服务器Hello Done后,客户端验证证书颁发机构是否信任服务器证书。验证后,它向服务器发送一条密钥交换消息,该消息包含随机生成的预主密钥,并用服务器的公钥加密。

服务器使用其私钥解密预主密钥。客户端和服务器使用先前共享的随机数和预主密钥生成主密钥。两者都使用共享的主密钥来生成会话密钥。

握手完毕


最后,客户端向服务器发送一条Change Cipher Spec消息,说明它正在使用会话密钥切换到对称加密,然后是Handshake Finished消息。

服务器还以Change Cipher Spec消息和Handshake Finished消息进行响应,表示它也准备好使用共享对称密钥。

客户端和服务器现在开始使用会话密钥交换完全加密的数据。这些密钥是临时的,仅在客户端和服务器之间的会话期间有效。

TLS 1.3


相比之下,TLS 1.3握手过程在一次往返(1-RTT)中完成。

客户问候


客户端通过客户端Hello消息发起TLS握手,该消息包括:

  • 提供的协议版本(1.3)
  • 客户端支持的密码套件
  • 客户端支持的密钥交换方法
  • 客户端生成的随机数
  • 任何可选扩展


服务器问候


服务器使用ClientHello随机数、其自己生成的随机数、客户端参数和密码套件生成主密钥。然后,它会返回一条服务器问候和服务器完成消息,其中包括:

  • 服务器选择的协议版本(1.3)
  • 服务器选择了密码套件
  • 服务器选择了密钥交换方法
  • 服务器生成的随机数
  • 服务器SSL/TLS证书
  • 任何可选参数


握手完毕


客户端验证服务器证书,生成主密钥,并发送客户端完成消息。然后,客户端和服务器立即开始通过对称加密交换数据。

TLS 1.2与1.3——功能差异


TLS 1.2的一些功能在1.3中没有继续。还添加了几个新功能。

算法


TLS 1.2中的遗留和弱加密算法已被删除。TLS 1.3现在只支持带关联数据的身份验证加密(AEAD)算法。AEAD是一种同时提供数据机密性、完整性和真实性保证的加密方式。它组合并处理正在加密的数据(明文)和需要完整性但不需要保密性的其他数据(相关数据)。这种集成方法确保加密数据(密文)在未被检测到的情况下不会被篡改或伪造,并且任何修改在解密后都会立即被发现。

版本控制


在TLS 1.2及更早版本中,版本协商机制允许客户端和服务器通信双方都能支持的最高版本的TLS。然而,此过程容易受到攻击者的操纵,攻击者可以拦截协商过程并修改消息以强制使用较旧的协议版本。TLS 1.3要求客户端和服务器在使用TLS 1.3时支持TLS 1.3,从而简化了这一过程。

压缩


1.3之前的TLS版本支持压缩,并在Client Hello中交换了支持的压缩方法列表。然而,这些方法在一些攻击中被利用了。TLS 1.3现在发送一个空字节(在legacy_compression_methods中),有效地从协议中删除了压缩。

数字签名验证


当服务器将其证书作为TLS握手的一部分呈现给另一方时,它还提供了一个数字签名来证明它是证书的合法所有者。数字签名也用于验证密钥交换过程。

TLS 1.2支持各种密码套件(主要是RSA)用于签名验证,选择取决于客户端和服务器支持和偏好。

相比之下,TLS 1.3强调使用椭圆曲线数字签名算法(ECDSA),该算法使用较小的密钥大小,从而实现更快的计算、更少的带宽使用和更快的连接。TLS 1.3将RSA的使用限制为更安全的填充方案(特别是RSASSA-PSS),并通常鼓励使用椭圆曲线密码学。

前向安全性


前向保密是指为每个安全通信会话生成新的唯一会话密钥的临时密钥交换机制。

TLS 1.3要求使用前向保密。如前一节所述,在TLS 1.3握手过程中,客户端和服务器都使用Ephemeral Diffie-Hellman密钥交换协议独立计算唯一的会话密钥。密钥是使用客户端和服务器随机数以及所选密码套件进行数学计算的。这些会话密钥不会在网络上传输,并在每次会话结束后被丢弃。

目标是保护过去会话的隐私,这样即使攻击者捕获了服务器的私钥,他们也无法解密整个数据交换。

TLS 1.2与1.3性能对比


TLS 1.3大大提高了1.2版本的性能。

减少握手延迟


TLS 1.2需要两次往返才能完成握手过程。TLS 1.3将初始握手和加密参数协商合并为一次往返。这有效地将握手时间减少了一半。

TLS 1.3还提供0-RTT握手,客户端和服务器可以恢复之前建立的TLS会话。为了启动零往返的数据交换,客户端和服务器都需要保留会话密钥。它们在服务器正确验证客户端身份之前交换数据。

假设攻击者之前已经拦截了客户端-服务器通信。在这种情况下,攻击者可以将客户端数据重放到服务器,服务器将无法验证其是否合法。因此,不建议使用0-RTT握手。

减少计算开销


TLS 1.3从协商过程中删除了过时的密码套件和加密函数。它还通过使用Diffie-Hellman密钥交换简化了密钥交换过程,并消除了对TLS 1.2中使用的RSA等单独密钥交换机制的需求。这两项改进都简化了客户端和服务器上的计算开销。

TLS 1.3采用


如果你还没有这样做,最好升级到TLS 1.3。

各种监管和标准组织正在将TLS 1.3纳入其合规要求,以确保跨不同网络的安全传输。

例如,美国国家标准与技术研究院(NIST)特别出版物800-52修订版2提供了在联邦系统中实施TLS 1.3的指南。NIST要求各组织在2024年1月之前计划并增加对TLS 1.3的支持。这一授权强调了升级到TLS 1.3以符合行业标准和最佳实践的重要性。

其他通用标准,如支付卡行业标准安全委员会(PCI-DSS)和《健康保险流通与责任法案》(HIPAA),也参考了NIST SP 800-52指南。

许多网站同时使用1.2和1.3来保持与大多数终端设备的互操作性。Qualys SSL实验室对排名前15万的最受欢迎的网站进行持续调查(根据Alexa的数据)。根据2024年2月的扫描,99.9%的网站支持1.2版本,67.8%的网站现在支持TLS 1.3。

采用TLS 1.3的主要挑战是客户端设备支持有限。截至本文撰写时,以下浏览器和应用程序完全支持TLS 1.3。

  • 火狐63+
  • Chrome 70+
  • 边缘75+
  • 歌剧57+
  • Safari 12.1+
  • 安卓10.0+
  • Java 11+
  • OpenSSL 1.1.1+

配置选项


Mozilla提供了一个SSL配置生成器,用于在许多服务器软件中启用TLS 1.3。以下是仅启用TLS 1.3的Apache 2.4.41 web服务器的推荐配置。

<VirtualHost *:80>
   RewriteEngine On
   RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
   RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>
<VirtualHost *:443>
   SSLEngine on
   SSLCertificateFile      /path/to/signed_cert_and_inter_certs
   SSLCertificateKeyFile   /path/to/private_key
   Protocols h2 http/1.1
   Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLHonorCipherOrder     off
SSLSessionTickets       off
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"


最后的想法


TLS在使用公钥加密和客户端与服务器之间的握手机制保护任何网络基础设施上的传输安全方面至关重要。与TLS 1.2相比,TLS 1.3提供了改进的安全性、增强的性能和简化的功能。

如果您正在努力解决性能问题,升级TLS只是第一步。您需要可见性来解决问题并降低MTTR。Catchpoint无与伦比的主动观察者网络提供了对所有站点、数据中心和远程位置的可见性。您可以跨用户连接、公私网络和应用程序层诊断问题。

接下来是什么?

 

介绍
了解HTTP/3如何在多路复用、连接、安全性、错误恢复等方面改进HTTP/2,以改善web通信、性能和用户体验。
1.gRPC HTTP/3
了解如何以及为什么使用gRPC和HTTP/3来构建高性能的现代应用程序,这些应用程序在规模上具有竞争力。
2..NGINX HTTP/3
学习基本和高级NGINX HTTP/3配置、调试技巧、如何与防火墙集成、性能优化和其他最佳实践。
3..HTTPS上的DNS与TLS
了解DNS over HTTPS和DNS over TLS,它们是如何工作的,性能差异,PowerDNS实现,以及如何在两者之间进行选择。
4..QUIC上的DNS
了解域名系统(DNS)如何随着时间的推移而发展,以及QUIC上的DNS如何提供性能和可靠性得到提高的解决方案。
5..Traefik HTTP/3
了解HTTP/3和Traefik如何协同工作以增强web基础设施。包括Traefik HTTP/3设置的详细静态和动态配置以及教程。
6..TLS 1.2与1.3
了解TLS 1.2和1.3在算法、版本控制、压缩、前向保密等方面的差异。
7.QUIC与TCP
了解如何为您的应用程序在QUIC和TCP之间进行选择。了解QUIC与TCP的关键差异以及监控性能的指标。

本文地址
最后修改
星期五, 四月 18, 2025 - 09:41
Article