拓冰网站定制 
网络安全网络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点击查看免费下载导读x509.log是 Zeek 网络分析框架中记录 TLS 握手期间交换的 X.509 证书详细信息的日志源与上一节介绍的ssl.log互为补充ssl.log提供连接级视图而x509.log提供证书级视图。本文以 Curl 产生的 TLS 1.2 与 TLS 1.3 流量为样本逐步剖析x509.log的完整字段含义、证书链的关联方式并结合仓库源码说明日志的记录机制、去重策略与可配置选项。读完本文你将能够独立读懂x509.log每一条记录、把ssl.log中的cert_chain_fuids与证书记录一一对应并理解为什么 TLS 1.3 会带来证书可见性的根本变化。x509.log 是什么x509.log记录的是在 TLS 协商过程中交换的证书细节包括版本、序列号、主题、签发者、有效期、密钥算法、密钥长度、Subject Alternative NameSAN以及基本约束Basic Constraints等信息。它由 Zeek 的 X.509 文件分析器file analyzer在识别出证书文件后生成核心实现位于 src/file_analysis/analyzer/x509/X509.cc日志列定义与记录类型X509::Info位于 scripts/base/files/x509/main.zeek。从源码可以看出x509.log的流log stream在zeek_init事件中以$pathx509注册见 main.zeek并且证书数据通过 MIME 类型识别application/x-x509-user-cert连接中的第一张证书即终端实体证书、application/x-x509-ca-cert后续的 CA 证书以及application/pkix-cert例如经 HTTP 明文传输的证书Zeek 核心对证书同时计算 MD5、SHA1、SHA256 哈希用于文件识别与后续的证书事件缓存见 main.zeek每当文件状态结束file_state_remove时日志被写入见 main.zeek。X509::Info 的核心字段X509::Info记录类型定义了x509.log的所有列详见 main.zeek字段含义ts当前时间戳fingerprint证书指纹默认使用 SHA256可通过X509::hash_function选项更换算法certificate证书基本信息的子记录版本、序列号、主题、签发者、有效期、密钥算法等sanSubject Alternative Name 扩展DNS 名、URI、Email、IPbasic_constraintsBasic Constraints 扩展是否 CA、路径长度限制host_cert是否为终端主机证书链中第一张client_cert是否为客户端发起方发送的证书X509::Certificate子记录的类型定义由 BIF 文件 src/file_analysis/analyzer/x509/types.bif 声明其字段填充逻辑在X509::ParseCertificate()中完成见 X509.cc包括证书版本X509_get_version、序列号X509_get_serialNumber、主题与签发者按 RFC2253 格式打印、有效期notBefore/notAfter、公钥算法 OID、RSA 公钥指数exponent、密钥类型rsa/dsa/ecdsa以及密钥长度等。关联日志ssl.log 与 x509.log 如何通过 fuids 挂钩x509.log本身并不直接输出连接信息它的记录与ssl.log通过**文件唯一标识符fuid**关联。TLS 分析器把握手过程中出现的每张证书都交给文件分析框架生成一个独立的文件记录而ssl.log中的cert_chain_fuids字段按顺序列出服务器证书链对应的文件 ID。这一关联机制可以在 scripts/base/protocols/ssl/files.zeek 中看到SSL::Info记录扩展了cert_chain证书文件对象向量、cert_chain_fps证书指纹向量log输出、client_cert_chain_fps等字段file_sniff事件把 MIME 类型为 X.509 证书的文件分别挂到服务端或客户端证书链上ssl_finishing钩子再把每张证书的x509$fingerprint汇总为指纹列表同时把链首证书的subject、issuer写入ssl.log。默认情况下subject/issuer字段被从ssl.log过滤掉可通过SSL::log_include_server_certificate_subject_issuer选项开启因为这些信息在x509.log中完整存在。ssl.log里缺失 fuid 或指纹并不意味着证书不存在也可能是这些字段被主动过滤——但更常见的原因是协议本身不再暴露证书这正是下一节要讨论的 TLS 1.3 场景。TLS 1.2 场景完整证书链的四个 x509.log 条目我们回到 Curl 使用 TLS 1.2 产生的流量。作为参照该活动的ssl.log条目如下{ ts: 1598377391.921726, uid: CsukF91Bx9mrqdEaH9, id.orig_h: 192.168.4.49, id.orig_p: 56718, id.resp_h: 13.32.202.10, id.resp_p: 443, version: TLSv12, cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, curve: secp256r1, server_name: www.taosecurity.com, resumed: false, next_protocol: h2, established: true, cert_chain_fuids: [ F2XEvj1CahhdhtfvT4, FZ7ygD3ERPfEVVohG9, F7vklpOKI4yX9wmvh, FAnbnR32nIIr2j9XV ], client_cert_chain_fuids: [], subject: CNwww.taosecurity.com, issuer: CNAmazon,OUServer CA 1B,OAmazon,CUS }这条ssl.log条目提到了四个cert_chain_fuids证书标识符。在对应的x509.log数据中我们依次看到它们各自的记录第一条——终端实体证书fuidF2XEvj1CahhdhtfvT4{ ts: 1598377391.938343, id: F2XEvj1CahhdhtfvT4, certificate.version: 3, certificate.serial: 0B58BC3898391F36592BA1BE1F6B03EF, certificate.subject: CNwww.taosecurity.com, certificate.issuer: CNAmazon,OUServer CA 1B,OAmazon,CUS, certificate.not_valid_before: 1590969600, certificate.not_valid_after: 1625140800, certificate.key_alg: rsaEncryption, certificate.sig_alg: sha256WithRSAEncryption, certificate.key_type: rsa, certificate.key_length: 2048, certificate.exponent: 65537, san.dns: [ www.taosecurity.com, taosecurity.com, *.taosecurity.com ], basic_constraints.ca: false }第二条——签发者 CAfuidFZ7ygD3ERPfEVVohG9{ ts: 1598377391.938343, id: FZ7ygD3ERPfEVVohG9, certificate.version: 3, certificate.serial: 067F94578587E8AC77DEB253325BBC998B560D, certificate.subject: CNAmazon,OUServer CA 1B,OAmazon,CUS, certificate.issuer: CNAmazon Root CA 1,OAmazon,CUS, certificate.not_valid_before: 1445472000, certificate.not_valid_after: 1760832000, certificate.key_alg: rsaEncryption, certificate.sig_alg: sha256WithRSAEncryption, certificate.key_type: rsa, certificate.key_length: 2048, certificate.exponent: 65537, basic_constraints.ca: true, basic_constraints.path_len: 0 }第三条——根 CAfuidF7vklpOKI4yX9wmvh{ ts: 1598377391.938343, id: F7vklpOKI4yX9wmvh, certificate.version: 3, certificate.serial: 067F944A2A27CDF3FAC2AE2B01F908EEB9C4C6, certificate.subject: CNAmazon Root CA 1,OAmazon,CUS, certificate.issuer: CNStarfield Services Root Certificate Authority - G2,OStarfield Technologies\\, Inc.,LScottsdale,STArizona,CUS, certificate.not_valid_before: 1432555200, certificate.not_valid_after: 2145834000, certificate.key_alg: rsaEncryption, certificate.sig_alg: sha256WithRSAEncryption, certificate.key_type: rsa, certificate.key_length: 2048, certificate.exponent: 65537, basic_constraints.ca: true }第四条——交叉签名根 CAfuidFAnbnR32nIIr2j9XV{ ts: 1598377391.938343, id: FAnbnR32nIIr2j9XV, certificate.version: 3, certificate.serial: A70E4A4C3482B77F, certificate.subject: CNStarfield Services Root Certificate Authority - G2,OStarfield Technologies\\, Inc.,LScottsdale,STArizona,CUS, certificate.issuer: OUStarfield Class 2 Certification Authority,OStarfield Technologies\\, Inc.,CUS, certificate.not_valid_before: 1251849600, certificate.not_valid_after: 2035129156, certificate.key_alg: rsaEncryption, certificate.sig_alg: sha256WithRSAEncryption, certificate.key_type: rsa, certificate.key_length: 2048, certificate.exponent: 65537, basic_constraints.ca: true }这四张证书构成了一条完整、可验证的信任链www.taosecurity.com→ Amazon Server CA 1B → Amazon Root CA 1 → Starfield Services Root CA G2含交叉签名根。对防守团队而言这些记录蕴含大量可挖掘的情报价值可以在历史数据仓库中检索其他证书中出现的相同值例如 SAN、序列号、公钥指数exponent或key_alg/sig_alg组合从而发现入侵者活动模式之间的关联。证书字段的源码级解读这些字段并非凭空产生其取值由 X509.cc 中的 OpenSSL 调用逐项提取certificate.versionX509_get_version()返回值加 1DER 中版本号从 0 计起输出为人类可读的 1/2/3certificate.seriali2a_ASN1_INTEGER打印的十六进制序列号certificate.subject/certificate.issuerX509_NAME_print_ex按 RFC2253 格式输出这也是为什么签发者字段中出现\\,转义逗号如LScottsdale,STArizona中的Starfield Technologies\\, Inc.实为逗号被转义certificate.not_valid_before/not_valid_afterASN.1 时间转为 Unix 时间戳如1590969600即 2020-06-01certificate.key_alg/sig_alg公钥算法与签名算法的 ASN.1 OID 文本名rsaEncryption、sha256WithRSAEncryptioncertificate.key_type/key_length/exponent由EVP_PKEY提取。RSA 密钥给出rsa、位数EVP_PKEY_bits与公钥指数十进制字符串65537EC 密钥给出ecdsa与曲线名KeyCurve()DSA 密钥给出dsa。源码中还包含一个特殊分支某些 RDP 服务器证书错误地把密钥算法声明为md5WithRSAEncryptionZeek 会绕过 OID 直接按 RSA 解码公钥见 X509.ccsan.dns/san.uri/san.email/san.ip来自 Subject Alternative Name 扩展的解析见 X509.cc其中GEN_DNS类型归入san.dns向量GEN_URI、GEN_EMAIL、GEN_IPADD分别归入对应向量basic_constraints.ca/basic_constraints.path_len来自 Basic Constraints 扩展见 X509.cccatrue表示该证书是 CA 证书path_len表示允许的中间 CA 级数。这正是区分终端实体证书cafalse与链中 CA 证书catrue的关键字段。TLS 1.3 场景为什么没有 x509.log下面看 Curl 使用 TLS 1.3 产生的流量。作为参照该活动的ssl.log条目如下{ ts: 1598983678.585087, uid: CcJfBs3hXLJn7oHVu7, id.orig_h: 192.168.4.142, id.orig_p: 58802, id.resp_h: 13.32.202.2, id.resp_p: 443, version: TLSv13, cipher: TLS_AES_128_GCM_SHA256, curve: x25519, server_name: www.taosecurity.com, resumed: true, established: true }注意这条记录中完全没有证书的文件标识符没有cert_chain_fuids、没有subject、没有issuer。这意味着相应的x509.log中没有任何对应条目——本节标题本身就是一个“陷阱题”。原因在于协议设计TLS 1.3 在握手阶段对Certificate消息进行了加密只有完成密钥交换后的通信双方才能看到证书内容。网络侧的 Zeek 只能看到加密后的密文无法再解析出证书因此既无法产出x509.log也无法在ssl.log中填充证书链指纹、subject/issuer等字段。同样的可见性损失还发生在 SNI 上回顾上一节内容当 ESNIEncrypted SNI或 ECHEncrypted Client Hello启用时ssl.log中的server_name字段也会缺失。TLS 1.3 加上 ESNI/ECH意味着握手元数据中“证书”与“服务器名”两大情报来源同时被遮蔽。x509.log 的可配置选项与高级用法去重与重发策略默认情况下x509.log对重复出现的证书做去重处理同一张证书在去重窗口内只记录一次。相关选项定义在 scripts/base/files/x509/main.zeekX509::relog_known_certificates_after证书被重新记录前的最大间隔默认1day。设为0secs可完全禁用去重X509::known_log_certs_maximum_size已记录证书集合的最大大小默认 1,000,000X509::known_log_certs_enable_publish与X509::known_log_certs_enable_node_up_publish是否把已记录证书的哈希发布给集群其他节点 / 是否在 worker 上线时同步实现跨节点的全局去重见 main.zeek。去重的键由LogCertHash记录构成证书指纹 是否终端主机证书 是否客户端证书见create_deduplication_index钩子main.zeek。指纹使用的哈希函数可通过X509::hash_function选项更换默认sha256_hash更换后ssl.log与x509.log中的指纹会同步变化。证书事件缓存除了日志去重Zeek 还提供证书事件缓存机制降低高频证书的解析开销默认每张证书在 62 秒窗口内被遇到 10 次后其解析结果进入缓存后续相同证书按 SHA256 索引不再走 OpenSSL 完整解析而是由钩子x509_certificate_cache_replay重放缓存的事件。相关选项定义在 scripts/base/files/x509/certificate-event-cache.zeekX509::caching_required_encounters触发缓存所需的最小遇到次数默认 10设为 0 禁用缓存X509::caching_required_encounters_interval计数窗口默认 62 秒X509::certificate_cache_max_entries缓存最大条目数默认 10000。核心侧的缓存查找在 X509.cc 实现EndOfFile()先计算证书 DER 数据的 SHA256命中缓存即跳过解析并调用回调。更进一步策略脚本 scripts/policy/files/x509/disable-certificate-events-known-certs.zeek 会在证书事件缓存之上再加一层过滤如果同一服务器 IP、同一 SNI、同一证书 SHA256 在近期出现过则不重复抛出证书事件。该脚本可显著降低负载但代价是依赖“每连接证书事件”的检测脚本将不再收到事件——如果您的检测脚本需要每个连接都触发证书事件不应加载此脚本。把证书原文写入日志如果需要保留证书的原始内容可加载策略脚本 scripts/policy/protocols/ssl/log-certs-base64.zeek。它扩展了X509::Info的cert字段在x509_certificate事件中把证书 DER 内容 Base64 编码后写入日志并把X509::default_max_field_string_bytes置 0 以避免大证书被截断。其他日志相关选项X509::log_x509_in_files_log是否同时在files.log中记录证书文件条目默认F关闭因为证书信息已完整落在x509.log中见 main.zeekX509::default_max_field_string_bytes默认继承Log::default_max_field_string_bytes、X509::default_max_field_container_elements默认 500、X509::default_max_total_container_elements默认 1500控制长字符串与大容器如 SAN 列表的截断上限。由于证书可能携带超长 SAN 集合X.509 流在创建时专门放大了这些限制见 main.zeek。结论加密流量时代的证书取证本节内容表明默认配置下的x509.log即便面对加密流量也能为防守者提供大量有价值的信息完整的证书链、序列号、主题/签发者、有效期、密钥参数、SAN 与基本约束这些都可以作为威胁狩猎的检索键。但正如 TLS 1.3 示例所示随着管理员和攻击者逐步部署更新的加密技术TLS 1.3、ESNI、ECH证书与 SNI 等明文握手元数据正在快速消失。防守者将越来越难以仅凭x509.log与ssl.log区分正常、可疑与恶意的流量——这要求检测策略从“依赖明文元数据”向“结合加密流量分析、端点遥测与证书透明日志CT等外部证据”迁移。理解x509.log能提供什么、不能提供什么正是构建这一新检测体系的第一步。赞分享网络安全网络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点击查看免费下载相关推荐ESP-IDF 中的 x509 证书包ESP x509 Certificate BundleTLS 服务器证书验证的完整实战指南ESP IDF 中的 x509 证书包ESP x509 Certificate BundleTLS 服务器证书验证的完整实战指南 本文以 ESP IDF物联网嵌入式DeBERTa-V3-Base开发者手册模型结构、参数配置与迁移学习最佳实践DeBERTa V3 Base开发者手册模型结构、参数配置与迁移学习最佳实践 DeBERTa V3 Base是一个先进的自然语言处理模型它采用ELECTRA5步掌握BiliTools跨平台B站资源管理终极指南5步掌握BiliTools跨平台B站资源管理终极指南 还在为B站上的优质内容无法离线保存而烦恼吗BiliTools作为一款基于Tauri框架构建的跨平台哔哩桌面应用音视频上一篇如何用 Shopify Code Snippets 用 Liquid 获取购物车 Token快速解锁自定义加购下一篇Claude Code终端智能编码助手7大实战技巧提升开发效率创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Zeek 证书日志 x509.log 深度解析：TLS 1.2 与 TLS 1.3 下的证书取证差异
网络安全网络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点击查看免费下载导读x509.log是 Zeek 网络分析框架中记录 TLS 握手期间交换的 X.509 证书详细信息的日志源与上一节介绍的ssl.log互为补充ssl.log提供连接级视图而x509.log提供证书级视图。本文以 Curl 产生的 TLS 1.2 与 TLS 1.3 流量为样本逐步剖析x509.log的完整字段含义、证书链的关联方式并结合仓库源码说明日志的记录机制、去重策略与可配置选项。读完本文你将能够独立读懂x509.log每一条记录、把ssl.log中的cert_chain_fuids与证书记录一一对应并理解为什么 TLS 1.3 会带来证书可见性的根本变化。x509.log 是什么x509.log记录的是在 TLS 协商过程中交换的证书细节包括版本、序列号、主题、签发者、有效期、密钥算法、密钥长度、Subject Alternative NameSAN以及基本约束Basic Constraints等信息。它由 Zeek 的 X.509 文件分析器file analyzer在识别出证书文件后生成核心实现位于 src/file_analysis/analyzer/x509/X509.cc日志列定义与记录类型X509::Info位于 scripts/base/files/x509/main.zeek。从源码可以看出x509.log的流log stream在zeek_init事件中以$pathx509注册见 main.zeek并且证书数据通过 MIME 类型识别application/x-x509-user-cert连接中的第一张证书即终端实体证书、application/x-x509-ca-cert后续的 CA 证书以及application/pkix-cert例如经 HTTP 明文传输的证书Zeek 核心对证书同时计算 MD5、SHA1、SHA256 哈希用于文件识别与后续的证书事件缓存见 main.zeek每当文件状态结束file_state_remove时日志被写入见 main.zeek。X509::Info 的核心字段X509::Info记录类型定义了x509.log的所有列详见 main.zeek字段含义ts当前时间戳fingerprint证书指纹默认使用 SHA256可通过X509::hash_function选项更换算法certificate证书基本信息的子记录版本、序列号、主题、签发者、有效期、密钥算法等sanSubject Alternative Name 扩展DNS 名、URI、Email、IPbasic_constraintsBasic Constraints 扩展是否 CA、路径长度限制host_cert是否为终端主机证书链中第一张client_cert是否为客户端发起方发送的证书X509::Certificate子记录的类型定义由 BIF 文件 src/file_analysis/analyzer/x509/types.bif 声明其字段填充逻辑在X509::ParseCertificate()中完成见 X509.cc包括证书版本X509_get_version、序列号X509_get_serialNumber、主题与签发者按 RFC2253 格式打印、有效期notBefore/notAfter、公钥算法 OID、RSA 公钥指数exponent、密钥类型rsa/dsa/ecdsa以及密钥长度等。关联日志ssl.log 与 x509.log 如何通过 fuids 挂钩x509.log本身并不直接输出连接信息它的记录与ssl.log通过**文件唯一标识符fuid**关联。TLS 分析器把握手过程中出现的每张证书都交给文件分析框架生成一个独立的文件记录而ssl.log中的cert_chain_fuids字段按顺序列出服务器证书链对应的文件 ID。这一关联机制可以在 scripts/base/protocols/ssl/files.zeek 中看到SSL::Info记录扩展了cert_chain证书文件对象向量、cert_chain_fps证书指纹向量log输出、client_cert_chain_fps等字段file_sniff事件把 MIME 类型为 X.509 证书的文件分别挂到服务端或客户端证书链上ssl_finishing钩子再把每张证书的x509$fingerprint汇总为指纹列表同时把链首证书的subject、issuer写入ssl.log。默认情况下subject/issuer字段被从ssl.log过滤掉可通过SSL::log_include_server_certificate_subject_issuer选项开启因为这些信息在x509.log中完整存在。ssl.log里缺失 fuid 或指纹并不意味着证书不存在也可能是这些字段被主动过滤——但更常见的原因是协议本身不再暴露证书这正是下一节要讨论的 TLS 1.3 场景。TLS 1.2 场景完整证书链的四个 x509.log 条目我们回到 Curl 使用 TLS 1.2 产生的流量。作为参照该活动的ssl.log条目如下{ ts: 1598377391.921726, uid: CsukF91Bx9mrqdEaH9, id.orig_h: 192.168.4.49, id.orig_p: 56718, id.resp_h: 13.32.202.10, id.resp_p: 443, version: TLSv12, cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, curve: secp256r1, server_name: www.taosecurity.com, resumed: false, next_protocol: h2, established: true, cert_chain_fuids: [ F2XEvj1CahhdhtfvT4, FZ7ygD3ERPfEVVohG9, F7vklpOKI4yX9wmvh, FAnbnR32nIIr2j9XV ], client_cert_chain_fuids: [], subject: CNwww.taosecurity.com, issuer: CNAmazon,OUServer CA 1B,OAmazon,CUS }这条ssl.log条目提到了四个cert_chain_fuids证书标识符。在对应的x509.log数据中我们依次看到它们各自的记录第一条——终端实体证书fuidF2XEvj1CahhdhtfvT4{ ts: 1598377391.938343, id: F2XEvj1CahhdhtfvT4, certificate.version: 3, certificate.serial: 0B58BC3898391F36592BA1BE1F6B03EF, certificate.subject: CNwww.taosecurity.com, certificate.issuer: CNAmazon,OUServer CA 1B,OAmazon,CUS, certificate.not_valid_before: 1590969600, certificate.not_valid_after: 1625140800, certificate.key_alg: rsaEncryption, certificate.sig_alg: sha256WithRSAEncryption, certificate.key_type: rsa, certificate.key_length: 2048, certificate.exponent: 65537, san.dns: [ www.taosecurity.com, taosecurity.com, *.taosecurity.com ], basic_constraints.ca: false }第二条——签发者 CAfuidFZ7ygD3ERPfEVVohG9{ ts: 1598377391.938343, id: FZ7ygD3ERPfEVVohG9, certificate.version: 3, certificate.serial: 067F94578587E8AC77DEB253325BBC998B560D, certificate.subject: CNAmazon,OUServer CA 1B,OAmazon,CUS, certificate.issuer: CNAmazon Root CA 1,OAmazon,CUS, certificate.not_valid_before: 1445472000, certificate.not_valid_after: 1760832000, certificate.key_alg: rsaEncryption, certificate.sig_alg: sha256WithRSAEncryption, certificate.key_type: rsa, certificate.key_length: 2048, certificate.exponent: 65537, basic_constraints.ca: true, basic_constraints.path_len: 0 }第三条——根 CAfuidF7vklpOKI4yX9wmvh{ ts: 1598377391.938343, id: F7vklpOKI4yX9wmvh, certificate.version: 3, certificate.serial: 067F944A2A27CDF3FAC2AE2B01F908EEB9C4C6, certificate.subject: CNAmazon Root CA 1,OAmazon,CUS, certificate.issuer: CNStarfield Services Root Certificate Authority - G2,OStarfield Technologies\\, Inc.,LScottsdale,STArizona,CUS, certificate.not_valid_before: 1432555200, certificate.not_valid_after: 2145834000, certificate.key_alg: rsaEncryption, certificate.sig_alg: sha256WithRSAEncryption, certificate.key_type: rsa, certificate.key_length: 2048, certificate.exponent: 65537, basic_constraints.ca: true }第四条——交叉签名根 CAfuidFAnbnR32nIIr2j9XV{ ts: 1598377391.938343, id: FAnbnR32nIIr2j9XV, certificate.version: 3, certificate.serial: A70E4A4C3482B77F, certificate.subject: CNStarfield Services Root Certificate Authority - G2,OStarfield Technologies\\, Inc.,LScottsdale,STArizona,CUS, certificate.issuer: OUStarfield Class 2 Certification Authority,OStarfield Technologies\\, Inc.,CUS, certificate.not_valid_before: 1251849600, certificate.not_valid_after: 2035129156, certificate.key_alg: rsaEncryption, certificate.sig_alg: sha256WithRSAEncryption, certificate.key_type: rsa, certificate.key_length: 2048, certificate.exponent: 65537, basic_constraints.ca: true }这四张证书构成了一条完整、可验证的信任链www.taosecurity.com→ Amazon Server CA 1B → Amazon Root CA 1 → Starfield Services Root CA G2含交叉签名根。对防守团队而言这些记录蕴含大量可挖掘的情报价值可以在历史数据仓库中检索其他证书中出现的相同值例如 SAN、序列号、公钥指数exponent或key_alg/sig_alg组合从而发现入侵者活动模式之间的关联。证书字段的源码级解读这些字段并非凭空产生其取值由 X509.cc 中的 OpenSSL 调用逐项提取certificate.versionX509_get_version()返回值加 1DER 中版本号从 0 计起输出为人类可读的 1/2/3certificate.seriali2a_ASN1_INTEGER打印的十六进制序列号certificate.subject/certificate.issuerX509_NAME_print_ex按 RFC2253 格式输出这也是为什么签发者字段中出现\\,转义逗号如LScottsdale,STArizona中的Starfield Technologies\\, Inc.实为逗号被转义certificate.not_valid_before/not_valid_afterASN.1 时间转为 Unix 时间戳如1590969600即 2020-06-01certificate.key_alg/sig_alg公钥算法与签名算法的 ASN.1 OID 文本名rsaEncryption、sha256WithRSAEncryptioncertificate.key_type/key_length/exponent由EVP_PKEY提取。RSA 密钥给出rsa、位数EVP_PKEY_bits与公钥指数十进制字符串65537EC 密钥给出ecdsa与曲线名KeyCurve()DSA 密钥给出dsa。源码中还包含一个特殊分支某些 RDP 服务器证书错误地把密钥算法声明为md5WithRSAEncryptionZeek 会绕过 OID 直接按 RSA 解码公钥见 X509.ccsan.dns/san.uri/san.email/san.ip来自 Subject Alternative Name 扩展的解析见 X509.cc其中GEN_DNS类型归入san.dns向量GEN_URI、GEN_EMAIL、GEN_IPADD分别归入对应向量basic_constraints.ca/basic_constraints.path_len来自 Basic Constraints 扩展见 X509.cccatrue表示该证书是 CA 证书path_len表示允许的中间 CA 级数。这正是区分终端实体证书cafalse与链中 CA 证书catrue的关键字段。TLS 1.3 场景为什么没有 x509.log下面看 Curl 使用 TLS 1.3 产生的流量。作为参照该活动的ssl.log条目如下{ ts: 1598983678.585087, uid: CcJfBs3hXLJn7oHVu7, id.orig_h: 192.168.4.142, id.orig_p: 58802, id.resp_h: 13.32.202.2, id.resp_p: 443, version: TLSv13, cipher: TLS_AES_128_GCM_SHA256, curve: x25519, server_name: www.taosecurity.com, resumed: true, established: true }注意这条记录中完全没有证书的文件标识符没有cert_chain_fuids、没有subject、没有issuer。这意味着相应的x509.log中没有任何对应条目——本节标题本身就是一个“陷阱题”。原因在于协议设计TLS 1.3 在握手阶段对Certificate消息进行了加密只有完成密钥交换后的通信双方才能看到证书内容。网络侧的 Zeek 只能看到加密后的密文无法再解析出证书因此既无法产出x509.log也无法在ssl.log中填充证书链指纹、subject/issuer等字段。同样的可见性损失还发生在 SNI 上回顾上一节内容当 ESNIEncrypted SNI或 ECHEncrypted Client Hello启用时ssl.log中的server_name字段也会缺失。TLS 1.3 加上 ESNI/ECH意味着握手元数据中“证书”与“服务器名”两大情报来源同时被遮蔽。x509.log 的可配置选项与高级用法去重与重发策略默认情况下x509.log对重复出现的证书做去重处理同一张证书在去重窗口内只记录一次。相关选项定义在 scripts/base/files/x509/main.zeekX509::relog_known_certificates_after证书被重新记录前的最大间隔默认1day。设为0secs可完全禁用去重X509::known_log_certs_maximum_size已记录证书集合的最大大小默认 1,000,000X509::known_log_certs_enable_publish与X509::known_log_certs_enable_node_up_publish是否把已记录证书的哈希发布给集群其他节点 / 是否在 worker 上线时同步实现跨节点的全局去重见 main.zeek。去重的键由LogCertHash记录构成证书指纹 是否终端主机证书 是否客户端证书见create_deduplication_index钩子main.zeek。指纹使用的哈希函数可通过X509::hash_function选项更换默认sha256_hash更换后ssl.log与x509.log中的指纹会同步变化。证书事件缓存除了日志去重Zeek 还提供证书事件缓存机制降低高频证书的解析开销默认每张证书在 62 秒窗口内被遇到 10 次后其解析结果进入缓存后续相同证书按 SHA256 索引不再走 OpenSSL 完整解析而是由钩子x509_certificate_cache_replay重放缓存的事件。相关选项定义在 scripts/base/files/x509/certificate-event-cache.zeekX509::caching_required_encounters触发缓存所需的最小遇到次数默认 10设为 0 禁用缓存X509::caching_required_encounters_interval计数窗口默认 62 秒X509::certificate_cache_max_entries缓存最大条目数默认 10000。核心侧的缓存查找在 X509.cc 实现EndOfFile()先计算证书 DER 数据的 SHA256命中缓存即跳过解析并调用回调。更进一步策略脚本 scripts/policy/files/x509/disable-certificate-events-known-certs.zeek 会在证书事件缓存之上再加一层过滤如果同一服务器 IP、同一 SNI、同一证书 SHA256 在近期出现过则不重复抛出证书事件。该脚本可显著降低负载但代价是依赖“每连接证书事件”的检测脚本将不再收到事件——如果您的检测脚本需要每个连接都触发证书事件不应加载此脚本。把证书原文写入日志如果需要保留证书的原始内容可加载策略脚本 scripts/policy/protocols/ssl/log-certs-base64.zeek。它扩展了X509::Info的cert字段在x509_certificate事件中把证书 DER 内容 Base64 编码后写入日志并把X509::default_max_field_string_bytes置 0 以避免大证书被截断。其他日志相关选项X509::log_x509_in_files_log是否同时在files.log中记录证书文件条目默认F关闭因为证书信息已完整落在x509.log中见 main.zeekX509::default_max_field_string_bytes默认继承Log::default_max_field_string_bytes、X509::default_max_field_container_elements默认 500、X509::default_max_total_container_elements默认 1500控制长字符串与大容器如 SAN 列表的截断上限。由于证书可能携带超长 SAN 集合X.509 流在创建时专门放大了这些限制见 main.zeek。结论加密流量时代的证书取证本节内容表明默认配置下的x509.log即便面对加密流量也能为防守者提供大量有价值的信息完整的证书链、序列号、主题/签发者、有效期、密钥参数、SAN 与基本约束这些都可以作为威胁狩猎的检索键。但正如 TLS 1.3 示例所示随着管理员和攻击者逐步部署更新的加密技术TLS 1.3、ESNI、ECH证书与 SNI 等明文握手元数据正在快速消失。防守者将越来越难以仅凭x509.log与ssl.log区分正常、可疑与恶意的流量——这要求检测策略从“依赖明文元数据”向“结合加密流量分析、端点遥测与证书透明日志CT等外部证据”迁移。理解x509.log能提供什么、不能提供什么正是构建这一新检测体系的第一步。赞分享网络安全网络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点击查看免费下载相关推荐ESP-IDF 中的 x509 证书包ESP x509 Certificate BundleTLS 服务器证书验证的完整实战指南ESP IDF 中的 x509 证书包ESP x509 Certificate BundleTLS 服务器证书验证的完整实战指南 本文以 ESP IDF物联网嵌入式DeBERTa-V3-Base开发者手册模型结构、参数配置与迁移学习最佳实践DeBERTa V3 Base开发者手册模型结构、参数配置与迁移学习最佳实践 DeBERTa V3 Base是一个先进的自然语言处理模型它采用ELECTRA5步掌握BiliTools跨平台B站资源管理终极指南5步掌握BiliTools跨平台B站资源管理终极指南 还在为B站上的优质内容无法离线保存而烦恼吗BiliTools作为一款基于Tauri框架构建的跨平台哔哩桌面应用音视频上一篇如何用 Shopify Code Snippets 用 Liquid 获取购物车 Token快速解锁自定义加购下一篇Claude Code终端智能编码助手7大实战技巧提升开发效率创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考