TLS原理与实践（三）tls1.3

主页

引言

tls1.2作为主流的网路安全协议，被广泛应用，但tls1.2仍存在一些安全隐患和性能问题，如：

  • MD5、SHA-1算法已被破解，不再安全
  • RSA密钥协商存在安全隐患，不支持前向安全
  • 加密模式CBC存在Padding Oracle攻击的潜在风险
  • tls1.2在进行密钥协商时，需要2-RTT，效率较低等

注：RTT = Round Trip Time，表示交互次数。

为了解决tls1.2存在的问题，tls1.3协议应运而生，tls1.3废弃了一些存在安全隐患的加密套件，并新增了一些安全级别较高的加密套件。同时在性能上，TLS1.3能够实现1-RTT密钥协商，以及0-RTT连接恢复（tls1.2连接恢复需要1-RTT），握手效率提升了1倍左右。

本文的主要内容组织如下：

  • TLS1.3加密套件介绍
  • TLS1.3握手协议
  • TLS1.3协议wireshark抓包分析

TLS1.3协议

TLS1.3加密套件

TLS1.3支持的加密套件如下：

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256

从加密套件上看，与tls1.2相比（如：tls_ecdhe_ecdsa_with_aes_128_gcm_sha256）, tls1.3协议支持的加密套件不再包含密钥协商算法和签名算法，仅包含加密和摘要算法，这是因为在TLS 1.3中：

  • 所有密钥协商默认使用ECDHE算法，这意味着在握手过程中，客户端和服务器都使用椭圆曲线密钥协商来生成共享的对称密钥。椭圆曲线Diffie-Hellman密钥交换提供了强大的安全性和前向保密性，可以抵抗主动攻击和被动监听。
  • TLS1.3允许客户端和服务器选择适当的签名算法，以实现身份验证和握手完整性的保护。这种灵活性和可扩展性是TLS 1.3设计的一部分，以提供更安全和可靠的通信。
  • TLS1.3仅支持AEAD带认证的加密算法，不再支持CBC模式的加密算法，提高了加密数据的安全性

注：需要注意的是，尽管TLS1.3默认使用ECDHE作为密钥协商算法，但仍然可以通过配置选择其他密钥交换算法，如基于RSA的密钥交换（RSA Key Exchange）。然而，在TLS 1.3中，推荐使用ECDHE来获得更高的安全性和性能。

TLS1.3握手协议

TLS1.3协议握手流程如下 (来源 rfc8446）

注：

  • +表示在先前提到的消息中发送的值得注意的扩展。
  • *表示可选或情境依赖的消息/扩展，不一定总是发送。
  • {}表示使用从 [sender]_handshake_traffic_secret 导出的密钥保护的消息。
  • []表示使用从 [sender]_application_traffic_secret_N 导出的密钥保护的消息。

从上图可以看到，握手可以看作有三个阶段（如上图所示）：

  • 密钥交换（Key Exchange）：建立共享的密钥材料并选择加密参数。此阶段之后的所有内容都是加密的。
  • 服务器参数（Server Parameters）：建立其他握手参数（如客户端是否经过身份验证、应用层协议支持等）。
  • 身份验证（Authentication）：对服务器（以及可选地对客户端）进行身份验证，并提供密钥确认和握手完整性。

密钥交换（Key Exchange)

在密钥交换阶段，客户端发送ClientHello消息，其中包含：

  • 随机的nonce（ClientHello.random);
  • 所提供的协议版本；
  • 一组对称密码算法/HKDF哈希对；
  • Diffie-Hellman共享密钥(在"key_share"扩展中)、预共享密钥标签集合(在"pre_shared_key"扩展中), 或两者都有；
  • 可能的其他扩展。

服务器处理ClientHello并确定适当的加密参数。然后通过ServerHello响应，指示协商的连接参数。ClientHello和ServerHello的组合确定了共享密钥。

  • 如果使用了(EC)DHE密钥协商，则ServerHello包含服务器临时生成DH公钥的key_share扩展。
  • 如果使用PSK密钥协商，则ServerHello包含一个pre_shared_key扩展，指示选择了客户端提供的PSK中的哪一个。
  • 请注意，实现可以同时使用(EC)DHE和PSK，在这种情况下ServerHello将提供两个扩展。

服务器参数(Sever Parameters)

然后，服务器发送两个消息以建立服务器参数：

  • EncryptedExtensions：对于不需要确定密码参数的ClientHello扩展的响应。
  • CertificateRequest：如果需要客户端身份证书验证，则为该证书的所需参数。如果不需要客户端身份验证，则省略此消息。

身份验证（Authentication)

最后，客户端和服务器交换身份验证消息。具体来说：

  • Certificate：服务端证书和证书相关的扩展。如果不使用证书进行身份验证，则服务器会省略此消息；如果使用原始公钥[RFC7250]或缓存的信息扩展[RFC7924]，则此消息将不包含证书，而是包含与服务器的长期密钥对应的其他信息。
  • CertificateVerify：使用Certificate消息中公钥对应的私钥对整个握手消息进行签名。如果不通过证书进行身份验证，则省略此消息。
  • Finished：对应整个握手的消息认证码MAC。此消息提供密钥确认，将客户端/服务端的身份与交换的密钥绑定，并在PSK模式下还进行握手身份验证。

收到服务器的消息后，客户端通过其身份验证消息（即Certificate和CertificateVerify（如果有请求）和Finished）做出响应。
此时，握手过程完成，客户端和服务器生成了记录层所需的密钥材料，以通过加密来交换应用层数据。在发送Finished消息之前，不得发送应用数据。

TLS1.3协议wireshark抓包分析

在TLS原理与实践（二） 中，我们使用tcpdump对TLS1.2协议的demo程序进行了抓包，并使用wireshark进行了分析。 我们使用同样的方法，对TLS1.3进行抓包分析，（注:在我们的demo程序中，仅模拟了服务器单项认证的场景), 抓包过程如下：

说明：

  1. 启动抓包程序：我们使用tcpdump进行抓包
  2. 启动tls服务：该demo程序服务端仅支持TLS1.3协议
  3. 启动tls客户端：该demo程序客户端支持多种版本TLS协议，我们通过tlsVersion 1.3指定仅使用TLS1.3
  4. 结束抓包程序：当客户端控制台打印hello world时，表明握手和传输应用数据完成。我们通过ctrl + c手动关闭tcpdump抓包程序，抓包程序会将捕获的网络数据保存到capture.pcap文件中。

下面我们将capture.pcap导入或拖入wireshark程序，对TLS1.3协议进行分析：

概览页

从概览图中我们可以看到，TLS1.3握手协议8个记录被封装到3个tcp协议包中完成：

  • Client Hello
  • Server Hello，Change Cipher Spec, Application Data，Application Data，Application Data，Application Data
  • Change Cipher Spec, Application Data

说明：

  • Change Cipher Spec这个记录用于较早版本TLS中，在TLS1.3不再需要。在中间盒兼容模式中，发送这个记录可以帮助伪装会话为TLS 1.2会话。
  • 在第2个协议包中包含4个Application Data实质代表的是被加密的握手协议记录，分别对应EncryptedExtensions, Certificate, CertificateVerify和Finished
  • 在第3个协议中包含的Application Data实质为应用层数据，这里代表客户端请求的数据（密文形式）

“中间盒兼容模式”: 在TLS 1.3中，引入了"中间盒兼容模式"（middlebox compatibility mode）的概念，这是为了解决某些网络中存在的中间设备（如防火墙、代理服务器等）可能不支持或不理解TLS 1.3协议的情况。由于TLS 1.3在协议设计和加密套件选择方面与TLS 1.2有很大的差异，一些网络设备可能无法正确解析或处理TLS 1.3的通信。为了绕过这些设备的限制，TLS 1.3引入了中间盒兼容模式。在中间盒兼容模式下，TLS 1.3的客户端会发送一个伪装为TLS 1.2的记录（record）。这个伪装的记录可以欺骗中间设备，使其认为通信是基于TLS 1.2协议进行的，从而绕过了对TLS 1.3的限制。需要注意的是，中间盒兼容模式只是一种临时解决方案，旨在帮助过渡期内的网络设备与TLS 1.3兼容。随着时间的推移，网络设备应该升级并支持TLS 1.3以享受其更强大的安全性和性能优势。

Client Hello消息

消息发送：客户端 -> 服务端

我们按照图中的序号进行分析：

  1. 表明该握手协议发送的为Client Hello消息
  2. 伪装的TLS协议版本，在TLS1.3中间盒兼容模式中，此处的版本号仅用于兼容TLS1.2模式，用于欺骗中间设备，绕过对TLS1.3协议的限制（这里的中间设备目前支持的最高TLS版本为TLS1.2）
  3. 客户端随机数，tls1.3协议Client Hello中的Random作用与TLS1.2相同，充当随机数种子
  4. 支持的加密套件。从图中可以看出客户端支持的加密套件(Cipher Suites)列表一共有19个。
  5. TLS1.3协议支持的加密套件。TLS1.3废弃了不安全或存在安全隐患的加密套件（16个），新增了3个更加安全的加密套件(本文开头已介绍，不在赘述）

在TLS1.3中，扩展字段发挥了重要作用，Client Hello消息包含的主要扩展字段（如上图) 有：

  1. 客户端支持的椭圆曲线算法Supported Groups列表，这里的EC算法主要用于密钥协商，按照优先级排列
  2. 客户端支持的签名算法signature_algorithms列表，用于身份认证
  3. 客户端支持的TLS版本，这里的版本为实际支持的TLS版本，由于我们在demo里，通过tlsVersion设置了TLS协议版本为1.3，所以这里显示客户端支持的TLS版本列表为TLS1.3
  4. 客户端选用的椭圆曲线算法，客户端使用了x25519椭圆曲线算法来生成了预备主密钥的客户端部分。

Server Hello消息

消息发送: 服务端 -> 客户端

Server Hello消息与Change Cipher Spec, Application Data，Application Data，Application Data，Application Data消息在同一个TCP包中发送。

基于上图，我们按照序号分析：

  1. 表明发送的握手协议包为ServerHello消息 (伴随了其他握手消息的密文，在同一个TCP包中发送）
  2. 服务端随机数，tls1.3协议Server Hello中的Random作用与TLS1.2相同，用作随机数种子
  3. 协商的加密套件，从上图中我们可以看到，客户端/服务端最终协商使用的加密套件为TLS_AES_128_GCM_SHA256
  4. 协商的tls协议版本，为TLS1.3
  5. 协商使用的密钥协商用到的椭圆曲线算法，从图中可以看到为x25519，这也是Client Hello中客户端优先选用的算法。在Key Exchange字段携带了服务端生成的共享密钥
  6. 此消息Change Cipher Spec在TLS1.3中不使用，仅用于兼容（本文前言部分已介绍，不在赘述）
  7. Application Data消息一共有4个，这里为密文形式，从这里我们可以了解到，与TLS1.2相比，TLS1.3提供了更强大的保密能力。 这里被加密的消息，与TLS1.2中的消息类似，主要用于客户端/服务端身份验证，不在赘述。

Change Cipher Spec

消息发送： 客户端 -> 服务端
Change Cipher Spec消息Application Data消息在同一个TCP包中发送。

说明：

  1. Change Cipher Spec消息：略
  2. Application Data： 客户端请求数据的密文形式

结论

本文详细介绍了TLS1.3协议的握手流程，通过wireshark抓包分析，我们可以看到与TLS1.2相比，TLS1.3在握手效率、消息保密性上具有更大的优势。应用系统接入TLS1.3也将是一种未来趋势。

参考资料

posted @ 2023-07-12 17:02  warm3snow  阅读(6605)  评论(0)  编辑  收藏  举报