尧图网站建设 
编程语言语言运行时标准库编译器并发编程【免费下载链接】otpErlang/OTP项目地址https://gitcode.com/gh_mirrors/ot/otp点击查看免费下载导读本文基于 Erlang/OTP 官方文档《TLS Hardening Guide》见 lib/ssl/doc/guides/ssl_hardening.md并结合ssl应用源码编写系统讲解如何加固由ssl应用配置的 TLS/DTLS 连接。你将掌握加密算法含后量子算法与密码套件的选择策略、TLS 1.3 与 TLS 1.2 的版本与密钥交换配置、客户端/服务器端证书验证verify_peer、verify_fun、CRL 吊销检查与 OCSP stapling 的完整配置方法并了解每项默认值的来源与安全权衡。Note安全性security与互操作性interoperability、安全性security与资源消耗resource consumption之间存在权衡。做此类取舍时必须做出知情决策并理解后果。本指南反映的是发布该指南的版本当前仓库为 OTP 30.0-rc0见 OTP_VERSION的默认状态除非特别说明使用旧版本可能需要更多配置才能达到相同效果。设计原则安全的默认值与不轻易变更的约定Erlang 的 TLS 实现ssl应用致力于提供安全默认值secure defaults。即便如此项目方也明确承诺不会在非 major 版本中随意更改默认值——这意味着升级 OTP 小版本时你的安全基线不会无声无息地漂移但跨大版本升级时必须重新审视配置例如下文提到的verify_peer默认值在 OTP 26.0 变更、reuse_sessions默认值在 OTP 29.0.6 变更。对带宽受限的嵌入式系统可配置使用 AES-CCM-88 字节认证标签密码套件以 64 位完整性替代 128 位完整性来换取开销下降。Warning启用任何被文档标记为 legacy遗留的功能都会降低应用安全性。WarningNSS Key Logging网络安全服务密钥日志格式是调试功能不应用于生产系统否则将破坏 TLS 协议的安全目的。加密算法Cryptographic Algorithms算法可用性取决于链接的 OpenSSLssl应用可用的加密算法取决于 Erlang/OTP 构建并链接的OpenSSL cryptolib 版本。配置supported_groups、signature_algs等算法选项时ssl应用会自动剔除底层 OpenSSL 不支持的算法。唯一的例外是ciphers选项用户提供的密码套件不会被自动按 crypto 支持过滤原因在于 pre TLS-1.3 的密码套件由多种算法组合而成、结构更复杂。此时应使用ssl:filter_cipher_suites/2手动剔除链接的 OpenSSL cryptolib 不支持的套件。从源码看filter_cipher_suites 的实现会合并用户过滤器与ssl_cipher:crypto_support_filters()返回的默认过滤器key exchange、cipher、MAC、PRF 四类然后调用ssl_cipher:filter_suites/2执行过滤。文档lib/ssl/src/ssl.erl明确指出ssl:filter_cipher_suites(Suites, [])等价于只应用 crypto 库支持过滤器这是最常见的用法。该函数自 OTP 20.3 起可用。%% 过滤掉当前 crypto 库不支持的套件 Suites0 ssl:cipher_suites(default, tlsv1.2), Suites ssl:filter_cipher_suites(Suites0, []).配套工具函数自 OTP 20.3 起ssl:prepend_cipher_suites/2将Preferred套件或筛选条件提到列表头部ssl:append_cipher_suites/2将Deferred套件或筛选条件沉到列表尾部。NoteTLS 协议本身用 Erlang 实现只有密码学原语来自 OpenSSL cryptolib。这缩小了出错面——排除了 C 程序中缓冲区溢出等指针类错误。算法选择权客户端偏好 vs 服务器偏好TLS 协议通常规定客户端的算法偏好决定算法选择。服务器选项honor_cipher_order可在所有 TLS 版本中覆盖此行为改为服务器偏好决定密码套件选择对 TLS-1.2 及更早版本honor_ecc_order对 ECC 曲线选择起同样作用默认false即遵循客户端偏好见 ssl.erl。签名算法Signature Algorithms两个独立配置项signature_algs配置 TLS 协议消息可接受的签名算法signature_algs_cert单独配置证书链签名可接受的算法。继承规则只指定signature_algs而未指定signature_algs_cert时signature_algs的值被隐式用于signature_algs_cert两者都未指定时证书签名按默认signature_algs校验另附 legacy SHA-1 算法见下。Note当前默认signature_algs会为signature_algs_cert附加允许使用 SHA-1 作为伪随机函数的签名算法用于证书签名而协议签名默认不允许 SHA-1。预计 2030 年之后移除——届时此类证书应当已被淘汰。ssl:signature_algs/2可列出可用签名算法ssl.erl 中给出了实际示例输出默认与全量列表均包含后量子算法1 ssl:signature_algs(default, tlsv1.3). [mldsa87,mldsa65,mldsa44,slh_dsa_shake_256f,slh_dsa_shake_256s, slh_dsa_sha2_256f,slh_dsa_sha2_256s,slh_dsa_shake_192f,slh_dsa_shake_192s, slh_dsa_sha2_192f,slh_dsa_sha2_192s,slh_dsa_shake_128f,slh_dsa_shake_128s, slh_dsa_sha2_128f,slh_dsa_sha2_128s,eddsa_ed25519,eddsa_ed448, ecdsa_secp521r1_sha512,ecdsa_secp384r1_sha384,ecdsa_secp256r1_sha256, ...]后量子算法Post Quantum Algorithms, PQCPQC 算法旨在抵御未来密码学相关量子计算机CRQC的攻击——它们预期能攻破 RSA、ECC 等经典算法。PQC 仅在 TLS-1.3 中可用。Note即便 CRQC 尚不存在启用 PQC 也能防御 harvest now, decrypt later先收割、后解密攻击——攻击者现在记录加密流量留待未来解密。PQC 通常比经典算法消耗更多计算量与网络带宽密钥尺寸、签名、密文都更大。密钥交换支持多种 ML-KEM 混合组。默认只提供x25519mlkem768——经典 X25519 与 ML-KEM-768 的混合兼顾当前安全性与未来量子抗性新算法实战考验较少。认证支持 ML-DSA 与 SLH-DSA 签名算法。ML-DSA 因签名更快、签名更小而更受青睐。使用 PQC 签名算法需要配套的 PQC 证书与密钥。隐私与完整性Privacy and IntegrityTLS-1.3 是相对前代协议的重大升级同时支持 TLS-1.3 与 TLS-1.2 需要包含两者的配置选项TLS 1.3 将握手从两轮往返2-RTT降为一轮1-RTT强制前向保密forward secrecy加密更多握手内容引入 0-RTT 会话恢复。协议本身在默认支持的 TLS-1.3 与 TLS-1.2 之间会阻止版本降级攻击其余仍可配置的 TLS 版本均为 legacy。DTLS-1.2UDP 之上的数据报 TLS功能与 TLS-1.2 类似但总是更不可靠可能像普通 UDP 一样丢失应用数据DTLS 运行在其他传输上可能实现但非开箱即用DTLS-1.3 目前不受支持。密码套件Cipher SuitesTLS-1.3 与旧版本不共享任何密码套件。要在ciphers选项中同时支持 TLS-1.3 与 TLS-1.2必须为两者各至少包含一个套件{versions, [tlsv1.3, tlsv1.2]}, {ciphers, ssl:cipher_suites(default, tlsv1.3) ssl:filter_cipher_suites(ssl:cipher_suites(default, tlsv1.2), [])}TLS 1.3 只使用现代 AEAD带关联数据的认证加密套件ssl应用的 TLS-1.2 默认值同样只使用 AEAD 套件。会话密钥更新Session Key Renewal重协商renegotiation选项只适用于 TLS-1.3 之前的版本。TLS-1.3 用密钥更新key update机制取代重协商——它只轮换会话密钥不允许在连接中途重协商密码套件或证书。服务器可用client_renegotiation选项完全禁用客户端发起的重协商避免 DoS 攻击面。默认值为true且默认情况下服务器通过在客户端发起的重协商之间强制 12 秒延迟来缓解滥用见 ssl.erl。注意禁用重协商可能因底层密码套件可加密消息数量有限导致长连接不可用。%% 服务器完全禁用客户端发起重协商 {client_renegotiation, false}TLS 1.2 会话恢复与客户端证书重要安全警告WarningTLS 1.2 会话恢复session ID 与 RFC 5077 ticket不将主密钥master secret绑定到握手转录。当要求客户端证书认证时此缺陷使连接易受Triple Handshake 攻击见 RFC 7627。该问题不适用于 TLS 1.3——TLS 1.3 将所有会话密钥绑定到完整转录。若 TLS 1.2 服务器使用{verify, verify_peer}要求客户端证书务必禁用会话恢复{verify, verify_peer}, {reuse_sessions, false}这消除了 Triple Handshake 攻击面代价是每次连接都要完整握手。需要同时具备双向认证与会话恢复的 TLS 1.2 部署推荐升级到 TLS 1.3——TLS 1.3 会话票据天然安全。注意此问题仅影响服务器角色。客户端设置verify_peer验证服务器不受影响。在上述场景下reuse_sessions的默认值自OTP 29.0.6起为false。密钥交换组Key Exchange GroupsTLS-1.3 将密钥交换算法与密码套件解耦通过supported_groups选项配置。TLS-1.2 则在密码套件之外还提供eccs、dh、dhfile等选项配置密钥交换dhDER 编码的 Diffie-Hellman 参数若指定则覆盖dhfiledhfilePEM 编码 DH 参数文件路径服务器协商使用 DH 密钥交换的套件时使用未指定则使用默认参数见 ssl.erl。TLS 1.3 移除了静态 RSA只支持临时 Diffie-Hellman——强制前向保密PFSssl应用的 TLS-1.2 默认值同样如此。预共享密钥Pre-Shared Keys, PSKWarning不要在 TLS 1.2 与 TLS 1.3 之间共用同一个 PSK这被认为不安全。TLS-1.2PSK 由 PSK 密码套件支持除非与 DHE 或 ECDHE 组合通常缺乏前向保密TLS-1.3PSK 最常与密钥交换算法配合使用以提供前向保密纯 PSK 选项仍然存在。PSK 相关选项包括客户端的psk_identity指定身份与服务器的psk_identity身份提示匹配密钥由user_lookup_fun选项提供的 fun 完成。早数据Early Data, 0-RTTTLS-1.3 的早数据不具备前向保密且易受重放攻击。服务器选项early_data默认禁用disabled见 ssl.erl。Warning只有应用能安全处理重放请求时才启用早数据例如幂等的 HTTP 方法。%% 显式保持禁用默认值 {early_data, disabled}相关缓解策略与示例参见 Early Data in TLS-1.3。源码同时说明ssl.erl0-RTT 数据在 TLS 1.3 设计上天然可重放缓解手段是应用层幂等性或服务器端反重放——有状态票据或带 Bloom 过滤器的无状态票据anti_replay选项支持10k | 100k或自定义 Bloom 过滤器三元组。真实性Authenticity证书验证证书验证是建立 TLS 连接信任的关键。ssl应用提供多种机制定制与强化证书校验。证书与密钥Certificate and Keys使用certs_keys选项可为一个客户端或服务器配置多套候选证书握手时选择与对端最兼容的最佳一份。验证函数Verify Functionverify_fun选项允许为 TLS 客户端和服务器定制证书路径验证在标准链验证之外附加应用特定检查。Warningverify_fun也可被用来接受某些错误。这样做风险自负会削弱应用的安全属性。legacy 客户端verify选项取verify_none时通过一个特殊verify_fun跳过所有证书验证错误只应用于测试与调试。Note服务器端默认verify_none——客户端认证是协议的可选特性需要显式配置。当配置客户端认证verify设为verify_peer时服务器 legacy 选项fail_if_no_peer_cert默认为true自 OTP 26.0 起见 ssl.erl即客户端未提供证书发送空证书时服务器直接失败。实践总结客户端始终使用verify_peer自 OTP 26 起为默认值见 ssl.erl除非有把握排除的边缘情况变通方案不要在verify_fun中接受{bad_cert, _}错误服务器启用客户端认证时确保fail_if_no_peer_cert为true自 OTP 26 起为默认。%% 客户端验证服务器证书OTP 26 默认建议显式写出 ssl:connect(Host, Port, [{verify, verify_peer}, {cacerts, public_key:cacerts_get()}]).证书吊销验证Certificate Revocation Verification吊销验证对安全很重要、必须执行但它需要应用特定知识才能正确配置因此crl_check默认为false见 ssl.erl。取值含义false不执行检查默认true验证整条证书链peer仅验证对端证书best_effortlegacy 且不安全——无法确定吊销状态时静默接受证书见 ssl.erl。%% 验证整条链的 CRL {crl_check, true}, %% 或仅检查对端证书 {crl_check, peer}CRL 实现基于public_key:pkix_crls_validate/3在路径验证public_key:pkix_path_validation/3期间执行。CRL 缓存机制内置 CRL 缓存可通过ssl_crl_cache:insert/1支持{file, Filename}与{der, [DER]}两种来源见 ssl_crl_cache.erl预填充也可配置为从证书中的 HTTP 分发点抓取 CRL自定义 CRL 源实现ssl_crl_cache_apibehaviourssl_crl_cache_api.erl。核心回调包括lookup/3按分发点与签发者查找 CRL、select/2按签发者或通用名选择 CRL、fresh_crl/2供public_key:pkix_crls_validate/3的update_crl选项使用自 OTP 22.2 起可返回 logger 信息用于日志事件。OCSP stapling客户端可用stapling选项请求服务器 OCSP stapling默认no_staple禁用见 ssl.erlTLS-1.2 只支持端实体证书end-entitystaplingTLS-1.3 支持更完整服务器未提供 staple 时连接默认以{bad_cert, missing_ocsp_staple}失败自定义verify_fun可拦截该错误以实现回退吊销检查如直接抓取 CRL。Warning不执行替代吊销检查就接受{bad_cert, missing_ocsp_staple}是不安全的——MITM 攻击者可通过省略 staple 来压制吊销信息。Notessl应用不执行直接 OCSP 查询客户端经证书 AIA 扩展联系 OCSP 响应者只支持客户端验证OCSP stapling握手期间服务器提供的响应。Erlang 服务器端无 stapling 支持。此外OCSP 支持似乎在衰落——例如 Lets Encrypt 已放弃 OCSP。源码给出了verify_fun拦截missing_ocsp_staple的完整模式ssl.erl{verify_fun, {fun(_, _, {bad_cert, missing_ocsp_staple} R, _St) - %% 在此实现回退吊销检查如直接 OCSP 查询或 CRL 检查。 %% 直接返回 {valid, St} 会完全跳过吊销检查。 {fail, R}; (_, _, {bad_cert, _} R, _) - {fail, R}; (_, _, {valid, _} _, St) - {valid, St} end, []}}加固检查清单速查结合本文全部内容可将以下配置作为 TLS 加固基线参考按自身场景取舍版本{versions, [tlsv1.3, tlsv1.2]}不要配置 legacy 版本客户端验证{verify, verify_peer}OTP 26 默认提供可信 CAcacerts服务器客户端认证{verify, verify_peer}{fail_if_no_peer_cert, true}OTP 26 默认TLS 1.2 服务器 双向认证{reuse_sessions, false}OTP 29.0.6 默认或升级 TLS 1.3密码套件ssl:filter_cipher_suites(ssl:cipher_suites(default, Vsn), [])过滤不支持套件TLS-1.3 与 TLS-1.2 各至少保留一个吊销检查按需设{crl_check, true | peer}启用stapling并用verify_fun实现回退检查best_effort视为不安全早数据默认disabled仅在应用幂等时启用重协商按 DoS 防护需要设{client_renegotiation, false}TLS-1.2 及更早后量子TLS-1.3 下默认提供x25519mlkem768混合组PQC 签名算法需配套 PQC 证书与密钥。延伸阅读SSL 用户指南使用指南包含密码套件定制Customizing cipher suites、TLS-1.3 早数据等主题的完整示例ssl 模块 API 文档含全部选项类型common_option_tls13/0、server_option_pre_tls13/0、common_option_cert/0等类型定义与默认值说明ssl_crl_cache 默认 CRL 缓存实现 与 ssl_crl_cache_api behaviour自定义 CRL 源的接入点SSL 测试套件可在仓库中查阅各选项的测试用例作为行为佐证。赞分享编程语言语言运行时标准库编译器并发编程【免费下载链接】otpErlang/OTP项目地址https://gitcode.com/gh_mirrors/ot/otp点击查看免费下载相关推荐Erlang/OTP SSL 应用 TLS/DTLS 协议全景解析握手、证书、会话与安全机制Erlang/OTP SSL 应用 TLS/DTLS 协议全景解析握手、证书、会话与安全机制 本文围绕 Erlang/OTP 中 ssl 应用对 TLS/DT编程语言语言运行时标准库编译器并发编程CloudNativePG 客户端 TLS/SSL 证书认证实战签发证书、验证连接与协议版本调优CloudNativePG 客户端 TLS/SSL 证书认证实战签发证书、验证连接与协议版本调优 CloudNativePG 在设计之初就将 TLS/SSL云原生数据库高可用灾备容器编排RPCS3汉化补丁怎么装文件命名是成败关键RPCS3汉化补丁怎么装文件命名是成败关键 在RPCS3里给PS3游戏打汉化补丁真正决定成败的只有一件事补丁文件放在哪、叫什么名字。走哪条路看你手头的补丁虚拟化图形学调试器上一篇Ultra-Fast-Lane-Detection-v2 项目常见问题解决方案下一篇Streamlit-Extras 项目常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Erlang/OTP ssl 应用 TLS 加固指南：算法选择、协议版本与证书验证的完整实战
编程语言语言运行时标准库编译器并发编程【免费下载链接】otpErlang/OTP项目地址https://gitcode.com/gh_mirrors/ot/otp点击查看免费下载导读本文基于 Erlang/OTP 官方文档《TLS Hardening Guide》见 lib/ssl/doc/guides/ssl_hardening.md并结合ssl应用源码编写系统讲解如何加固由ssl应用配置的 TLS/DTLS 连接。你将掌握加密算法含后量子算法与密码套件的选择策略、TLS 1.3 与 TLS 1.2 的版本与密钥交换配置、客户端/服务器端证书验证verify_peer、verify_fun、CRL 吊销检查与 OCSP stapling 的完整配置方法并了解每项默认值的来源与安全权衡。Note安全性security与互操作性interoperability、安全性security与资源消耗resource consumption之间存在权衡。做此类取舍时必须做出知情决策并理解后果。本指南反映的是发布该指南的版本当前仓库为 OTP 30.0-rc0见 OTP_VERSION的默认状态除非特别说明使用旧版本可能需要更多配置才能达到相同效果。设计原则安全的默认值与不轻易变更的约定Erlang 的 TLS 实现ssl应用致力于提供安全默认值secure defaults。即便如此项目方也明确承诺不会在非 major 版本中随意更改默认值——这意味着升级 OTP 小版本时你的安全基线不会无声无息地漂移但跨大版本升级时必须重新审视配置例如下文提到的verify_peer默认值在 OTP 26.0 变更、reuse_sessions默认值在 OTP 29.0.6 变更。对带宽受限的嵌入式系统可配置使用 AES-CCM-88 字节认证标签密码套件以 64 位完整性替代 128 位完整性来换取开销下降。Warning启用任何被文档标记为 legacy遗留的功能都会降低应用安全性。WarningNSS Key Logging网络安全服务密钥日志格式是调试功能不应用于生产系统否则将破坏 TLS 协议的安全目的。加密算法Cryptographic Algorithms算法可用性取决于链接的 OpenSSLssl应用可用的加密算法取决于 Erlang/OTP 构建并链接的OpenSSL cryptolib 版本。配置supported_groups、signature_algs等算法选项时ssl应用会自动剔除底层 OpenSSL 不支持的算法。唯一的例外是ciphers选项用户提供的密码套件不会被自动按 crypto 支持过滤原因在于 pre TLS-1.3 的密码套件由多种算法组合而成、结构更复杂。此时应使用ssl:filter_cipher_suites/2手动剔除链接的 OpenSSL cryptolib 不支持的套件。从源码看filter_cipher_suites 的实现会合并用户过滤器与ssl_cipher:crypto_support_filters()返回的默认过滤器key exchange、cipher、MAC、PRF 四类然后调用ssl_cipher:filter_suites/2执行过滤。文档lib/ssl/src/ssl.erl明确指出ssl:filter_cipher_suites(Suites, [])等价于只应用 crypto 库支持过滤器这是最常见的用法。该函数自 OTP 20.3 起可用。%% 过滤掉当前 crypto 库不支持的套件 Suites0 ssl:cipher_suites(default, tlsv1.2), Suites ssl:filter_cipher_suites(Suites0, []).配套工具函数自 OTP 20.3 起ssl:prepend_cipher_suites/2将Preferred套件或筛选条件提到列表头部ssl:append_cipher_suites/2将Deferred套件或筛选条件沉到列表尾部。NoteTLS 协议本身用 Erlang 实现只有密码学原语来自 OpenSSL cryptolib。这缩小了出错面——排除了 C 程序中缓冲区溢出等指针类错误。算法选择权客户端偏好 vs 服务器偏好TLS 协议通常规定客户端的算法偏好决定算法选择。服务器选项honor_cipher_order可在所有 TLS 版本中覆盖此行为改为服务器偏好决定密码套件选择对 TLS-1.2 及更早版本honor_ecc_order对 ECC 曲线选择起同样作用默认false即遵循客户端偏好见 ssl.erl。签名算法Signature Algorithms两个独立配置项signature_algs配置 TLS 协议消息可接受的签名算法signature_algs_cert单独配置证书链签名可接受的算法。继承规则只指定signature_algs而未指定signature_algs_cert时signature_algs的值被隐式用于signature_algs_cert两者都未指定时证书签名按默认signature_algs校验另附 legacy SHA-1 算法见下。Note当前默认signature_algs会为signature_algs_cert附加允许使用 SHA-1 作为伪随机函数的签名算法用于证书签名而协议签名默认不允许 SHA-1。预计 2030 年之后移除——届时此类证书应当已被淘汰。ssl:signature_algs/2可列出可用签名算法ssl.erl 中给出了实际示例输出默认与全量列表均包含后量子算法1 ssl:signature_algs(default, tlsv1.3). [mldsa87,mldsa65,mldsa44,slh_dsa_shake_256f,slh_dsa_shake_256s, slh_dsa_sha2_256f,slh_dsa_sha2_256s,slh_dsa_shake_192f,slh_dsa_shake_192s, slh_dsa_sha2_192f,slh_dsa_sha2_192s,slh_dsa_shake_128f,slh_dsa_shake_128s, slh_dsa_sha2_128f,slh_dsa_sha2_128s,eddsa_ed25519,eddsa_ed448, ecdsa_secp521r1_sha512,ecdsa_secp384r1_sha384,ecdsa_secp256r1_sha256, ...]后量子算法Post Quantum Algorithms, PQCPQC 算法旨在抵御未来密码学相关量子计算机CRQC的攻击——它们预期能攻破 RSA、ECC 等经典算法。PQC 仅在 TLS-1.3 中可用。Note即便 CRQC 尚不存在启用 PQC 也能防御 harvest now, decrypt later先收割、后解密攻击——攻击者现在记录加密流量留待未来解密。PQC 通常比经典算法消耗更多计算量与网络带宽密钥尺寸、签名、密文都更大。密钥交换支持多种 ML-KEM 混合组。默认只提供x25519mlkem768——经典 X25519 与 ML-KEM-768 的混合兼顾当前安全性与未来量子抗性新算法实战考验较少。认证支持 ML-DSA 与 SLH-DSA 签名算法。ML-DSA 因签名更快、签名更小而更受青睐。使用 PQC 签名算法需要配套的 PQC 证书与密钥。隐私与完整性Privacy and IntegrityTLS-1.3 是相对前代协议的重大升级同时支持 TLS-1.3 与 TLS-1.2 需要包含两者的配置选项TLS 1.3 将握手从两轮往返2-RTT降为一轮1-RTT强制前向保密forward secrecy加密更多握手内容引入 0-RTT 会话恢复。协议本身在默认支持的 TLS-1.3 与 TLS-1.2 之间会阻止版本降级攻击其余仍可配置的 TLS 版本均为 legacy。DTLS-1.2UDP 之上的数据报 TLS功能与 TLS-1.2 类似但总是更不可靠可能像普通 UDP 一样丢失应用数据DTLS 运行在其他传输上可能实现但非开箱即用DTLS-1.3 目前不受支持。密码套件Cipher SuitesTLS-1.3 与旧版本不共享任何密码套件。要在ciphers选项中同时支持 TLS-1.3 与 TLS-1.2必须为两者各至少包含一个套件{versions, [tlsv1.3, tlsv1.2]}, {ciphers, ssl:cipher_suites(default, tlsv1.3) ssl:filter_cipher_suites(ssl:cipher_suites(default, tlsv1.2), [])}TLS 1.3 只使用现代 AEAD带关联数据的认证加密套件ssl应用的 TLS-1.2 默认值同样只使用 AEAD 套件。会话密钥更新Session Key Renewal重协商renegotiation选项只适用于 TLS-1.3 之前的版本。TLS-1.3 用密钥更新key update机制取代重协商——它只轮换会话密钥不允许在连接中途重协商密码套件或证书。服务器可用client_renegotiation选项完全禁用客户端发起的重协商避免 DoS 攻击面。默认值为true且默认情况下服务器通过在客户端发起的重协商之间强制 12 秒延迟来缓解滥用见 ssl.erl。注意禁用重协商可能因底层密码套件可加密消息数量有限导致长连接不可用。%% 服务器完全禁用客户端发起重协商 {client_renegotiation, false}TLS 1.2 会话恢复与客户端证书重要安全警告WarningTLS 1.2 会话恢复session ID 与 RFC 5077 ticket不将主密钥master secret绑定到握手转录。当要求客户端证书认证时此缺陷使连接易受Triple Handshake 攻击见 RFC 7627。该问题不适用于 TLS 1.3——TLS 1.3 将所有会话密钥绑定到完整转录。若 TLS 1.2 服务器使用{verify, verify_peer}要求客户端证书务必禁用会话恢复{verify, verify_peer}, {reuse_sessions, false}这消除了 Triple Handshake 攻击面代价是每次连接都要完整握手。需要同时具备双向认证与会话恢复的 TLS 1.2 部署推荐升级到 TLS 1.3——TLS 1.3 会话票据天然安全。注意此问题仅影响服务器角色。客户端设置verify_peer验证服务器不受影响。在上述场景下reuse_sessions的默认值自OTP 29.0.6起为false。密钥交换组Key Exchange GroupsTLS-1.3 将密钥交换算法与密码套件解耦通过supported_groups选项配置。TLS-1.2 则在密码套件之外还提供eccs、dh、dhfile等选项配置密钥交换dhDER 编码的 Diffie-Hellman 参数若指定则覆盖dhfiledhfilePEM 编码 DH 参数文件路径服务器协商使用 DH 密钥交换的套件时使用未指定则使用默认参数见 ssl.erl。TLS 1.3 移除了静态 RSA只支持临时 Diffie-Hellman——强制前向保密PFSssl应用的 TLS-1.2 默认值同样如此。预共享密钥Pre-Shared Keys, PSKWarning不要在 TLS 1.2 与 TLS 1.3 之间共用同一个 PSK这被认为不安全。TLS-1.2PSK 由 PSK 密码套件支持除非与 DHE 或 ECDHE 组合通常缺乏前向保密TLS-1.3PSK 最常与密钥交换算法配合使用以提供前向保密纯 PSK 选项仍然存在。PSK 相关选项包括客户端的psk_identity指定身份与服务器的psk_identity身份提示匹配密钥由user_lookup_fun选项提供的 fun 完成。早数据Early Data, 0-RTTTLS-1.3 的早数据不具备前向保密且易受重放攻击。服务器选项early_data默认禁用disabled见 ssl.erl。Warning只有应用能安全处理重放请求时才启用早数据例如幂等的 HTTP 方法。%% 显式保持禁用默认值 {early_data, disabled}相关缓解策略与示例参见 Early Data in TLS-1.3。源码同时说明ssl.erl0-RTT 数据在 TLS 1.3 设计上天然可重放缓解手段是应用层幂等性或服务器端反重放——有状态票据或带 Bloom 过滤器的无状态票据anti_replay选项支持10k | 100k或自定义 Bloom 过滤器三元组。真实性Authenticity证书验证证书验证是建立 TLS 连接信任的关键。ssl应用提供多种机制定制与强化证书校验。证书与密钥Certificate and Keys使用certs_keys选项可为一个客户端或服务器配置多套候选证书握手时选择与对端最兼容的最佳一份。验证函数Verify Functionverify_fun选项允许为 TLS 客户端和服务器定制证书路径验证在标准链验证之外附加应用特定检查。Warningverify_fun也可被用来接受某些错误。这样做风险自负会削弱应用的安全属性。legacy 客户端verify选项取verify_none时通过一个特殊verify_fun跳过所有证书验证错误只应用于测试与调试。Note服务器端默认verify_none——客户端认证是协议的可选特性需要显式配置。当配置客户端认证verify设为verify_peer时服务器 legacy 选项fail_if_no_peer_cert默认为true自 OTP 26.0 起见 ssl.erl即客户端未提供证书发送空证书时服务器直接失败。实践总结客户端始终使用verify_peer自 OTP 26 起为默认值见 ssl.erl除非有把握排除的边缘情况变通方案不要在verify_fun中接受{bad_cert, _}错误服务器启用客户端认证时确保fail_if_no_peer_cert为true自 OTP 26 起为默认。%% 客户端验证服务器证书OTP 26 默认建议显式写出 ssl:connect(Host, Port, [{verify, verify_peer}, {cacerts, public_key:cacerts_get()}]).证书吊销验证Certificate Revocation Verification吊销验证对安全很重要、必须执行但它需要应用特定知识才能正确配置因此crl_check默认为false见 ssl.erl。取值含义false不执行检查默认true验证整条证书链peer仅验证对端证书best_effortlegacy 且不安全——无法确定吊销状态时静默接受证书见 ssl.erl。%% 验证整条链的 CRL {crl_check, true}, %% 或仅检查对端证书 {crl_check, peer}CRL 实现基于public_key:pkix_crls_validate/3在路径验证public_key:pkix_path_validation/3期间执行。CRL 缓存机制内置 CRL 缓存可通过ssl_crl_cache:insert/1支持{file, Filename}与{der, [DER]}两种来源见 ssl_crl_cache.erl预填充也可配置为从证书中的 HTTP 分发点抓取 CRL自定义 CRL 源实现ssl_crl_cache_apibehaviourssl_crl_cache_api.erl。核心回调包括lookup/3按分发点与签发者查找 CRL、select/2按签发者或通用名选择 CRL、fresh_crl/2供public_key:pkix_crls_validate/3的update_crl选项使用自 OTP 22.2 起可返回 logger 信息用于日志事件。OCSP stapling客户端可用stapling选项请求服务器 OCSP stapling默认no_staple禁用见 ssl.erlTLS-1.2 只支持端实体证书end-entitystaplingTLS-1.3 支持更完整服务器未提供 staple 时连接默认以{bad_cert, missing_ocsp_staple}失败自定义verify_fun可拦截该错误以实现回退吊销检查如直接抓取 CRL。Warning不执行替代吊销检查就接受{bad_cert, missing_ocsp_staple}是不安全的——MITM 攻击者可通过省略 staple 来压制吊销信息。Notessl应用不执行直接 OCSP 查询客户端经证书 AIA 扩展联系 OCSP 响应者只支持客户端验证OCSP stapling握手期间服务器提供的响应。Erlang 服务器端无 stapling 支持。此外OCSP 支持似乎在衰落——例如 Lets Encrypt 已放弃 OCSP。源码给出了verify_fun拦截missing_ocsp_staple的完整模式ssl.erl{verify_fun, {fun(_, _, {bad_cert, missing_ocsp_staple} R, _St) - %% 在此实现回退吊销检查如直接 OCSP 查询或 CRL 检查。 %% 直接返回 {valid, St} 会完全跳过吊销检查。 {fail, R}; (_, _, {bad_cert, _} R, _) - {fail, R}; (_, _, {valid, _} _, St) - {valid, St} end, []}}加固检查清单速查结合本文全部内容可将以下配置作为 TLS 加固基线参考按自身场景取舍版本{versions, [tlsv1.3, tlsv1.2]}不要配置 legacy 版本客户端验证{verify, verify_peer}OTP 26 默认提供可信 CAcacerts服务器客户端认证{verify, verify_peer}{fail_if_no_peer_cert, true}OTP 26 默认TLS 1.2 服务器 双向认证{reuse_sessions, false}OTP 29.0.6 默认或升级 TLS 1.3密码套件ssl:filter_cipher_suites(ssl:cipher_suites(default, Vsn), [])过滤不支持套件TLS-1.3 与 TLS-1.2 各至少保留一个吊销检查按需设{crl_check, true | peer}启用stapling并用verify_fun实现回退检查best_effort视为不安全早数据默认disabled仅在应用幂等时启用重协商按 DoS 防护需要设{client_renegotiation, false}TLS-1.2 及更早后量子TLS-1.3 下默认提供x25519mlkem768混合组PQC 签名算法需配套 PQC 证书与密钥。延伸阅读SSL 用户指南使用指南包含密码套件定制Customizing cipher suites、TLS-1.3 早数据等主题的完整示例ssl 模块 API 文档含全部选项类型common_option_tls13/0、server_option_pre_tls13/0、common_option_cert/0等类型定义与默认值说明ssl_crl_cache 默认 CRL 缓存实现 与 ssl_crl_cache_api behaviour自定义 CRL 源的接入点SSL 测试套件可在仓库中查阅各选项的测试用例作为行为佐证。赞分享编程语言语言运行时标准库编译器并发编程【免费下载链接】otpErlang/OTP项目地址https://gitcode.com/gh_mirrors/ot/otp点击查看免费下载相关推荐Erlang/OTP SSL 应用 TLS/DTLS 协议全景解析握手、证书、会话与安全机制Erlang/OTP SSL 应用 TLS/DTLS 协议全景解析握手、证书、会话与安全机制 本文围绕 Erlang/OTP 中 ssl 应用对 TLS/DT编程语言语言运行时标准库编译器并发编程CloudNativePG 客户端 TLS/SSL 证书认证实战签发证书、验证连接与协议版本调优CloudNativePG 客户端 TLS/SSL 证书认证实战签发证书、验证连接与协议版本调优 CloudNativePG 在设计之初就将 TLS/SSL云原生数据库高可用灾备容器编排RPCS3汉化补丁怎么装文件命名是成败关键RPCS3汉化补丁怎么装文件命名是成败关键 在RPCS3里给PS3游戏打汉化补丁真正决定成败的只有一件事补丁文件放在哪、叫什么名字。走哪条路看你手头的补丁虚拟化图形学调试器上一篇Ultra-Fast-Lane-Detection-v2 项目常见问题解决方案下一篇Streamlit-Extras 项目常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考