咨询WolfSSL中DTLS1.0/1.2的HelloVerifyRequest cookie交换启用控制方法

首先明确容易混淆的边界：你提到的wolfSSL_send_hrr_cookie接口仅适配TLS 1.3体系下的HelloRetryRequest逻辑，和DTLS 1.0/1.2中基于RFC 6347定义、以HelloVerifyRequest为载体的cookie防DoS机制完全独立，两类流程互不影响，调用HRR相关接口不会改动DTLS 1.0/1.2的cookie行为。

实际部署中的启用与控制操作可以按需选择：

• 基础默认启用规则：只要编译WolfSSL时开启DTLS支持（对应编译配置项--enable-dtls），服务端侧的HelloVerifyRequest cookie交互流程就是默认开启状态，不需要额外业务调用触发。流程完全对齐RFC 6347 4.2.1节要求：服务端收到无有效cookie的初始ClientHello报文时，自动生成绑定客户端地址、带完整性校验的Cookie，封装在HelloVerifyRequest中返回客户端；待客户端回传携带匹配Cookie的ClientHello后，才会分配握手上下文、推进正式握手流程，从源头拦截无来源校验的泛洪攻击。
• 可自定义的控制项：
• 替换默认Cookie签名密钥：服务端初始化DTLS上下文后，可以调用wolfSSL_dtls_set_cookie_key接口，传入自定义的固定密钥，替代WolfSSL默认进程启动时随机生成的Cookie校验密钥，适配多实例部署下跨进程共享Cookie校验能力的需求。
• 按需关闭cookie校验：如果是在完全可信的封闭内网环境，不需要做防泛洪校验，可以在创建服务端SSL上下文时，通过wolfSSL_CTX_set_dtls接口传入WOLFSSL_DTLS_NO_COOKIE配置项，直接跳过HelloVerifyRequest的cookie交互步骤。
• 调整Cookie有效时效：通过wolfSSL_CTX_dtls_set_cookie_timeout接口设置Cookie的过期时长，超过时效的Cookie会被服务端判定为无效，触发重新校验流程，降低Cookie被长期复用伪造的风险。

补充说明：DTLS cookie交换流程是协议栈内置的自动逻辑，客户端业务代码不需要手动提取、修改、回传Cookie字段——只要客户端符合RFC 6347标准实现，就会自动完成整个cookie交互过程，无需业务层额外介入。

内容的提问来源于stack exchange，提问作者gspr