Mbed TLS 安全模型详解威胁模型、漏洞报告流程与分支维护策略【免费下载链接】mbedtlsAn open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.项目地址: https://gitcode.com/GitHub_Trending/mb/mbedtlsMbed TLS 作为广泛使用的开源 TLS 库其安全性承诺的边界比支持哪些算法更关键它防哪些攻击、不防哪些攻击、漏洞该报给谁、哪些分支会收到安全修复。本文以仓库根目录的 SECURITY.md 为主体结合 BRANCHES.md 的分支维护策略与源码中的常量时间constant-time实现证据完整解析 Mbed TLS 的威胁模型threat model、漏洞报告通道和 X.509 解析的安全边界。读完后你能够为自己的项目准确划定 Mbed TLS 的安全保证范围并知道如何正确地上报漏洞与选择受支持的版本分支。一、漏洞如何报告安全团队的报告通道与事件处理目标根据 SECURITY.md 的Reporting Vulnerabilities一节如果你认为发现了一个 Mbed TLS 安全漏洞应通过电子邮件将其发送至安全团队mbed-tls-securitylists.trustedfirmware.org安全事件的处理流程Security Incident Handling Process则详细说明在项目在线文档的 vulnerability 处理页面中。该流程的首要目标是确保当问题公开时修复方案已经准备好可以部署fixes ready to be deployed when the issue goes public——这也是 Mbed TLS 安全响应的基本方针公开披露前修复必须就绪而不是先公开再修。这一承诺在仓库中是有迹可循的。例如 ChangeLog.d/serialized-data-load-hardening.txt 记录的是一类典型的内存越界读取型缺陷修复Reject serialized TLS 1.2 sessions whose session ID length exceeds 32, instead of accepting an out-of-range length that is later used to read past the end of the 32-byte session ID buffer.这类改动会进入ChangeLog.d/待发布变更说明并在修复就绪后随版本一起公开与修复先于公开的事件处理目标一致。二、哪些分支会收到安全修复只有维护中的分支SECURITY.md 明确指出只有维护中的分支maintained branches才会获得安全修复并强烈建议用户始终使用维护分支的最新版本。维护分支的完整清单定义在 BRANCHES.md 中当前仓库4.2.0 版本线见 build_info.h 中的MBEDTLS_VERSION_STRING 4.2.0对应以下分支格局分支性质修复策略main始终包含最新 release 及所有已公开的安全修复功能 Bug 修复 安全修复development准备下一个 4.x 小版本新功能 Bug 修复 安全修复mbedtls-3.6LTS 长期支持分支2024 年 3 月发布仅 Bug 修复 安全修复支持到 2027 年 3 月mbedtls-4.1首个 4.x LTS2026 年 3 月发布仅 Bug 修复 安全修复支持到 2029 年 3 月需要注意的边界同样来自 BRANCHES.md归档分支不再获得任何更新以archive/为前缀的历史分支如archive/mbedtls-2.7将不会收到任何变更自然也收不到安全修复。如果你的系统仍在跑这类老版本升级本身就是最大的安全动作。LTS 分支的额外约束LTS 分支除修复外还会尽量维持 ABI 兼容避免代码体积/RAM 占用增长但若与修复安全问题冲突安全优先——且会提供兼容选项。因此是否还会收到安全修复这个问题可以用一条简单的判断规则回答分支名不带archive/前缀、且在 BRANCHES.md 的维护清单里才会收到安全修复。三、与 TF-PSA-Crypto 的关系密码学操作的威胁模型边界SECURITY.md 的Use of TF-PSA-Crypto一节强调Mbed TLS 使用 TF-PSA-Crypto 提供的密码学 APITF-PSA-Crypto 的威胁模型适用于 Mbed TLS 执行的所有密码学操作。特别地文档提醒 Mbed TLS 用户注意其中关于分组密码block ciphers的考量——因为分组密码正是 TLS 中使用的类型那部分的威胁模型约束直接作用于 TLS 的密码处理。这一结构在仓库中可以直接印证。docs/4.0-migration-guide.md 说明了 4.0 的重大变化Mbed TLS has been split between two products: TF-PSA-Crypto for cryptography, and Mbed TLS for X.509 and (D)TLS即 Mbed TLS 被拆分为 TF-PSA-Crypto密码学与 Mbed TLSX.509 和 (D)TLS两个产品Mbed TLS 以子模块方式消费 TF-PSA-Crypto。仓库根目录下的tf-psa-crypto/目录正是该子模块的挂载点。对使用者的实际含义是评估 Mbed TLS 的密码学安全性时不能只看本仓库的 SECURITY.md还必须把 TF-PSA-Crypto 的威胁模型一并纳入尤其是其中对分组密码实现如常量时间性、故障注入防护的说明。四、威胁模型按攻击者能力分级SECURITY.md 的Threat model部分按攻击者能力将攻击分为三类远程攻击、本地攻击、物理攻击。下面逐类展开 Mbed TLS 对每一类的承诺。4.1 远程攻击目标是完全防护攻击者定义能够观察并修改网络上发送的数据包括观察单个数据包的内容与时间、抑制或延迟合法消息、注入消息。Mbed TLS 的立场目标是完全防护远程攻击并让用户应用能够提供完整的远程攻击防护但安全保证以所实现协议自身提供的安全保证为上限。文档举了一个典型例子Mbed TLS 单独无法保证消息不延迟送达因为 TLS 协议本身也不保证这一点。换言之Mbed TLS 在远程攻击这一层是全力防护 协议能力为天花板。4.2 本地攻击防护有限且不承诺本地攻击者定义能在同一台机器上运行软件但权限不足以直接访问 Mbed TLS 的内存和文件等资产。此类攻击进一步细分为三种。4.2.1 时序攻击Timing attacks攻击者利用共享硬件Mbed TLS 与攻击者都可访问的 CPU 资源观察 Mbed TLS 执行的指令时序典型攻击向量包括缓存时序、内存总线争用、分支预测。Mbed TLS 在此处只做有限防护limited protection原因和目标在文档中说得非常直白防护成本随测量粒度与噪声水平差异很大因此防护只能有限目标是仅防护公开记录在案的已公开攻击技术publicly documented attack techniques攻击在进步防护也在进步。Mbed TLS 正朝着完全时序无关fully timing-invariant代码的模型演进但尚未达到。这一承诺在源码中可以得到印证Mbed TLS 在敏感比较处显式使用常量时间函数。以 TLS 1.2 重协商时的 verify-data 校验为例ssl_tls12_client.c 中/* Check verify-data in constant-time. The length OTOH is no secret */ if (len ! 1 ssl-verify_data_len * 2 || buf[0] ! ssl-verify_data_len * 2 || mbedtls_ct_memcmp(buf 1, ssl-own_verify_data, ssl-verify_data_len) ! 0 || mbedtls_ct_memcmp(buf 1 ssl-verify_data_len, ssl-peer_verify_data, ssl-verify_data_len) ! 0) {这里对敏感的 verify-data 使用mbedtls_ct_memcmp常量时间内存比较而非普通memcmp同时代码注释明确长度本身不是秘密——这正是针对已公开时序攻击技术做定点防护这一策略的微观体现。服务端 ssl_tls12_server.c 中有完全对应的实现。此外tests/suites/下存在 test_suite_constant_time_hmac.function 等测试套件用于对常量时间行为进行回归验证。文档中还特别指出时序信息也可能通过网络或物理旁路观察到——远程时序攻击归入远程攻击一节讨论物理时序攻击归入物理攻击一节讨论。4.2.2 本地非时序旁路Local non-timing side channels攻击者代码可以通过平台上某种传感器拾取 Mbed TLS 运行时的硬件物理状态信息。文档举例平台上一个恰好位置不当的模数转换器ADC拾取了 CPU 噪声。Mbed TLS 的立场明确不对本地非时序旁路攻击提供任何安全保证。如果用户用例的威胁模型中存在此类攻击必须由平台侧缓解。4.2.3 本地故障注入Local fault injection attacks同一硬件上运行的软件可以影响设备物理状态并引入故障。Mbed TLS 同样不提供针对本地故障注入的安全保证需由平台缓解。4.3 物理攻击明确不承诺攻击者定义能获取 Mbed TLS 所运行硬件的物理信息和/或能改变硬件的物理状态例如功耗分析、电磁辐射、故障注入。Mbed TLS 的立场不针对物理攻击提供任何安全保证。若威胁模型中存在物理攻击必须由物理反制措施physical countermeasures来缓解。这对嵌入式场景是重要提示如果你依赖硬件安全模块或物理加固来做物理防护Mbed TLS 不会成为缺口但也不会替你兜底。五、Caveats三条容易被忽略的重要注意事项SECURITY.md 的Caveats部分给出了三条边界说明每一条都直接影响工程实践。5.1 编译器引入的时序旁路Compiler-induced side channelsMbed TLS 主体用 C 编写使用标准 C已知编译器例外除外因此不预期编译器会引入直接漏洞。但编译器可能在意图为常量时间的代码中引入时序旁路。Mbed TLS 包含防止这一点的反制措施但鉴于编译器、编译选项和目标平台的多样性这种防护可能不完整。文档给出了明确的编译建议推荐使用常见优化级别编译如-O2或-Os若常见编译器 常见优化级别下出现可利用的时序旁路Mbed TLS 通常会将其视为漏洞-O3、-Oz更高级别通常仍然安全但审查程度更低less scrutinized不推荐单独使用可能引入数据依赖时序的个别选项且 Mbed TLS 不会为不属于常见优化级别的此类优化做适配。工程含义如果你用非标准的编译选项组合构建 Mbed TLS如某些编译器私有标志时序安全性承诺的适用性会打折扣。5.2 范围外的反制措施Out-of-scope countermeasuresMbed TLS 是有机生长evolved organically的项目威胁模型并非从一开始就清晰定义。因此代码中可能存在针对威胁模型之外攻击的反制措施。两条关键结论这些反制措施的存在不代表Mbed TLS 对其威胁模型之外的某一类攻击提供防护这类反制措施的失效也不被视为漏洞。这避免了某处代码看起来像防护于是把它当安全承诺的误读。5.3 X.509 数据的格式处理Formatting of X509 data这一节讨论 Mbed TLS 处理 X.509 对象证书、证书签名请求 CSR、证书吊销列表 CRL的局限对 CA 场景尤其重要Mbed TLS 不校验对象严格符合 X.509 及其他相关标准。对已签名的证书与 CRL假设签名方已做过合规校验签名正确则信任其格式正确CSR 同样被隐式信任为标准合规的明确警告除非额外独立地执行合规性校验否则不得用 Mbed TLS 去签署不可信的 CSR 或 CRL。因此 Mbed TLS 单独使用不适合直接充当证书颁发机构CA但 Mbed TLS 承诺在解析证书、CSR、CRL 时防护内存破坏和其他未定义行为。如果一个 CSR 或签名证书在解析时触发未定义行为即被视为安全漏洞。这一条给出了清晰的使用边界Mbed TLS 的 X.509 定位是安全地解析与信任链验证而非完整的 CA 签发流水线。六、把威胁模型落到工程决策一份速查表综合 SECURITY.md 的承诺矩阵可以为不同部署场景直接得出结论威胁类型Mbed TLS 的承诺谁来兜底远程攻击窃听/篡改/注入/时序观测全力防护以协议保证为上限Mbed TLS 用户应用本地时序攻击有限防护仅针对已公开攻击技术朝 fully timing-invariant 演进Mbed TLS有限本地非时序旁路无保证平台本地故障注入无保证平台物理攻击功耗/辐射/物理故障注入无保证物理反制措施解析恶意 X.509 对象导致的内存破坏/UB有保证UB 即漏洞Mbed TLS签署不可信 CSR/CRL不保证需额外校验单独不适合做 CA上层 CA 软件密码学原语本身的威胁模型适用 TF-PSA-Crypto 威胁模型需一并评估配合前文的两点行动建议版本侧始终使用维护分支的最新版本当前维护分支见 BRANCHES.mdmain、development、LTS 的mbedtls-3.6至 2027-03、mbedtls-4.1至 2029-03避免停留在archive/归档分支构建侧使用-O2或-Os这类常见优化级别编译保持时序防护承诺在承诺范围内生效。七、小结SECURITY.md 的价值在于把 Mbed TLS 的安全承诺写得没有任何模糊空间远程攻击全力防护、本地时序攻击有限防护且目标明确、本地非时序旁路与物理攻击明确不承诺、X.509 解析保证无未定义行为但不保证严格标准合规、漏洞统一走 mbed-tls-securitylists.trustedfirmware.org、安全修复只进维护分支。源码层面的常量时间比较函数如 ssl_tls12_client.c 中的mbedtls_ct_memcmp、针对常量时间行为的测试套件、以及ChangeLog.d/中的安全修复记录都与这份文档的承诺相互印证。把这份威胁模型当作选型与加固清单使用是安全使用 Mbed TLS 的第一步。【免费下载链接】mbedtlsAn open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.项目地址: https://gitcode.com/GitHub_Trending/mb/mbedtls创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Mbed TLS 安全模型详解：威胁模型、漏洞报告流程与分支维护策略
Mbed TLS 安全模型详解威胁模型、漏洞报告流程与分支维护策略【免费下载链接】mbedtlsAn open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.项目地址: https://gitcode.com/GitHub_Trending/mb/mbedtlsMbed TLS 作为广泛使用的开源 TLS 库其安全性承诺的边界比支持哪些算法更关键它防哪些攻击、不防哪些攻击、漏洞该报给谁、哪些分支会收到安全修复。本文以仓库根目录的 SECURITY.md 为主体结合 BRANCHES.md 的分支维护策略与源码中的常量时间constant-time实现证据完整解析 Mbed TLS 的威胁模型threat model、漏洞报告通道和 X.509 解析的安全边界。读完后你能够为自己的项目准确划定 Mbed TLS 的安全保证范围并知道如何正确地上报漏洞与选择受支持的版本分支。一、漏洞如何报告安全团队的报告通道与事件处理目标根据 SECURITY.md 的Reporting Vulnerabilities一节如果你认为发现了一个 Mbed TLS 安全漏洞应通过电子邮件将其发送至安全团队mbed-tls-securitylists.trustedfirmware.org安全事件的处理流程Security Incident Handling Process则详细说明在项目在线文档的 vulnerability 处理页面中。该流程的首要目标是确保当问题公开时修复方案已经准备好可以部署fixes ready to be deployed when the issue goes public——这也是 Mbed TLS 安全响应的基本方针公开披露前修复必须就绪而不是先公开再修。这一承诺在仓库中是有迹可循的。例如 ChangeLog.d/serialized-data-load-hardening.txt 记录的是一类典型的内存越界读取型缺陷修复Reject serialized TLS 1.2 sessions whose session ID length exceeds 32, instead of accepting an out-of-range length that is later used to read past the end of the 32-byte session ID buffer.这类改动会进入ChangeLog.d/待发布变更说明并在修复就绪后随版本一起公开与修复先于公开的事件处理目标一致。二、哪些分支会收到安全修复只有维护中的分支SECURITY.md 明确指出只有维护中的分支maintained branches才会获得安全修复并强烈建议用户始终使用维护分支的最新版本。维护分支的完整清单定义在 BRANCHES.md 中当前仓库4.2.0 版本线见 build_info.h 中的MBEDTLS_VERSION_STRING 4.2.0对应以下分支格局分支性质修复策略main始终包含最新 release 及所有已公开的安全修复功能 Bug 修复 安全修复development准备下一个 4.x 小版本新功能 Bug 修复 安全修复mbedtls-3.6LTS 长期支持分支2024 年 3 月发布仅 Bug 修复 安全修复支持到 2027 年 3 月mbedtls-4.1首个 4.x LTS2026 年 3 月发布仅 Bug 修复 安全修复支持到 2029 年 3 月需要注意的边界同样来自 BRANCHES.md归档分支不再获得任何更新以archive/为前缀的历史分支如archive/mbedtls-2.7将不会收到任何变更自然也收不到安全修复。如果你的系统仍在跑这类老版本升级本身就是最大的安全动作。LTS 分支的额外约束LTS 分支除修复外还会尽量维持 ABI 兼容避免代码体积/RAM 占用增长但若与修复安全问题冲突安全优先——且会提供兼容选项。因此是否还会收到安全修复这个问题可以用一条简单的判断规则回答分支名不带archive/前缀、且在 BRANCHES.md 的维护清单里才会收到安全修复。三、与 TF-PSA-Crypto 的关系密码学操作的威胁模型边界SECURITY.md 的Use of TF-PSA-Crypto一节强调Mbed TLS 使用 TF-PSA-Crypto 提供的密码学 APITF-PSA-Crypto 的威胁模型适用于 Mbed TLS 执行的所有密码学操作。特别地文档提醒 Mbed TLS 用户注意其中关于分组密码block ciphers的考量——因为分组密码正是 TLS 中使用的类型那部分的威胁模型约束直接作用于 TLS 的密码处理。这一结构在仓库中可以直接印证。docs/4.0-migration-guide.md 说明了 4.0 的重大变化Mbed TLS has been split between two products: TF-PSA-Crypto for cryptography, and Mbed TLS for X.509 and (D)TLS即 Mbed TLS 被拆分为 TF-PSA-Crypto密码学与 Mbed TLSX.509 和 (D)TLS两个产品Mbed TLS 以子模块方式消费 TF-PSA-Crypto。仓库根目录下的tf-psa-crypto/目录正是该子模块的挂载点。对使用者的实际含义是评估 Mbed TLS 的密码学安全性时不能只看本仓库的 SECURITY.md还必须把 TF-PSA-Crypto 的威胁模型一并纳入尤其是其中对分组密码实现如常量时间性、故障注入防护的说明。四、威胁模型按攻击者能力分级SECURITY.md 的Threat model部分按攻击者能力将攻击分为三类远程攻击、本地攻击、物理攻击。下面逐类展开 Mbed TLS 对每一类的承诺。4.1 远程攻击目标是完全防护攻击者定义能够观察并修改网络上发送的数据包括观察单个数据包的内容与时间、抑制或延迟合法消息、注入消息。Mbed TLS 的立场目标是完全防护远程攻击并让用户应用能够提供完整的远程攻击防护但安全保证以所实现协议自身提供的安全保证为上限。文档举了一个典型例子Mbed TLS 单独无法保证消息不延迟送达因为 TLS 协议本身也不保证这一点。换言之Mbed TLS 在远程攻击这一层是全力防护 协议能力为天花板。4.2 本地攻击防护有限且不承诺本地攻击者定义能在同一台机器上运行软件但权限不足以直接访问 Mbed TLS 的内存和文件等资产。此类攻击进一步细分为三种。4.2.1 时序攻击Timing attacks攻击者利用共享硬件Mbed TLS 与攻击者都可访问的 CPU 资源观察 Mbed TLS 执行的指令时序典型攻击向量包括缓存时序、内存总线争用、分支预测。Mbed TLS 在此处只做有限防护limited protection原因和目标在文档中说得非常直白防护成本随测量粒度与噪声水平差异很大因此防护只能有限目标是仅防护公开记录在案的已公开攻击技术publicly documented attack techniques攻击在进步防护也在进步。Mbed TLS 正朝着完全时序无关fully timing-invariant代码的模型演进但尚未达到。这一承诺在源码中可以得到印证Mbed TLS 在敏感比较处显式使用常量时间函数。以 TLS 1.2 重协商时的 verify-data 校验为例ssl_tls12_client.c 中/* Check verify-data in constant-time. The length OTOH is no secret */ if (len ! 1 ssl-verify_data_len * 2 || buf[0] ! ssl-verify_data_len * 2 || mbedtls_ct_memcmp(buf 1, ssl-own_verify_data, ssl-verify_data_len) ! 0 || mbedtls_ct_memcmp(buf 1 ssl-verify_data_len, ssl-peer_verify_data, ssl-verify_data_len) ! 0) {这里对敏感的 verify-data 使用mbedtls_ct_memcmp常量时间内存比较而非普通memcmp同时代码注释明确长度本身不是秘密——这正是针对已公开时序攻击技术做定点防护这一策略的微观体现。服务端 ssl_tls12_server.c 中有完全对应的实现。此外tests/suites/下存在 test_suite_constant_time_hmac.function 等测试套件用于对常量时间行为进行回归验证。文档中还特别指出时序信息也可能通过网络或物理旁路观察到——远程时序攻击归入远程攻击一节讨论物理时序攻击归入物理攻击一节讨论。4.2.2 本地非时序旁路Local non-timing side channels攻击者代码可以通过平台上某种传感器拾取 Mbed TLS 运行时的硬件物理状态信息。文档举例平台上一个恰好位置不当的模数转换器ADC拾取了 CPU 噪声。Mbed TLS 的立场明确不对本地非时序旁路攻击提供任何安全保证。如果用户用例的威胁模型中存在此类攻击必须由平台侧缓解。4.2.3 本地故障注入Local fault injection attacks同一硬件上运行的软件可以影响设备物理状态并引入故障。Mbed TLS 同样不提供针对本地故障注入的安全保证需由平台缓解。4.3 物理攻击明确不承诺攻击者定义能获取 Mbed TLS 所运行硬件的物理信息和/或能改变硬件的物理状态例如功耗分析、电磁辐射、故障注入。Mbed TLS 的立场不针对物理攻击提供任何安全保证。若威胁模型中存在物理攻击必须由物理反制措施physical countermeasures来缓解。这对嵌入式场景是重要提示如果你依赖硬件安全模块或物理加固来做物理防护Mbed TLS 不会成为缺口但也不会替你兜底。五、Caveats三条容易被忽略的重要注意事项SECURITY.md 的Caveats部分给出了三条边界说明每一条都直接影响工程实践。5.1 编译器引入的时序旁路Compiler-induced side channelsMbed TLS 主体用 C 编写使用标准 C已知编译器例外除外因此不预期编译器会引入直接漏洞。但编译器可能在意图为常量时间的代码中引入时序旁路。Mbed TLS 包含防止这一点的反制措施但鉴于编译器、编译选项和目标平台的多样性这种防护可能不完整。文档给出了明确的编译建议推荐使用常见优化级别编译如-O2或-Os若常见编译器 常见优化级别下出现可利用的时序旁路Mbed TLS 通常会将其视为漏洞-O3、-Oz更高级别通常仍然安全但审查程度更低less scrutinized不推荐单独使用可能引入数据依赖时序的个别选项且 Mbed TLS 不会为不属于常见优化级别的此类优化做适配。工程含义如果你用非标准的编译选项组合构建 Mbed TLS如某些编译器私有标志时序安全性承诺的适用性会打折扣。5.2 范围外的反制措施Out-of-scope countermeasuresMbed TLS 是有机生长evolved organically的项目威胁模型并非从一开始就清晰定义。因此代码中可能存在针对威胁模型之外攻击的反制措施。两条关键结论这些反制措施的存在不代表Mbed TLS 对其威胁模型之外的某一类攻击提供防护这类反制措施的失效也不被视为漏洞。这避免了某处代码看起来像防护于是把它当安全承诺的误读。5.3 X.509 数据的格式处理Formatting of X509 data这一节讨论 Mbed TLS 处理 X.509 对象证书、证书签名请求 CSR、证书吊销列表 CRL的局限对 CA 场景尤其重要Mbed TLS 不校验对象严格符合 X.509 及其他相关标准。对已签名的证书与 CRL假设签名方已做过合规校验签名正确则信任其格式正确CSR 同样被隐式信任为标准合规的明确警告除非额外独立地执行合规性校验否则不得用 Mbed TLS 去签署不可信的 CSR 或 CRL。因此 Mbed TLS 单独使用不适合直接充当证书颁发机构CA但 Mbed TLS 承诺在解析证书、CSR、CRL 时防护内存破坏和其他未定义行为。如果一个 CSR 或签名证书在解析时触发未定义行为即被视为安全漏洞。这一条给出了清晰的使用边界Mbed TLS 的 X.509 定位是安全地解析与信任链验证而非完整的 CA 签发流水线。六、把威胁模型落到工程决策一份速查表综合 SECURITY.md 的承诺矩阵可以为不同部署场景直接得出结论威胁类型Mbed TLS 的承诺谁来兜底远程攻击窃听/篡改/注入/时序观测全力防护以协议保证为上限Mbed TLS 用户应用本地时序攻击有限防护仅针对已公开攻击技术朝 fully timing-invariant 演进Mbed TLS有限本地非时序旁路无保证平台本地故障注入无保证平台物理攻击功耗/辐射/物理故障注入无保证物理反制措施解析恶意 X.509 对象导致的内存破坏/UB有保证UB 即漏洞Mbed TLS签署不可信 CSR/CRL不保证需额外校验单独不适合做 CA上层 CA 软件密码学原语本身的威胁模型适用 TF-PSA-Crypto 威胁模型需一并评估配合前文的两点行动建议版本侧始终使用维护分支的最新版本当前维护分支见 BRANCHES.mdmain、development、LTS 的mbedtls-3.6至 2027-03、mbedtls-4.1至 2029-03避免停留在archive/归档分支构建侧使用-O2或-Os这类常见优化级别编译保持时序防护承诺在承诺范围内生效。七、小结SECURITY.md 的价值在于把 Mbed TLS 的安全承诺写得没有任何模糊空间远程攻击全力防护、本地时序攻击有限防护且目标明确、本地非时序旁路与物理攻击明确不承诺、X.509 解析保证无未定义行为但不保证严格标准合规、漏洞统一走 mbed-tls-securitylists.trustedfirmware.org、安全修复只进维护分支。源码层面的常量时间比较函数如 ssl_tls12_client.c 中的mbedtls_ct_memcmp、针对常量时间行为的测试套件、以及ChangeLog.d/中的安全修复记录都与这份文档的承诺相互印证。把这份威胁模型当作选型与加固清单使用是安全使用 Mbed TLS 的第一步。【免费下载链接】mbedtlsAn open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.项目地址: https://gitcode.com/GitHub_Trending/mb/mbedtls创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考