尧图网站建设 
Envoy QUIC 下游连接新增 P-384 / P-521 ECDSA 叶子证书支持【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy导读本文基于 Envoy 仓库changelogs/current/new_features/quic__support-p384-p521-ecdsa-curves.rst的变更记录深入解读 Envoy 新增的对 QUICHTTP/3下游连接 P-384、P-521 ECDSA 叶子证书的支持。此前 Envoy 的 QUIC 下游握手仅接受 P-256 曲线签发的证书本次变更将其扩展为 P-256 / P-384 / P-521 三档曲线并配套提供名为envoy.reloadable_features.quic_support_additional_ecdsa_curves的运行时开关用于临时回退。读完本文你将掌握该能力的适用场景、底层签名算法推导逻辑、证书链选择机制以及如何通过运行时配置控制该行为。变更背景QUIC/TLS 1.3 握手与 ECDSA 签名曲线QUIC 传输层的 TLS 1.3 握手与证书体系完全复用 TLS 的 PKI。服务端在握手阶段向客户端出示证书链其中**叶子证书leaf certificate**携带的 ECDSA 公钥必须与 TLS 1.3 的签名算法SignatureScheme一一对应P-256secp256r1NID 为NID_X9_62_prime256v1对应SSL_SIGN_ECDSA_SECP256R1_SHA256P-384secp384r1NID 为NID_secp384r1对应SSL_SIGN_ECDSA_SECP384R1_SHA384P-521secp521r1NID 为NID_secp521r1对应SSL_SIGN_ECDSA_SECP521R1_SHA512。在本次变更之前Envoy 的 QUIC 下游downstream连接只支持 P-256 一种 ECDSA 曲线相较之下通用 TLS 下行路径source/common/tls/context_impl.cc早已支持 P-256、P-384、P-521 三种曲线见该文件中 We only support P-256, P-384 or P-521 ECDSA today. 的注释。因此本次变更本质上是将 TLS 路径已有的曲线能力对齐到 QUIC 路径让部署了 P-384 / P-521 证书的站点也能直接对外提供 HTTP/3 服务而无需为 QUIC 单独准备 P-256 证书。适用前提该能力作用于 Envoy 作为服务端接受的下行 QUIC 连接对应envoy.transport_sockets.quic的QuicDownstreamTransport场景不涉及上游upstream方向的证书签发。变更内容叶子证书支持曲线从 P-256 扩展至 P-256 / P-384 / P-521变更记录原文要点如下新增对P-384 与 P-521 ECDSA 叶子证书的支持用于 QUIC 下游连接原有的P-256支持保持不变可通过将运行时开关envoy.reloadable_features.quic_support_additional_ecdsa_curves设为false临时回退到旧行为仅 P-256。该开关在 runtime_features.cc 中以RUNTIME_GUARD(envoy_reloadable_features_quic_support_additional_ecdsa_curves)的形式注册属于标准的reloadable可热加载运行时功能开关——这意味着无需重启进程只需更新运行时配置即可生效适用于灰度发布期间临时关闭新能力的场景。源码级实现解析1.deduceSignatureAlgorithmFromPublicKey按证书曲线推导签名算法QUIC 路径的证书合法性校验与签名算法选择集中在 envoy_quic_utils.cc 的deduceSignatureAlgorithmFromPublicKey()函数中。其核心逻辑如下通过EVP_PKEY_id判断公钥类型对ECDSA公钥取出椭圆曲线群并获取曲线 NID然后按曲线分派签名算法NID_X9_62_prime256v1P-256恒返回SSL_SIGN_ECDSA_SECP256R1_SHA256NID_secp384r1P-384仅当开关envoy.reloadable_features.quic_support_additional_ecdsa_curves启用时返回SSL_SIGN_ECDSA_SECP384R1_SHA384否则返回 0NID_secp521r1P-521仅当开关启用时返回SSL_SIGN_ECDSA_SECP521R1_SHA512否则返回 0若推导结果签名算法为 0则设置错误信息。错误文案也随开关状态变化开关开启时报Invalid leaf cert, only P-256, P-384 or P-521 ECDSA certificates are supported关闭时报Invalid leaf cert, only P-256 ECDSA certificates are supported。该函数对RSA公钥同样做了处理要求 2048 位及以上FIPS 模式下仅允许 2048 / 3072 / 4096 位但本文聚焦 ECDSA 曲线扩展。该函数在 QUIC 路径中有三处调用点覆盖了服务端与客户端两侧的证书校验envoy_quic_proof_source.cc服务端 ProofSource 使用私钥推导签名算法用于实际签发握手签名envoy_quic_proof_verifier.cc对端证书验证时推导签名算法quic_server_transport_socket_factory.cc下游监听器创建 TLS 上下文时校验证书合法性。2. 证书链选择supported_curves与findTlsContext除了签名算法推导证书链的按曲线过滤逻辑位于 quic_server_transport_socket_factory.cc 的getTlsCertificateAndKey()const Ssl::CurveNIDVector supported_curves Runtime::runtimeFeatureEnabled( envoy.reloadable_features.quic_support_additional_ecdsa_curves) ? Ssl::CurveNIDVector{NID_X9_62_prime256v1, NID_secp384r1, NID_secp521r1} : Ssl::CurveNIDVector{NID_X9_62_prime256v1}; auto [tls_context, ocsp_staple_action] ctx-findTlsContext(sni, supported_curves, false /* TODO: ocsp_capable */, cert_matched_sni);可以看到开关开启时支持曲线集合为{P-256, P-384, P-521}三个 NID关闭时退化为仅{P-256}。该集合被传入ServerContextImpl::findTlsContext()用于在多证书含 SNI 匹配场景下挑选与客户端能力兼容的证书链进一步印证了开关对证书选择路径的完整约束。3. 签名算法推导与 ProofSource 的配合在 envoy_quic_proof_source.cc 中deduceSignatureAlgorithmFromPublicKey的返回值直接决定了服务端握手签名所采用的算法。若叶子证书曲线不被支持开关关闭时使用 P-384/P-521 证书推导返回 0 并携带错误信息握手将因此失败——这正是运维人员需要关注回退开关与证书曲线匹配关系的原因。运行时开关配置方式与回退场景envoy.reloadable_features.quic_support_additional_ecdsa_curves是一个布尔型 reloadable runtime guard默认值为true启用新能力。回退操作如下layered_runtime: layers: - name: static_layer_0 static_layer: envoy: reloadable_features: quic_support_additional_ecdsa_curves: false适用回退的典型场景升级到包含该变更的 Envoy 版本后若 P-384 / P-521 证书握手出现兼容性问题可先将开关置为false恢复旧行为仅 P-256排查并修复后再重新开启存量环境中若存在仅支持 P-256 的客户端或证书体系运维可在灰度窗口内保持旧行为以缩小变更面。需要留意的是回退期间所有 QUIC 下游连接仍严格要求叶子证书为 P-256若配置了 P-384 / P-521 证书且未匹配到 P-256 证书链握手仍会因签名算法推导失败而拒绝。实操为 QUIC 下游监听器配置 ECDSA 证书仓库中的示例配置 proxy_connect_udp_http3_downstream.yaml 展示了 QUIC 下游监听器的完整写法该示例用于将下行 CONNECT-UDP 请求转发至上游static_resources: listeners: - name: listener_0 address: socket_address: protocol: UDP address: 127.0.0.1 port_value: 10001 udp_listener_config: quic_options: {} downstream_socket_config: prefer_gro: true filter_chains: - transport_socket: name: envoy.transport_sockets.quic typed_config: type: type.googleapis.com/envoy.extensions.transport_sockets.quic.v3.QuicDownstreamTransport downstream_tls_context: common_tls_context: tls_certificates: - certificate_chain: filename: certs/servercert.pem private_key: filename: certs/serverkey.pem filters: - name: envoy.filters.network.http_connection_manager typed_config: type: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager codec_type: HTTP3 stat_prefix: ingress_http # ... 后续为 route_config 与 http_filters 配置要点解读下行 QUIC 监听器必须是UDPsocket并设置udp_listener_config.quic_options可传空对象{}启用默认 QUIC 选项filter chain 的 transport socket 使用envoy.transport_sockets.quic其type为QuicDownstreamTransport证书通过downstream_tls_context.common_tls_context.tls_certificates提供上层网络过滤器选择 HTTP/3HttpConnectionManager的codec_type设为HTTP3。基于本次变更该处的servercert.pem/serverkey.pem既可以是 P-256 证书也可以是 P-384 或 P-521 证书开关保持默认开启时。与通用 TLS 下行配置见 context_config_impl.cc 中默认曲线DEFAULT_CURVES P-256等定义相比QUIC 路径此前只能接受 P-256现在曲线支持范围已与 TLS 对齐。总结变更内容Envoy QUIC 下游连接从仅支持 P-256扩展为支持P-256 / P-384 / P-521三种 ECDSA 曲线叶子证书与通用 TLS 路径的能力对齐实现要点签名算法由 envoy_quic_utils.cc 的deduceSignatureAlgorithmFromPublicKey()按曲线 NID 推导P-384 →SSL_SIGN_ECDSA_SECP384R1_SHA384P-521 →SSL_SIGN_ECDSA_SECP521R1_SHA512证书链选择由 quic_server_transport_socket_factory.cc 依据开关动态决定支持曲线集合回退手段将运行时开关envoy.reloadable_features.quic_support_additional_ecdsa_curves置为false即可临时恢复仅 P-256 的旧行为实操指引QUIC 下行监听器的证书配置位置为QuicDownstreamTransport.downstream_tls_context参考 proxy_connect_udp_http3_downstream.yaml。该变更对需要大规模部署 HTTP/3 且已使用高强度 ECDSA 证书P-384 / P-521的生产环境尤为有价值它消除了HTTP/3 必须额外签发 P-256 证书的限制使 QUIC 服务能够直接复用现有 PKI 资产。【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Envoy QUIC 下游连接新增 P-384 / P-521 ECDSA 叶子证书支持
Envoy QUIC 下游连接新增 P-384 / P-521 ECDSA 叶子证书支持【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy导读本文基于 Envoy 仓库changelogs/current/new_features/quic__support-p384-p521-ecdsa-curves.rst的变更记录深入解读 Envoy 新增的对 QUICHTTP/3下游连接 P-384、P-521 ECDSA 叶子证书的支持。此前 Envoy 的 QUIC 下游握手仅接受 P-256 曲线签发的证书本次变更将其扩展为 P-256 / P-384 / P-521 三档曲线并配套提供名为envoy.reloadable_features.quic_support_additional_ecdsa_curves的运行时开关用于临时回退。读完本文你将掌握该能力的适用场景、底层签名算法推导逻辑、证书链选择机制以及如何通过运行时配置控制该行为。变更背景QUIC/TLS 1.3 握手与 ECDSA 签名曲线QUIC 传输层的 TLS 1.3 握手与证书体系完全复用 TLS 的 PKI。服务端在握手阶段向客户端出示证书链其中**叶子证书leaf certificate**携带的 ECDSA 公钥必须与 TLS 1.3 的签名算法SignatureScheme一一对应P-256secp256r1NID 为NID_X9_62_prime256v1对应SSL_SIGN_ECDSA_SECP256R1_SHA256P-384secp384r1NID 为NID_secp384r1对应SSL_SIGN_ECDSA_SECP384R1_SHA384P-521secp521r1NID 为NID_secp521r1对应SSL_SIGN_ECDSA_SECP521R1_SHA512。在本次变更之前Envoy 的 QUIC 下游downstream连接只支持 P-256 一种 ECDSA 曲线相较之下通用 TLS 下行路径source/common/tls/context_impl.cc早已支持 P-256、P-384、P-521 三种曲线见该文件中 We only support P-256, P-384 or P-521 ECDSA today. 的注释。因此本次变更本质上是将 TLS 路径已有的曲线能力对齐到 QUIC 路径让部署了 P-384 / P-521 证书的站点也能直接对外提供 HTTP/3 服务而无需为 QUIC 单独准备 P-256 证书。适用前提该能力作用于 Envoy 作为服务端接受的下行 QUIC 连接对应envoy.transport_sockets.quic的QuicDownstreamTransport场景不涉及上游upstream方向的证书签发。变更内容叶子证书支持曲线从 P-256 扩展至 P-256 / P-384 / P-521变更记录原文要点如下新增对P-384 与 P-521 ECDSA 叶子证书的支持用于 QUIC 下游连接原有的P-256支持保持不变可通过将运行时开关envoy.reloadable_features.quic_support_additional_ecdsa_curves设为false临时回退到旧行为仅 P-256。该开关在 runtime_features.cc 中以RUNTIME_GUARD(envoy_reloadable_features_quic_support_additional_ecdsa_curves)的形式注册属于标准的reloadable可热加载运行时功能开关——这意味着无需重启进程只需更新运行时配置即可生效适用于灰度发布期间临时关闭新能力的场景。源码级实现解析1.deduceSignatureAlgorithmFromPublicKey按证书曲线推导签名算法QUIC 路径的证书合法性校验与签名算法选择集中在 envoy_quic_utils.cc 的deduceSignatureAlgorithmFromPublicKey()函数中。其核心逻辑如下通过EVP_PKEY_id判断公钥类型对ECDSA公钥取出椭圆曲线群并获取曲线 NID然后按曲线分派签名算法NID_X9_62_prime256v1P-256恒返回SSL_SIGN_ECDSA_SECP256R1_SHA256NID_secp384r1P-384仅当开关envoy.reloadable_features.quic_support_additional_ecdsa_curves启用时返回SSL_SIGN_ECDSA_SECP384R1_SHA384否则返回 0NID_secp521r1P-521仅当开关启用时返回SSL_SIGN_ECDSA_SECP521R1_SHA512否则返回 0若推导结果签名算法为 0则设置错误信息。错误文案也随开关状态变化开关开启时报Invalid leaf cert, only P-256, P-384 or P-521 ECDSA certificates are supported关闭时报Invalid leaf cert, only P-256 ECDSA certificates are supported。该函数对RSA公钥同样做了处理要求 2048 位及以上FIPS 模式下仅允许 2048 / 3072 / 4096 位但本文聚焦 ECDSA 曲线扩展。该函数在 QUIC 路径中有三处调用点覆盖了服务端与客户端两侧的证书校验envoy_quic_proof_source.cc服务端 ProofSource 使用私钥推导签名算法用于实际签发握手签名envoy_quic_proof_verifier.cc对端证书验证时推导签名算法quic_server_transport_socket_factory.cc下游监听器创建 TLS 上下文时校验证书合法性。2. 证书链选择supported_curves与findTlsContext除了签名算法推导证书链的按曲线过滤逻辑位于 quic_server_transport_socket_factory.cc 的getTlsCertificateAndKey()const Ssl::CurveNIDVector supported_curves Runtime::runtimeFeatureEnabled( envoy.reloadable_features.quic_support_additional_ecdsa_curves) ? Ssl::CurveNIDVector{NID_X9_62_prime256v1, NID_secp384r1, NID_secp521r1} : Ssl::CurveNIDVector{NID_X9_62_prime256v1}; auto [tls_context, ocsp_staple_action] ctx-findTlsContext(sni, supported_curves, false /* TODO: ocsp_capable */, cert_matched_sni);可以看到开关开启时支持曲线集合为{P-256, P-384, P-521}三个 NID关闭时退化为仅{P-256}。该集合被传入ServerContextImpl::findTlsContext()用于在多证书含 SNI 匹配场景下挑选与客户端能力兼容的证书链进一步印证了开关对证书选择路径的完整约束。3. 签名算法推导与 ProofSource 的配合在 envoy_quic_proof_source.cc 中deduceSignatureAlgorithmFromPublicKey的返回值直接决定了服务端握手签名所采用的算法。若叶子证书曲线不被支持开关关闭时使用 P-384/P-521 证书推导返回 0 并携带错误信息握手将因此失败——这正是运维人员需要关注回退开关与证书曲线匹配关系的原因。运行时开关配置方式与回退场景envoy.reloadable_features.quic_support_additional_ecdsa_curves是一个布尔型 reloadable runtime guard默认值为true启用新能力。回退操作如下layered_runtime: layers: - name: static_layer_0 static_layer: envoy: reloadable_features: quic_support_additional_ecdsa_curves: false适用回退的典型场景升级到包含该变更的 Envoy 版本后若 P-384 / P-521 证书握手出现兼容性问题可先将开关置为false恢复旧行为仅 P-256排查并修复后再重新开启存量环境中若存在仅支持 P-256 的客户端或证书体系运维可在灰度窗口内保持旧行为以缩小变更面。需要留意的是回退期间所有 QUIC 下游连接仍严格要求叶子证书为 P-256若配置了 P-384 / P-521 证书且未匹配到 P-256 证书链握手仍会因签名算法推导失败而拒绝。实操为 QUIC 下游监听器配置 ECDSA 证书仓库中的示例配置 proxy_connect_udp_http3_downstream.yaml 展示了 QUIC 下游监听器的完整写法该示例用于将下行 CONNECT-UDP 请求转发至上游static_resources: listeners: - name: listener_0 address: socket_address: protocol: UDP address: 127.0.0.1 port_value: 10001 udp_listener_config: quic_options: {} downstream_socket_config: prefer_gro: true filter_chains: - transport_socket: name: envoy.transport_sockets.quic typed_config: type: type.googleapis.com/envoy.extensions.transport_sockets.quic.v3.QuicDownstreamTransport downstream_tls_context: common_tls_context: tls_certificates: - certificate_chain: filename: certs/servercert.pem private_key: filename: certs/serverkey.pem filters: - name: envoy.filters.network.http_connection_manager typed_config: type: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager codec_type: HTTP3 stat_prefix: ingress_http # ... 后续为 route_config 与 http_filters 配置要点解读下行 QUIC 监听器必须是UDPsocket并设置udp_listener_config.quic_options可传空对象{}启用默认 QUIC 选项filter chain 的 transport socket 使用envoy.transport_sockets.quic其type为QuicDownstreamTransport证书通过downstream_tls_context.common_tls_context.tls_certificates提供上层网络过滤器选择 HTTP/3HttpConnectionManager的codec_type设为HTTP3。基于本次变更该处的servercert.pem/serverkey.pem既可以是 P-256 证书也可以是 P-384 或 P-521 证书开关保持默认开启时。与通用 TLS 下行配置见 context_config_impl.cc 中默认曲线DEFAULT_CURVES P-256等定义相比QUIC 路径此前只能接受 P-256现在曲线支持范围已与 TLS 对齐。总结变更内容Envoy QUIC 下游连接从仅支持 P-256扩展为支持P-256 / P-384 / P-521三种 ECDSA 曲线叶子证书与通用 TLS 路径的能力对齐实现要点签名算法由 envoy_quic_utils.cc 的deduceSignatureAlgorithmFromPublicKey()按曲线 NID 推导P-384 →SSL_SIGN_ECDSA_SECP384R1_SHA384P-521 →SSL_SIGN_ECDSA_SECP521R1_SHA512证书链选择由 quic_server_transport_socket_factory.cc 依据开关动态决定支持曲线集合回退手段将运行时开关envoy.reloadable_features.quic_support_additional_ecdsa_curves置为false即可临时恢复仅 P-256 的旧行为实操指引QUIC 下行监听器的证书配置位置为QuicDownstreamTransport.downstream_tls_context参考 proxy_connect_udp_http3_downstream.yaml。该变更对需要大规模部署 HTTP/3 且已使用高强度 ECDSA 证书P-384 / P-521的生产环境尤为有价值它消除了HTTP/3 必须额外签发 P-256 证书的限制使 QUIC 服务能够直接复用现有 PKI 资产。【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考