openssl speed 是 OpenSSL 官方提供的加密算法性能基准测试工具。通过它可以了解不同加密算法在当前硬件上的处理速度，从而为生产环境选择合适的加密算法提供数据支撑。 基本用法 1 openssl speed [options] [algorithm...] 常用选项： -seconds N — 测试持续时间（默认 10 秒） -bytes N — 测试缓冲区大小（默认 16KB） -evp name — 使用 EVP 接口测试指定算法 -elapsed — 使用 wall-clock 时间而非 CPU 时间 -mr — 产生机器可读的输出 对称加密算法性能测试 测试 AES-256-GCM 1 2 3 4 5 6 7 8 9 10 $ openssl speed -seconds 1 -evp aes-256-gcm Doing AES-256-GCM for 1s on 16 size blocks: 1502986 AES-256-GCM's in 1....

漏洞概述 2026 年 1 月 27 日，OpenSSL 官方发布了安全公告，披露了一个高危漏洞 CVE-2025-15467。该漏洞位于 OpenSSL 的 CMS（Cryptographic Message Syntax）实现中，当处理使用 AEAD（Authenticated Encryption with Associated Data）密码的 AuthEnvelopedData 结构时，存在栈缓冲区溢出问题。 漏洞严重性评级为 High，可导致拒绝服务（DoS），在特定条件下甚至可能实现远程代码执行（RCE）。 影响版本 受影响的 OpenSSL 版本： OpenSSL 3.6.x OpenSSL 3.5.x OpenSSL 3.4.x OpenSSL 3.3.x OpenSSL 3.0.x 不受影响的版本： OpenSSL 1.1.1 OpenSSL 1.0.2 修复版本： OpenSSL 3.6.1 OpenSSL 3.5.5 OpenSSL 3.4.4 OpenSSL 3.3.6 OpenSSL 3.0.19 技术分析 CMS 简介 CMS（Cryptographic Message Syntax，RFC 5652）是一种用于签名、加密消息的通用语法标准，广泛应用于： S/MIME：安全电子邮件 PKCS#7：加密消息语法 代码签名 证书管理（如 CRL、证书请求） CMS 支持多种加密数据格式，包括： EnvelopedData：加密数据 SignedData：签名数据 AuthEnvelopedData：带认证的加密数据（AEAD） AEAD 密码与 AES-GCM AEAD（Authenticated Encryption with Associated Data）是一种同时提供机密性和完整性的加密模式。常见的 AEAD 密码包括：...

深入解析TLS握手过程中，每条消息在何时被加密，以及TLS 1.2与TLS 1.3在这方面的重要区别。

在部署 HTTPS 服务时，选择 RSA 还是 ECDSA 证书是一个常见问题。这两种签名算法在安全强度、证书大小、握手性能和兼容性上存在显著差异。本文基于实测数据和实际案例，帮助你做出明智的选择。 核心差异一览 指标 RSA 2048 ECDSA P-256 备注 密钥长度 2048 bits 256 bits ECDSA 密钥短得多 证书大小 ~1100 bytes ~562 bytes ECDSA 证书约小一半 私钥大小 ~1704 bytes ~302 bytes ECDSA 私钥约小 82% 安全强度 ~112 bits ~128 bits P-256 比 RSA 2048 更强 签名大小 256 bytes 64 bytes ECDSA 签名更紧凑 以上数据基于 OpenSSL 本地生成的自签名证书实测。 为什么 ECDSA 更高效？ 1. 更小的证书体积 ECDSA 证书比 RSA 证书小约一半，这意味着： 更少的 TCP 分段：证书需要更少的网络数据包传输 更低的丢包敏感度：在移动网络环境下，减少 TCP 重传 更快的传输：握手阶段传输的数据更少 从 Wireshark 抓包数据来看：...

背景：量子计算威胁与 TLS 量子计算机的快速发展对现有加密体系构成了潜在威胁。Shor 算法能够在多项式时间内分解大整数和计算离散对数，这意味着当前的 RSA、ECDSA 等公钥密码系统将可能被破解。SSL/TLS 协议中依赖的密钥交换和数字签名都可能受到影响。 虽然大规模量子计算机尚未出现，但"现在收集，以后解密"（harvest now, decrypt later）攻击已经是一种现实威胁 —— 攻击者可以预先收集加密流量，等待量子计算机足够强大时进行解密。 面对这一威胁，TLS 协议社区开发了混合密钥交换（Hybrid Key Exchange）方案，在传统算法基础上叠加后量子算法，实现"双重保险"。 什么是混合密钥交换 混合密钥交换同时使用两种不同的密钥交换算法，将其结果组合生成最终的会话密钥： 1 最终密钥 = HKDF(传统密钥交换结果 || 后量子密钥交换结果) 这种方案的优势在于： 兼容性：至少一个算法是传统经典算法，确保与旧系统兼容 安全性：即使量子计算机破解了其中一种算法，攻击者仍无法获得完整密钥 渐进性：可以逐步在网络中部署后量子算法 X25519MLKEM768 详解 X25519MLKEM768 是 TLS 1.3 中最常用的混合密钥交换组合： 组件 类型 算法 X25519 传统 Curve25519 ECDH ML-KEM-768 后量子 Kyber-768 (NIST Level 3) X25519 X25519 是基于 Curve25519 曲线的椭圆曲线 Diffie-Hellman 密钥交换协议，目前被广泛使用。它提供 128 位的安全强度，已被包括 Apple、Google 在内的主要厂商采用。 ML-KEM-768 ML-KEM（Module-Lattice-Based Key-Encapsulation Mechanism）是 NIST 后量子密码学标准中的密钥封装机制，基于 Kyber 算法。它提供约 192 位的安全强度（NIST Level 3），能够抵抗量子计算机攻击。...

QUIC（Quick UDP Internet Connections）是 Google 在 2013 年提出的新一代传输层协议，2018 年 IETF 将其标准化为 RFC 9000。QUIC 最显著的特点是将加密握手与可靠传输结合在一起，实现了 0-RTT 快速连接。本文深入剖析 QUIC 的加密机制，帮助读者理解它与传统 TLS 的区别。 QUIC 加密层概述 QUIC 的加密层位于传输层之上，但与传统 TLS 有本质不同： 特性 传统 TLS QUIC 承载协议 TCP UDP 加密层位置 TLS 层在 TCP 之上 QUIC 内置加密，集成在传输层 握手次数 1-RTT 或 0-RTT 1-RTT 或 0-RTT（更高效） 头加密 可选 必须加密 QUIC 的加密设计遵循 “加密 everything” 原则，尽可能减少明文传输。 QUIC 握手与密钥派生 QUIC 使用 TLS 1.3 的握手结果，但有自己的密钥派生流程。QUIC 的密钥派生使用 HKDF（HMAC-based Key Derivation Function），与 TLS 1.3 相同。...

TLS 握手失败是 HTTPS 连接问题中最常见的情况之一。当浏览器显示"ERR_CONNECTION_CLOSED"或"PR_CONNECT_RESET_ERROR"等错误时，很可能是 TLS 握手出现了问题。本文将深入讲解 TLS 握手失败的常见原因，以及如何使用 OpenSSL 工具进行诊断和排查。 1. TLS 握手失败概述 TLS 握手是建立安全连接的关键过程，涉及版本协商、加密套件选择、证书验证、密钥交换等多个步骤。任何一步出现问题都可能导致握手失败。 握手失败通常表现为： 浏览器无法加载页面 连接立即关闭 证书错误警告 协议不兼容错误 2. 常见的握手失败原因 2.1 证书问题 证书相关问题是握手失败的最常见原因： 证书过期：服务器证书已过有效期 域名不匹配：证书 CN/SAN 与访问域名不一致 证书链不完整：中间证书缺失 自签名证书：客户端不信任该 CA 证书被吊销：CRL/OCSP 检查失败 2.2 协议版本不兼容 客户端和服务器支持的 TLS 版本不匹配： 客户端只支持 TLS 1.0/1.1，服务器已禁用 客户端不支持 TLS 1.3，服务器只启用 TLS 1.3 使用废弃的 SSL 协议 2.3 加密套件不匹配 服务器不支持客户端提供的任何加密套件： 服务器只启用了较旧的加密套件 客户端请求的加密套件被服务器禁用 客户端和服务器没有共同的加密套件 2.4 客户端证书问题（mTLS 场景） 在双向 TLS 认证中： 客户端证书过期或无效 客户端证书不在服务器信任列表中 3. 使用 OpenSSL 诊断 3.1 基本诊断命令 1 2 3 4 5 # 基础连接测试，获取证书和握手信息 openssl s_client -connect example....

在生产环境中，更新 TLS 证书是一个常见但敏感的操作。如果直接重启 Nginx 服务，会导致连接中断，影响用户体验。本文介绍如何在 Nginx 中实现 TLS 证书的热更新，在不中断服务的情况下完成证书更新。 什么是证书热更新？ 证书热更新（Hot Reload）是指在不停止服务的情况下，重新加载新的证书文件。Nginx 支持通过发送 reload 信号来实现配置和证书的平滑重新加载。 与完全重启（nginx -s stop 然后 nginx）相比，reload 的优势在于： 不会中断正在处理的请求 平滑过渡，新连接使用新证书，旧连接继续使用旧证书 服务可用性不受影响 Nginx reload 机制 Nginx 支持以下几种信号： nginx -s reload - 平滑重新加载配置 kill -HUP <master_pid> - 发送 HUP 信号，作用与 reload 相同 kill -USR1 <master_pid> - 重新打开日志文件 kill -USR2 <master_pid> - 优雅升级（用于升级 Nginx 二进制文件） 当 Nginx 收到 reload 信号时： 主进程（Master Process）解析新的配置文件 如果配置合法，主进程启动新的工作进程（Worker Process） 旧的工作进程优雅退出（处理完现有连接后关闭） 新的工作进程使用新的证书 证书热更新操作步骤 1. 准备新的证书文件 首先，将新的证书和私钥文件复制到指定目录：...

当我们讨论 HTTPS 安全性时，证书吊销检查是一个常被忽视但至关重要的环节。传统的 OCSP（Online Certificate Status Protocol）存在隐私和性能问题，Mozilla 提出的 CRLite 提供了一种更优的解决方案。本文将深入探讨 CRLite 的设计原理、与 OCSP 的对比，以及如何在实际环境中应用。 传统 OCSP 的问题 在了解 CRLite 之前，我们先回顾一下传统 OCSP 面临的挑战： 1. 隐私泄露 OCSP 请求会直接向 CA 的 OCSP 服务器发送请求，这会暴露用户的浏览行为。攻击者可以通过监控 OCSP 请求来确定用户正在访问哪些网站。 1 2 # 模拟 OCSP 请求 openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 10 "OCSP response" 2. 性能瓶颈 每次建立 HTTPS 连接时，客户端都需要额外查询 OCSP 服务器，这增加了握手延迟。如果 OCSP 服务器响应缓慢，会直接影响用户体验。 1 2 3 # 测试 OCSP 响应状态（使用 timeout 防止卡住） timeout 5 openssl s_client -connect ocsp....

在生产环境中配置 HTTPS 时，经常会遇到各种问题。本文总结 Nginx SSL 配置中的常见错误及其排查方法，帮助你快速定位和解决问题。 1. 证书链顺序错误 常见症状 浏览器显示证书链不完整或提示「此证书链不受信任」： 1 2 # 使用 openssl s_client 查看证书链 echo | openssl s_client -connect example.com:443 -showcerts 2>/dev/null | grep -E "subject=|issuer=" 问题原因 Nginx 配置的证书文件只包含服务器证书，没有包含中间证书（Intermediate Certificate）。 解决方法 将证书链按正确顺序拼接：服务器证书 → 中间证书 → 根证书（可选）。 1 2 3 4 # 正确的证书链顺序 cat server.crt > nginx-ssl.crt cat intermediate.crt >> nginx-ssl.crt # 根证书通常不需要添加 Nginx 配置： 1 2 3 4 5 6 7 8 9 server { listen 443 ssl; server_name example....