网络安全网络IDS【免费下载链接】zeekZeek is a powerful network analysis framework that is much different from the typical IDS you may know.项目地址https://gitcode.com/gh_mirrors/ze/zeek点击查看免费下载导读本文围绕 Zeek 的policy/protocols/ssl/validate-sct.zeek脚本系统讲解如何对 TLS 连接中遇到的 Signed Certificate TimestampSCT签名证书时间戳进行验证——这是 Certificate Transparency证书透明度CT机制的核心环节规范依据为 RFC6962。你将掌握该脚本的数据模型SSL::SctInfo、SSL::SctSource、SCT 的三种来源X.509 证书扩展、TLS 会话扩展、OCSP 响应扩展、验证流程与底层sct_verify实现原理并了解如何在 SSL 日志中输出验证结果字段。文末给出的源码路径均可直接在当前仓库中继续深入阅读。脚本定位为 SSL 连接补齐 CT 证明校验在证书生态中CA 签发的证书会附带一个或多个由 CT 日志服务器签名的 SCT用于证明证书已提交到公开日志。validate-sct.zeek是 Zeek 的 policy 层脚本功能是对 SSL 连接中收集到的所有 SCT 进行密码学验证而不是仅仅把原始 SCT 记录到日志。脚本文件位于 scripts/policy/protocols/ssl/validate-sct.zeek其头部注释明确了用途##! Perform validation of Signed Certificate Timestamps, as used ##! for Certificate Transparency. See RFC6962 for more details.该脚本依赖两个基础组件load base/protocols/ssl load protocols/ssl/validate-certsbase/protocols/ssl提供 SSL 分析器的核心事件与SSL::Info记录定义见 scripts/base/protocols/ssl/main.zeekprotocols/ssl/validate-certs即 scripts/policy/protocols/ssl/validate-certs.zeek提供证书链验证与中间证书缓存是 X.509 扩展中 SCT 校验的前提。启用方式与所有 policy 脚本一致通过在 Zeek 脚本加载链中加入一行即可启用load policy/protocols/ssl/validate-sct或在使用zeek命令行时直接指定zeek -r trace.pcap policy/protocols/ssl/validate-sct需要特别说明的是脚本会自动将SSL::ssl_store_valid_chain重定义为T# We need to know issuer certificates to be able to determine the IssuerKeyHash, # which is required for validating certificate extensions. redef SSL::ssl_store_valid_chain T;这是因为 X.509 证书扩展中携带的 SCT 属于 pre-certificate 类型其验证必须用到签发者公钥哈希IssuerKeyHash只有保留完整的有效证书链才能拿到该信息。数据模型三种 SCT 来源与 SctInfo 记录SSL::SctSourceSCT 的来源枚举脚本在SSL命名空间下定义了枚举SSL::SctSource区分 SCT 出现的三种位置枚举值含义SSL::SCT_X509_EXTSCT 出现在 X.509 证书的扩展中SSL::SCT_TLS_EXTSCT 出现在 TLS 会话扩展中SSL::SCT_OCSP_EXTSCT 出现在 stapled OCSP 响应的扩展中SSL::SctInfo单个 SCT 的完整描述type SctInfo: record { version: count; # SCT 版本v1 应为 0 logid: string; # 签发该 SCT 的日志 ID timestamp: count; # SCT 签发时间自 epoch 起毫秒忽略闰秒 sig_alg: count; # 该 SCT 使用的签名算法 hash_alg: count; # 该 SCT 使用的哈希算法 signature: string; # SCT 的签名 source: SctSource; # SCT 的来源 valid: bool optional; # 验证结果 };各字段含义对应文档与源码注释versionSCT 版本号RFC6962 v1 恒为 0logid签发日志的 ID用于在 CT 日志表中查找对应的日志公钥timestampSCT 签发时间单位为毫秒。特别注意这里故意不转换为 Zeek 时间戳因为验证时需要毫秒精度的原始值参与签名数据构造sig_alg / hash_algSCT 签名所用算法标识signature日志服务器对 SCT 内容的数字签名source上述三种来源之一valid验证结果由后续的ssl_finishing钩子填充。SSL::Info 记录的扩展字段脚本通过redef record Info 为 SSL 连接日志追加了 6 个新字段字段类型属性含义valid_sctscountoptional连接中验证通过的 SCT 数量invalid_sctscountoptional连接中未能验证通过的 SCT 数量valid_ct_logscountlog optional连接中提供有效 SCT 的不同日志数量valid_ct_operatorscountlog optional提供有效 SCT 的不同日志运营商数量valid_ct_operators_listset[string]optional提供有效 SCT 的运营商列表ct_proofsvector of SctInfodefault []连接中遇到的全部 SCT 信息其中带log属性的字段会直接写入ssl.log输出列其余字段通过脚本事件/钩子供进一步分析使用。SCT 收集阶段三个入口事件验证的前提是先把 SCT 收集到c$ssl$ct_proofs向量中。脚本注册了两个事件处理器均为priority5分别覆盖三种来源中的两种路径1. TLS 会话扩展event ssl_extension_signed_certificate_timestamp(c: connection, is_client: bool, version: count, logid: string, timestamp: count, signature_and_hashalgorithm: SSL::SignatureAndHashAlgorithm, signature: string) priority5 { c$ssl$ct_proofs SctInfo($versionversion, $logidlogid, $timestamptimestamp, $sig_algsignature_and_hashalgorithm$SignatureAlgorithm, $hash_algsignature_and_hashalgorithm$HashAlgorithm, $signaturesignature, $sourceSCT_TLS_EXT); }该事件由 SSL 分析器在解析 TLS ClientHello/ServerHello 扩展时触发事件签名定义在 src/analyzer/protocol/ssl/events.bifssl_extension_signed_certificate_timestamp。来自 TLS 扩展的 SCT 直接标记为SCT_TLS_EXT。2. X.509 证书扩展与 stapled OCSP 响应event x509_ocsp_ext_signed_certificate_timestamp(f: fa_file, version: count, logid: string, timestamp: count, hash_algorithm: count, signature_algorithm: count, signature: string) priority5 { local src: SctSource; if ( ! f?$info ) return; if ( f$source SSL f$info$mime_type application/ocsp-response ) src SCT_OCSP_EXT; else if ( f$source SSL f$info$mime_type application/x-x509-user-cert ) src SCT_X509_EXT; else return; if ( |f$conns| ! 1 ) return; local c: connection is_assigned; for ( _, c in f$conns ) { if ( ! c?$ssl ) return; } c$ssl$ct_proofs SctInfo($versionversion, $logidlogid, $timestamptimestamp, $sig_algsignature_algorithm, $hash_alghash_algorithm, $signaturesignature, $sourcesrc); }该事件通过fa_file文件分析框架上报脚本根据文件的 MIME 类型区分来源application/ocsp-response→SCT_OCSP_EXTOCSP stapling 响应扩展application/x-x509-user-cert→SCT_X509_EXTX.509 用户证书扩展。为保证能将文件与连接对应起来脚本要求f$conns恰好只有一个连接且该连接已建立$ssl信息。同时为了让 OCSP 响应进入文件分析流程脚本在zeek_init中注册了 MIME 类型event zeek_init() { Files::register_for_mime_type(Files::ANALYZER_OCSP_REPLY, application/ocsp-response); }至此c$ssl$ct_proofs中已包含该连接遇到的全部 SCT无论来源等待统一验证。验证阶段ssl_finishing 钩子验证逻辑集中在ssl_finishing钩子中优先级设为priority19——注释说明“Priority 19 will be handled after validation is done”即在证书验证完成之后执行确保 X.509 类型的 SCT 有可用的验证结果与证书链信息。前置条件检查hook ssl_finishing(c: connection) priority19 { if ( ! c$ssl?$cert_chain || |c$ssl$cert_chain| 0 || ! c$ssl$cert_chain[0]?$x509 ) return; local cert c$ssl$cert_chain[0]$x509$handle; local certhash c$ssl$cert_chain[0]$sha1; local issuer_name_hash x509_issuer_name_hash(cert, 4); ... }没有证书链或叶证书缺少 X.509 信息时直接返回随后取叶证书句柄、SHA-1 哈希、签发者名称哈希作为后续验证的输入。逐条验证 SCT对ct_proofs中的每个 SCT日志查找若proof$logid不在SSL::ct_logs表中直接判定valid F“如果我们不认识这个日志就没有什么可做的了”缓存检查以certhash logid timestamp hash_alg signature source拼接后取 SHA-1 作为缓存键命中recently_validated_scts则直接复用结果避免重复计算TLS/OCSP 来源直接调用sct_verify(cert, logid, log$key, signature, timestamp, hash_alg)X.509 来源需要 IssuerKeyHash按四种途径依次尝试若前一轮已确定issuer_key_hash直接使用从intermediate_cache由 validate-certs 脚本维护的中间证书缓存见 scripts/policy/protocols/ssl/validate-certs.zeek中按签发者名称哈希取中间证书计算其 SPKI 哈希若c$ssl$valid_chain长度 ≥ 2用有效链中的第二个证书计算遍历c$ssl$cert_chain中除叶证书索引 0外的所有证书逐一尝试。if ( proof$source SCT_TLS_EXT || proof$source SCT_OCSP_EXT ) valid sct_verify(cert, proof$logid, log$key, proof$signature, proof$timestamp, proof$hash_alg); else if ( found_cache F ) { # X.509 proof. Here things get awkward because we need information about # the issuer cert... and we need to try a few times, because we have to see if we got # the right issuer cert. ... }结果汇总与写入验证完成后更新各统计字段proof$valid valid; if ( valid ) { valid_proofs; add c$ssl$valid_ct_operators_list[log$operator]; add valid_logs[proof$logid]; } else invalid_proofs; ... c$ssl$valid_scts valid_proofs; c$ssl$invalid_scts invalid_proofs; c$ssl$valid_ct_operators |c$ssl$valid_ct_operators_list|; c$ssl$valid_ct_logs |valid_logs|;于是ssl.log中会出现valid_scts、invalid_scts、valid_ct_logs、valid_ct_operators等列valid_ct_operators_list与ct_proofs则保留在连接信息中供脚本层消费。验证结果缓存脚本用一个带读过期时间的表缓存 5 分钟内的验证结论以减轻计算负担global recently_validated_scts: table[string] of bool table() read_expire5mins redef;缓存键包含证书哈希、日志 ID、时间戳、哈希算法、签名与来源对 X.509 来源的 SCT 额外追加c$ssl$validation_code避免不同验证状态下的结果串用。这是典型的以空间换 CPU 的优化同一证书例如 CDN 场景下大量连接复用同一证书的 SCT 验证结果可被复用。底层原理sct_verify 的密码学验证流程sct_verify是x509文件分析模块提供的 BIF内建函数声明位于 src/file_analysis/analyzer/x509/functions.biffunction sct_verify%(cert: opaque of x509, logid: string, log_key: string, signature: string, timestamp: count, hash_algorithm: count, issuer_key_hash: string default%): bool参数说明来自 BIF 文档注释cert待验证 SCT 所针对的证书logidSCT 的日志 IDlog_key签发 SCT 的日志公钥DER 编码的 SubjectPublicKeyInfotimestamp证明生成时间hash_algorithmSCT 证明使用的哈希算法issuer_key_hash签发者公钥的 SHA-256 哈希仅在 SCT 来自 X.509 证书扩展时必须提供。签名数据的构造RFC6962 规定格式函数内部按 RFC6962 的digitally-signed输入格式逐字节构造待验签数据version1 字节恒为 0与signature_type1 字节恒为certificate_timestamp即 08 字节网络字节序的timestamphtonll转换毫秒精度entry_type2 字节pre-certificate 为\0\1普通 X.509 证书为\0\0证书数据普通证书直接使用 DER 编码的完整证书i2d_X509pre-certificateissuer_key_hash非空时先通过 OpenSSL 的NID_ct_precert_scts或老版本 OpenSSL 下按 OID1.3.6.1.4.1.11129.2.4.2字符串比对定位并删除证书中的 SCT 扩展再对 TBS 部分编码i2d_re_X509_tbs随后追加 32 字节的 IssuerKeyHash3 字节网络字节序的证书长度2 字节扩展数恒为\0\0即无扩展。验签执行const EVP_MD* hash hash_to_evp(hash_algorithm); EVP_PKEY* key d2i_PUBKEY(nullptr, key_char, log_key-Len()); EVP_DigestVerifyInit(mdctx, nullptr, hash, nullptr, key); EVP_DigestVerifyUpdate(mdctx, data.data(), data.size()); EVP_DigestVerifyFinal(mdctx, signature-Bytes(), signature-Len());即用日志公钥与 SCT 声明的哈希算法对构造出的输入数据与签名执行EVP_DigestVerify*系列操作。任何一步失败未知哈希算法、无法加载日志公钥、找不到 pre-certificate 扩展等都会通过zeek::reporter-Error上报错误并返回F。数据支撑CT 日志表与 CTInfo验证依赖“日志 ID → 日志公钥”的映射即SSL::ct_logs表。其记录类型CTInfo定义在 scripts/base/protocols/ssl/main.zeektype CTInfo: record { description: string; # 日志描述 operator: string; # 日志运营商 key: string; # 日志公钥DER SubjectPublicKeyInfo maximum_merge_delay: count; # 日志最大合并延迟秒 url: string; # 日志提交 URL }; option ct_logs: table[string] of CTInfo {};默认日志表由 scripts/base/protocols/ssl/ct-list.zeek 提供。该文件头部的注释表明它由gen-ct-list.py从 Google 的公开 CT 日志列表https://www.gstatic.com/ct/log_list/v3/log_list.json自动生成并注明“Do not edit this file”。其中包含 Google、Cloudflare、DigiCert、Lets Encrypt、Sectigo、TrustAsia 等运营商的日志条目还包含两个用于“修复行为异常的 CT 库”的占位日志Bogus placeholder log。这意味着SCT 验证能力与ct_logs表的时效性直接相关——仓库随版本发布更新日志列表用户也可通过redef ct_logs 追加私有或新增日志若 SCT 的日志不在表中脚本会直接判为无效invalid_scts计数 1这属于“无法验证”而非“签名错误”。实战要点与注意事项必须与 validate-certs 配合脚本显式load protocols/ssl/validate-certsX.509 扩展 SCT 的验证强依赖valid_chain、validation_code与intermediate_cache单独加载本脚本而缺少证书验证链将导致 X.509 来源 SCT 的验证途径大幅减少。OCSP stapling 场景依赖文件分析zeek_init中注册application/ocsp-responseMIME 类型是关键一步否则 stapled OCSP 响应不会被送入文件分析框架SCT_OCSP_EXT也就无法被收集。性能权衡recently_validated_scts的 5 分钟缓存与ssl_store_valid_chain T带来的链保存开销是设计上的取舍——缓存降低重复验签的 CPU 成本而保留完整链为 IssuerKeyHash 解析提供素材。日志解读在ssl.log中valid_scts/invalid_scts反映单连接 SCT 的通过率valid_ct_logs与valid_ct_operators则可用于评估该站点证书的 CT 覆盖广度来自多少个独立日志、多少个运营商这对识别依赖单一日志、存在单点风险的证书很有价值。相关资源索引脚本本体scripts/policy/protocols/ssl/validate-sct.zeek文档页doc/scripts/policy/protocols/ssl/validate-sct.zeek.rst依赖的证书验证脚本scripts/policy/protocols/ssl/validate-certs.zeekSSL 基础脚本SSL::Info、CTInfo、ct_logs定义scripts/base/protocols/ssl/main.zeek默认 CT 日志列表自动生成scripts/base/protocols/ssl/ct-list.zeeksct_verifyBIF 实现src/file_analysis/analyzer/x509/functions.bifTLS 扩展事件定义src/analyzer/protocol/ssl/events.bif赞分享网络安全网络IDS【免费下载链接】zeekZeek is a powerful network analysis framework that is much different from the typical IDS you may know.项目地址https://gitcode.com/gh_mirrors/ze/zeek点击查看免费下载相关推荐Zeek 的证书透明度日志库SSL::ct_logs结构、生成与 SCT 验证实战解析Zeek 的证书透明度日志库SSL::ct_logs结构、生成与 SCT 验证实战解析 本文围绕 Zeek 仓库中 scripts/base/protoc网络安全网络IDSlibcurl 证书主机名校验指南深入解析 CURLOPT_SSL_VERIFYHOSTlibcurl 证书主机名校验指南深入解析 CURLOPT_SSL_VERIFYHOST 本指南围绕 libcurl 的 CURLOPT_SSL_VERIFYCLI网络通信如何确保数据库迁移安全Flyway Validate命令的终极指南如何确保数据库迁移安全Flyway Validate命令的终极指南 Flyway作为Redgate推出的数据库迁移工具其核心价值在于保障数据库变更的一致性与数据库开发工具上一篇Pearcleaner你的Mac终极清理专家免费开源彻底解决应用残留问题下一篇3分钟快速启用Windows Insider预览版无需微软账户的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考