TLS1.3抓包分析（1）——ClientHello

最新推荐文章于 2025-07-03 00:17:14 发布
原创 最新推荐文章于 2025-07-03 00:17:14 发布 · 8.6k 阅读 · 30 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#TLS1.3 #Wireshark #抓包 #报文分析

本文通过Wireshark分析了HTTPS连接中TLS1.3的ClientHello报文，详细解读了版本号、随机数、密码套件、扩展等关键字段，包括向后兼容性、会话恢复、加密算法选择以及预共享密钥协商等内容。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

抓包使用的是WireShark2.6.7，抓包内容为https://tls13.crypto.mozilla.org/（Mozilla的TLS1.3测试页面），浏览器为chrome（需开启TLS1.3），这里我先给出抓包结果：

wireshark抓包
本次从握手的第一步开始分析，即ClientHello，下面是ClientHello的报文内容：
ClientHello
我们需要关注的是Secure Sockets Layer,即安全套接字层，下面是ClientHello所包含的内容：
ClientHello所包含的内容
Record Layer，记录层
Content Type：HandShake，表示内容类型为握手消息
Version：TLS1.0（0x0301），版本号为1.0，为什么是1.0？之前看的draft好像固定1.2版本
后面是握手部分（Handshake）的内容，首先上图：
Handshake Protocol
Handshake Type:ClientHello，表示握手消息类型，此处是ClientHello
Length:557,

最低0.47元/天 解锁文章

200万优质内容无限畅学
Adaptive AUTOSAR中的TLS技术
usstmiracle的博客
06-25 61
摘要：TLS技术作为传输层安全协议，在Adaptive AUTOSAR平台中发挥着关键作用，保障车辆通信安全。文章详细解析了TLS的定义、发展历程及核心功能，包括加密、身份认证和完整性保护机制。重点探讨了TLS在Adaptive AUTOSAR中的实施架构，包括安全通信服务端、加密API和身份管理组件等核心模块。通过典型应用场景分析，展示了TLS在车云通信、V2X安全等领域的实践方案，并提出了算法配置、性能优化等最佳实践。最后，文章指出TLS面临的计算资源挑战，展望了后量子密码学集成等未来发展方向。
TLS1.3抓包分析（3）——EncryptedExtentions等
汪哈哈zzz
03-12 2760
其实在最开始抓包的时候就发现了一个问题，就是在ChangeCipherSpec消息之后，没有加密扩展、证书，甚至Finished消息都没有。在握手过程中，Finished消息是一定存在的，所以说明用Wireshark抓的包存在问题，之前提到过，ChangeCipherSpec之后的消息都是进行加密了的，所以可能是因为Wireshark没有对后续的消息进行解密，所以只是显示了ApplicationD...
关于 TLS Client_Hello 版本的问题分析
weixin_44184325的博客
03-17 2676
以上可知，因为client_hello的兼容性，无论Record Layer使用哪种TLS协议版本，client_hello数据报文均能够得到有效的解析，最终完成数据通信过程中的TLS协议版本协商。SSL 3.0、TLS 1.0、TLS 1.1、TLS 1.2保持兼容的clienthello数据格式，只要保持兼容的数据格式，即使未来出现更高的tls 协议版本，服务器也能够进行处理。Client报文的封装和解析与Version协议版本无关，即使上下version均修改后，报文仍然可以得到正确的解析。
TLS/SSL 协议详解 (9) Client hello
叼哥的博客
11-14 6589
  SSL报文格式可以大致分为2部分，Record层 和 Handshake层，Record层中指定了后续数据的类型，SSL版本(一般来说固定)，以及后续数据的长度。Handshake层欧威Record层的负载，其关系类似TCP层的数据作为IP层的负载。 例如上图中显示的那样，SSL报文头部是TVL格式：   Content Type: Handshake   Version: TLS 1...
TLS 1.3 （Transport Layer Security version 1.3）详解 && TLS 1.3 严选密码套件
最新发布
csdn_tom_168的博客
07-03 1035
TLS 1.3是2018年发布的传输层安全协议重大升级，通过精简协议、强化加密和优化性能，解决了旧版本的安全与效率问题。其核心改进包括：仅保留强加密算法（如ECDHE、AES-GCM），强制前向保密；优化握手流程至1-RTT（首次）和0-RTT（恢复）；使用HKDF密钥派生和全加密握手。部署需注意0-RTT重放风险和后向兼容。相比TLS 1.2，TLS 1.3在安全性、速度和配置简化方面显著提升，成为现代互联网安全通信的基础标准。建议优先启用并配合OCSP Stapling等机制增强防护。
TLS1.3 协议的Golang 实现——ClientHello
weixin_33762130的博客
05-10 932
前言 撰写本文时TLS1.3 RFC 已经发布到28版本。以前写过一点密码学及TLS 相关的文章，为了更深入理解TLS1.3协议，这次将尝试使用Go语言实现它。网络上已有部分站点支持TLS1.3，Chrome浏览器通过设置可支持TLS1.3 (draft23)，利用这些条件可验证，我们实现的协议是否标准。 完整的实现TLS1.3 工作量很大，概念和细节...
TLS1.3实现篇---模拟clienthello
qq_35324057的博客
04-18 4590
前言 前面我已经写过一些有关TLS1.3协议的文章，主要是从理论出发去了解TLS1.3协议，为了更加深入的理解TLS1.3协议，我将尝试去实现它，目前有部分站点已经开始支持TLS1.3，我们可以利用这些站点来进行测试代码是否成功实现TLS1.3的部分结构，我现在主要实现了ClientHello的整体结构和部分扩展，但是在进行测试的时候不尽如人意，我们先来看一下测试情况。 测试站点www.git...
TLS1.3抓包分析（2）——ServerHello
汪哈哈zzz
03-12 3379
继续上次的报文分析，这次主要内容是TLS握手中的ServerHello消息。 首先是记录层（Record Layer）内容，Content Type表示内容类型为握手（Handshake），Version表示版本为TLS1.2，接下来是长度（Length）。 后面是握手协议部分的内容，我将逐个解释（其实大部分都和ClientHello的内容类似）： Handshake Type:ServerH...
TLS1.3抓包分析（4）——NewSessionTicket
汪哈哈zzz
03-12 6424
上次对客户端的认证阶段进行了分析，本次继续上次的内容往后进行分析。 先看Client响应的Change Cipher Spec和Finished消息，当服务器在前面发送了Certificate Request时，客户端往往也要发送自己的证书Certificate以及Certificate Verrify。 从图中就可以看出，消息格式和之前服务器发送的是一样的，所以不再进行分析。 New Ses...
查看服务器tls1.3是否存在
03-19
#### 抓包分析网络流量 借助专业的抓取软件如 Wireshark 对实时数据流展开深入剖析不失为另一种可行策略。当观察到初始 Client Hello 包含 version extension 字段且其中列举了 {3,4} 表示期望采用 TLS 1.3 同时...
科普：什么是TLS1.3
TrustAsia的博客
07-24 4175
TLS1.3是一种新的加密协议，它既能提高各地互联网用户的访问速度，又能增强安全性。 我们在访问许多网页的时候，常常会在浏览器的地址栏上看到一个锁的图标，并使用“https”代替传统的“http”。这里的“s”代表着安全。当你连接到一个HTTPS站点时，你和该站点之间的通信会被加密，这会显著提高浏览的安全性，使你的通信避开那些窥视的眼睛，并防止恶意代码的注入。HTTPS不仅应用于网站，还保护
tls1.3【转载】
llzhang_fly的博客
08-29 2179
该文档定义了TLS(Transport Layer Security)协议的1.3版本。TLS可以让C/S应用在互联网上通过一种能抵御信息泄露、破坏或篡改的方式安全通信。该文档更新了RFC 5705和6066，废弃了RFC 5077、5246、6961。也对TLS1.2的实现做了些新的规定。TLS的首要目标在两个通信端点之间提供一个安全通道；对底层传输通道的唯一要求就是传输可靠、没有乱序。可鉴别：server端总是可被鉴别，client端可选被鉴别。...
测试网站是否支持TLS1.3协议的方法
weixin_44435894的博客
03-25 4233
1.先测试1.2 openssl s_client -connect www.baidu.com:443 -tls1_2 2.测试1.3 TLS 从图上说明百度不支持TLS1.3
ubuntu-18.04下nginx-1.14搭建http2+TLS 1.3网站并采用wireshark 3.6+chrome抓包
duzhig的专栏
05-14 577
ubuntu-18.04下nginx-1.14搭建http2+TLS 1.3网站并采用wireshark 3.6+chrome抓包
使用wireshark分析TLS
网鱼的栈
12-22 3397
原文链接：https://www.cnblogs.com/lv6965/p/7859925.html 1.基本概念 SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。 TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据
Tengine TLSv1.3最佳实践
weixin_33841503的博客
09-05 97
2019独角兽企业重金招聘Python工程师标准>>> ...
wireshark 抓包学习TLS握手（ECDHE）
m0_61209018的博客
11-19 1835
首先放出经典的流程图： TLS 握手共分四个阶段,为了便于理解，我用wireshark抓了包来分析每一个阶段： Client Hello（第一次握手）： 客户端首先会发一个「Client Hello」消息，消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random） Server Hello(第二次握手) 服务器收到client hello 之后，会回复要给server hello的消息，这个消息中会包含有服务端确认的 TLS 版本号，一个..
Tls1.3中，clienthello报文中的psk mode扩展表示什么意思
03-20
<think>好的，我现在要解释TLS 1.3中ClientHello报文里的psk_mode扩展的含义。首先，我需要回忆一下TLS 1.3中PSK的相关知识。PSK是预共享密钥，用于简化握手流程，提升性能。 psk_mode扩展应该和PSK的使用方式有关。在TLS 1.3中，有两种主要的握手模式：一种是完整的握手，另一种是使用PSK的简化握手。可能psk_mode用来协商客户端支持的PSK模式。 接下来，我需要确认RFC文档中的具体定义。根据RFC 8446，TLS 1.3的规范，PSK密钥交换模式扩展（psk_key_exchange_modes）确实存在于ClientHello中。用户可能混淆了名称，将psk_key_exchange_modes简称为psk_mode。 这个扩展的作用是客户端告诉服务器它支持的PSK密钥交换模式。可能的模式包括psk_ke（仅PSK）和psk_dhe_ke（PSK与临时Diffie-Hellman组合）。服务器会根据客户端支持的模式和自身的配置选择一种模式继续握手。 需要进一步检查是否在ClientHello中有名为psk_mode的扩展，或者是否是用户对psk_key_exchange_modes的简称。根据RFC，正确的扩展名是psk_key_exchange_modes，所以可能用户提到的psk_mode扩展实际上是这个。 然后，要解释每个模式的具体含义。psk_ke表示仅使用预共享密钥，不提供前向保密；而psk_dhe_ke结合了PSK和临时DH，提供了前向保密。客户端通过这个扩展告知服务器自己支持哪些模式，服务器选择其中一个进行后续流程。 总结来说，psk_mode扩展（正确名称是psk_key_exchange_modes）用于协商PSK在密钥交换中的使用方式，确保客户端和服务器在安全性和性能需求上达成一致。</think>在 TLS 1.3 中，ClientHello 报文中的 `psk_key_exchange_modes` 扩展（用户可能简称为 `psk_mode`）用于**协商客户端支持的预共享密钥（PSK）密钥交换模式**。以下是逐步解析： --- ### 1. **PSK 的作用** TLS 1.3 通过 PSK 实现两种优化： - **会话恢复**：复用之前会话的密钥材料，减少握手开销。 - **预共享密钥认证**：使用预先配置的密钥进行身份验证，无需证书。 --- ### 2. `psk_key_exchange_modes` 扩展的格式 客户端在 ClientHello 中通过该扩展声明支持的 PSK 模式： ```plaintext psk_key_exchange_modes = [PSK模式1, PSK模式2, ...] ``` 模式类型为单字节值，目前定义两种： - `0x00`: **psk_ke`（仅 PSK）** 仅使用预共享密钥，不提供前向保密（Forward Secrecy）。 - `0x01`: **psk_dhe_ke`（PSK + 临时 DH）** 结合 PSK 和临时 Diffie-Hellman 交换，提供前向保密。 --- ### 3. **协商过程** - **客户端**：通过 `psk_key_exchange_modes` 扩展列出支持的模式（如 `[psk_dhe_ke, psk_ke]`）。 - **服务器**：根据自身策略选择一个模式： - 若选择 `psk_dhe_ke`，需生成临时 DH 参数（包含在 ServerHello 或 KeyShare 扩展）。 - 若选择 `psk_ke`，直接复用 PSK 生成密钥，但失去前向保密性。 --- ### 4. **关键注意事项** - **必须性**：如果客户端发送了 `pre_shared_key` 扩展，则必须同时发送 `psk_key_exchange_modes` 扩展。 - **安全性优先级**：服务器通常优先选择 `psk_dhe_ke`，因其提供前向保密。 - **兼容性**：若客户端未发送此扩展，服务器不得使用 PSK 进行密钥交换。 --- ### 5. **示例流程** 1. **ClientHello** ```plaintext psk_key_exchange_modes = [psk_dhe_ke, psk_ke] pre_shared_key = [PSK标识1, PSK标识2...] ``` 2. **ServerHello** ```plaintext selected_identity = 0 // 选择第一个 PSK 标识 key_share = ServerDHParams // 若选择 psk_dhe_ke ``` 3. **密钥计算** - `psk_ke`：直接使用 PSK 派生密钥。 - `psk_dhe_ke`：结合 PSK 和 DH 共享密钥派生密钥。 --- ### 总结 `psk_key_exchange_modes` 扩展是 TLS 1.3 中 PSK 握手的核心机制，它确保了客户端和服务器在以下方面达成一致： - 是否要求前向保密（通过 `psk_dhe_ke`）。 - PSK 如何与其他密钥材料结合使用。 通过此扩展，TLS 1.3 在简化握手的同时，仍能灵活平衡性能与安全性。
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值