security

在排查 HTTPS 连接问题时，能够解密 TLS 流量是极其重要的技能。Wireshark 支持通过 SSLKEYLOGFILE 方式解密 TLS 流量，本文详细介绍其工作原理和实操步骤。 工作原理 TLS 加密通信的安全性来自密钥交换过程。如果能够获取客户端和服务端协商出的密钥（Master Secret 或 Traffic Keys），就能解密捕获的 TLS 流量。 SSLKEYLOGFILE 是 NSS 密码库引入的一个特性，被 Chrome、Firefox、curl 等支持。客户端在建立 TLS 连接时，会将密钥材料写入指定文件，Wireshark 读取该文件即可解密流量。 ⚠️ 注意：本文仅用于调试自己的 TLS 连接。请勿用于窃听他人通信。 前置要求 Wireshark（支持 TLS 1.2 和 TLS 1.3 解密） 支持 SSLKEYLOGFILE 的客户端（如 Chrome、Firefox、curl、OpenSSL s_client） 环境准备 1. 创建 Keylog 文件 1 2 3 # 创建空文件用于存储密钥 touch ~/ssl-keylog.txt chmod 600 ~/ssl-keylog.txt 2. 配置环境变量 在 Linux/macOS 上： 1 export SSLKEYLOGFILE=~/ssl-keylog.txt 在 Windows 上（PowerShell）：...

介绍国密 SSL/TLS 算法（SM2/SM3/SM4），讲解在 OpenSSL 和 Nginx 中配置国密加密的实战方法。

交叉签名证书（Cross Signed Certificate）是 SSL/TLS 基础设施中一个重要但常被误解的概念。本文深入解释交叉签名的原理、适用场景以及 OpenSSL 操作方法。 什么是交叉签名？ 交叉签名是指由一个 CA（证书颁发机构）对另一个 CA 的证书进行签名。签名的对象是 CA 证书本身，而不是终端实体证书。 1 2 3 4 原始链：Root CA → Intermediate CA → Server Certificate 交叉签名链：Root CA (新) → Cross-signed Intermediate CA → Server Certificate ↑ 由新Root CA签名 关键特征： 交叉签名证书的 Subject（主题）与原始中间 CA 相同 Issuer（颁发者）变为进行交叉签名的根 CA 公钥与原始中间 CA 完全相同 典型使用场景 1. 多根 CA 信任 企业可能有两个不同的根 CA（如并购后的整合），需要让一张证书同时被两个根 CA 信任。 1 场景：公司有两个根 CA（Root CA 1 和 Root CA 2），都需要信任同一张服务器证书 2. 旧客户端兼容性 某些老旧客户端只信任特定的根 CA，通过交叉签名让新证书也能被这些客户端接受。...

深入解析 OpenSSL Engine 架构，讲解如何通过 Engine 接口集成 HSM、PKCS#11 设备、云 KMS 等外部加密服务。

在配置 HTTPS 时，ECDHE（椭圆曲线 Diffie-Hellman 密钥交换）是实现完全前向保密（PFS）的核心机制。但很多人忽视了曲线选择的重要性——不同的椭圆曲线在安全级别和性能上差异显著。本文详细介绍 Nginx 中如何选择和配置椭圆曲线。 椭圆曲线基础 椭圆曲线密码学（ECC）相比传统 RSA 具有更短的密钥和更高的安全性。以常见的曲线为例： 曲线 密钥长度 安全级别 适用场景 prime256v1 (secp256r1) 256 位 约 128 位 通用场景，推荐 X25519 256 位 约 128 位 现代推荐，更快 secp384r1 384 位 约 192 位 高安全需求 secp521r1 521 位 约 256 位 最高安全级别 注意：X25519 是蒙哥马利曲线，只用于密钥交换；secp256r1 是魏尔斯特拉斯曲线，可同时用于密钥交换和数字签名。 查看 Nginx 支持的曲线 首先确认 Nginx 编译时支持的椭圆曲线列表： 1 2 3 4 5 # 查看 Nginx 支持的曲线 nginx -V 2>&1 | grep -o "X25519\|secp256r1\|secp384r1" # 运行时查看 OpenSSL 支持的曲线 openssl ecparam -list_curves | grep -E "prime256v1|secp384r1|X25519" 输出示例：...

在 TLS 1.3 的握手过程中，客户端首先发送 ClientHello 消息，其中包含支持的密码套件、扩展和密钥共享参数。有时候服务端发现客户端提供的参数需要调整，就会发送一个特殊的响应——Hello Retry Request（简称 HRR）。本文详解 HRR 的触发条件、工作原理和实际观察方法。 什么是 Hello Retry Request Hello Retry Request 是 TLS 1.3 引入的一种握手优化机制。当服务端收到的 ClientHello 消息中的参数不符合要求时（比如缺少必要的密钥共享、密码套件不匹配等），服务端不会直接拒绝连接，而是发送一个 HelloRetryRequest 消息，要求客户端重新发送带有正确参数的 ClientHello。 这与 TLS 1.2 的行为形成对比——TLS 1.2 中如果密码套件不兼容，服务端会直接发送 Handshake Failure 警报并终止连接。 HRR 的触发条件 HRR 主要在以下几种情况被触发： 1. Key Share 不符合要求 客户端发送的 key_share 扩展中提供的密钥共享参数不被服务端接受。常见原因包括： 使用了服务端不支持的椭圆曲线 密钥共享参数格式不正确 2. 缺少必要的 Cookie 服务端要求验证客户端身份时，会在 HRR 中包含 cookie 扩展，客户端下一次 ClientHello 必须原样返回这个 Cookie。 3. 密码套件协商 虽然现代 TLS 1.3 实现通常支持所有标准密码套件，但在某些特殊配置下，服务端可能要求客户端使用特定的套件。 HRR 工作流程 完整的 HRR 流程如下：...

在 TLS 协议通信过程中，当发生错误或需要通知对方某些情况时，Alert Protocol（告警协议） 就会发挥作用。理解告警协议有助于排查 TLS 连接问题和进行安全调试。 什么是 TLS Alert Protocol TLS Alert Protocol是 TLS 记录层的子协议之一，用于在 TLS 会话中传递告警信息。这些告警可以是： 警告（Warning）：告知对方注意某些情况，但不会中断连接 致命错误（Fatal）：导致连接立即关闭 告警消息通常在以下场景出现： 证书验证失败 握手过程出错 加密操作异常 协议版本不兼容 告警消息格式 每个告警消息包含两个字段： 字段 长度 说明 Alert Level 1 字节 1 = Warning，2 = Fatal Alert Description 1 字节 具体告警类型的编号 1 2 3 4 +----------------+----------------+ | Alert Level | Alert Descr | | (1 byte) | (1 byte) | +----------------+----------------+ 告警级别 Warning（警告） 警告级别告警不会终止连接，但可能影响后续通信。常见警告包括： close_notify：正常关闭通知 no_certificate：无可用证书 bad_certificate：证书格式有问题 unsupported_certificate：不支持的证书类型 certificate_revoked：证书已吊销 certificate_expired：证书已过期 certificate_unknown：证书未知 Fatal（致命） 致命告警会导致连接立即关闭。常见致命告警包括：...

DNS CAA（Certification Authority Authorization）记录是一种 DNS 记录类型，用于声明哪些证书颁发机构（CA）可以为特定域名颁发 SSL/TLS 证书。作为域名所有者，通过配置 CAA 记录，可以有效防止未经授权的证书被颁发，保护网站安全。 什么是 CAA 记录 CAA 记录于 2013 年在 RFC 6844 中定义，允许域名管理者明确指定允许为该域名颁发证书的 CA。CAA 记录的工作原理是：当 CA 收到证书申请时，会查询域名的 DNS CAA 记录，如果发现没有授权给自己，则拒绝颁发证书。 CAA 记录的作用 防止证书被冒领：阻止未经授权的 CA 为你的域名颁发证书 提升安全等级：确保只有指定的 CA 可以提供证书服务 审计追踪：CAA 记录可以要求 CA 在颁发证书时发送通知 CAA 记录格式详解 CAA 记录的基本格式如下： 1 CAA <flags> <tag> <value> 关键字段 字段 说明 flags 8 位标志字段，目前使用 bit 0（关键位） tag 标签，指定 CAA 记录的类型的 value 标签对应的值 常用标签 CAA 记录支持多种标签，常用的包括： 标签 说明 示例 issue 授权指定 CA 颁发证书 issue "letsencrypt....

预共享密钥（PSK，Pre-Shared Key）是 TLS 1.3 引入的重要特性，允许通信双方在握手前共享对称密钥，简化握手流程并提升性能。本文详细介绍 PSK 的原理、使用场景以及 OpenSSL 命令行实战。 什么是 PSK？ PSK 是一种在 TLS 握手前就共享的对称密钥。在传统 TLS 握手过程中，客户端和服务端需要通过公钥密码学协商出共享密钥；而使用 PSK 时，双方直接使用预先共享的密钥进行加密通信。 PSK 的优势 减少握手延迟：省去公钥协商步骤，缩短握手时间 降低计算开销：无需执行昂贵的非对称加密运算 适用于特定场景：物联网设备、CDN 加速等对性能要求高的场景 PSK 的使用场景 会话恢复（Session Resumption）：TLS 会话恢复本质上使用 PSK 物联网设备：计算资源受限的设备间安全通信 CDN 边缘节点：需要快速建立大量连接的场景 内部服务通信：在可信网络中使用对称密钥 PSK 密钥生成 PSK 密钥通常是 256 位（32 字节）的随机数据。使用 OpenSSL 生成： 1 2 # 生成 256 位 PSK 密钥（32 字节 = 64 个十六进制字符） openssl rand -hex 32 输出示例： 1 779cfa0b22020c13ae4e841e0c96b1b90b3afa48f6bcb85192f1694156676aac ⚠️ 注意：PSK 密钥必须安全存储和传输，不要在代码中硬编码或通过网络明文传输。 OpenSSL s_client PSK 测试 基础连接测试 使用 PSK 连接到支持 PSK 的服务器：...

TLS 1.3 作为最新版本的传输层安全协议，在握手效率和安全性方面做了重大改进。其中，密钥更新（Key Update）机制是一个重要的安全特性，允许在不重新握手的情况下更新加密密钥，从而延长加密会话的生命周期，同时保持前向安全性。 什么是密钥更新机制？ 密钥更新（Key Update）是 TLS 1.3 协议定义的 POST-HANDSHAKE 消息之一。在 TLS 1.3 中，握手完成后的加密通信使用两类密钥： 应用流量密钥（Application Traffic Keys）：用于加密实际的应用数据 握手流量密钥（Handshake Traffic Keys）：仅用于加密握手消息 传统的 TLS 1.2 想要更新密钥必须重新握手，这会增加延迟。TLS 1.3 引入了 KeyUpdate 消息，允许双方在不中断连接的情况下动态更新应用流量密钥。 为什么需要密钥更新？ 1. 限制单密钥加密数据量 现代加密算法在加密大量数据后，理论上存在被破解的风险（尽管概率极低）。定期更新密钥可以： 减少每个密钥加密的数据量 降低潜在的安全风险 满足某些合规要求 2. 保持前向安全性 TLS 1.3 的密钥派生使用 HKDF，从原始握手密钥派生出应用流量密钥。即使某个会话密钥被破解，之前的通信仍然是安全的。密钥更新机制让这一特性在长会话中持续生效。 3. 减少握手开销 相比完整的重新握手，KeyUpdate 消息只包含几个字节，延迟几乎可以忽略不计。 KeyUpdate 消息格式 TLS 1.3 的 KeyUpdate 消息结构简洁高效： 1 2 3 4 5 6 7 8 9 struct { KeyUpdateRequest request; } KeyUpdate; enum { update_not_requested(0), update_requested(1), (255) } KeyUpdateRequest; update_not_requested(0)：我已更新密钥，但不希望对方也更新 update_requested(1)：我已更新密钥，并请求对方也更新 工作流程详解 密钥更新的完整流程如下：...