(Non-conformance) Stateless Cookie Exchange
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 技术栈
- c
- 领域
- networking, security
调研方向
Read the linked DTLS 1.2 RFC section 4.2.1 and inspect the attached handshake trace alongside the duplicate-packet log. Trace how TinyDTLS records and checks the initial ClientHello sequence number; done means the ClientKeyExchange record in the trace is not discarded as a duplicate and the stateless cookie exchange retains no initial ClientHello state.
由索引模型根据 Issue 内容生成。
描述
Description
- Type: Non-conformance Bug
- Priority: Minor
Non-conformance Bug
Version: development branch
Expected behavior
The DTLS 1.2 RFC specifies the following requirement regarding stateless cookie exchange :
The DTLS server SHOULD generate cookies in such a way that they can be verified without retaining any per-client state on the server.
Actual behavior
TinyDTLS stores the record sequence number of the initial ClientHello and discards any subsequent records that duplicate this sequence number. However, in a truly stateless exchange, no information from the initial ClientHello should be retained. In the attached handshake trace, the record containing the ClientKeyExchange message uses the same record sequence number as the initial ClientHello. As shown in the log below, this results in the record being discarded.
Log
May 15 13:08:00 INFO received message (117 bytes), starting with 'handshake', epoch 0
May 15 13:08:00 INFO handshake message epoch 0
May 15 13:08:00 INFO got 'handshake' epoch 0 sequence 0 (42 bytes)
May 15 13:08:00 DEBG dtls_handle_message: FOUND PEER
May 15 13:08:00 DEBG bitfield is ffffffffffffffff sequence base 1 rseqn 0
May 15 13:08:00 DEBG Drop: duplicate packet arrived (bitfield)```- 主要语言
- C
- 星标
- 122
- 派生
- 67
- 平均合并
- 6 天 8 小时
- 30 天内合并 PR
- 5
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
eclipse-tinydtls/tinydtls 的其他 Issue
-
ECDHE_ECDSA ClientKeyExchange rejected as too short when DTLS_PSK_MAX_CLIENT_IDENTITY_LEN > 64可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭bug good first issue please retest
难度 2/5 1-3 小时 新手友好度 76/100
eclipse-tinydtls/tinydtls#298 · 2 条评论 ·
维护者通常 2 天内回复
-
`dtls_get_cookie`: dereference before the length check (currently masked by `dtls_create_cookie`)未关闭
难度 2/5 1-3 小时 新手友好度 68/100
eclipse-tinydtls/tinydtls#279 · 2 条评论 · 1 个 reaction ·
维护者通常 2 天内回复
-
MSVC build is broken (undeclared `DTLS_DEBUG_BUF_SIZE`)可能已有人在做 @mrdeep1 于 9 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 25/100
eclipse-tinydtls/tinydtls#283 · 5 条评论 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 57/100
eclipse-tinydtls/tinydtls#278 · 3 条评论 · 1 个 reaction ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
eclipse-tinydtls/tinydtls#274 · 2 条评论 ·
维护者通常 2 天内回复
查看 eclipse-tinydtls/tinydtls 的全部 Issue
相似的 Issue
-
type: feature
难度 1/5 1 小时以内 新手友好度 77/100
-
难度 2/5 1-3 小时 新手友好度 78/100
FujiNetWIFI/fujinet-firmware#1932 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 63/100
维护者通常 1 天内回复
-
stdlib
难度 2/5 1-3 小时 新手友好度 68/100
-
logo request
难度 2/5 1-3 小时 新手友好度 72/100
fastfetch-cli/fastfetch#2650 ·
维护者通常 1 天内回复