ssl

引言 CRYSTALS-Kyber 是 NIST 后量子密码学标准中的核心密钥封装机制（Key Encapsulation Mechanism, KEM），于 2024 年正式发布。作为 TLS 1.3 未来版本中 ECDHE 的潜在替代方案，理解 Kyber 的工作原理对于安全工程师至关重要。本文将深入解析 Kyber 的数学基础和工作流程。 1. 为什么需要后量子 KEM？ 传统 TLS 1.3 使用 ECDHE（椭圆曲线 Diffie-Hellman）进行密钥交换，其安全性基于有限域上离散对数问题的困难性。 量子计算机的 Shor 算法能在多项式时间内解决： 整数分解问题（RSA 密钥） 离散对数问题（ECDSA、ECDHE 密钥） 这意味着：一旦拥有足够大规模的量子计算机，当前基于 RSA 和 ECC 的密钥交换将不再安全。 后量子密码学（Post-Quantum Cryptography, PQC）应运而生——设计能够抵御量子攻击的经典算法。NIST 于 2024 年正式发布后量子密码学标准，CRYSTALS-Kyber 正是其中的核心算法。 2. 格理论基础 Kyber 的安全性建立在**格理论（Lattice-based Cryptography）**之上。 什么是格？ 格（Lattice）是 n 维空间中一组线性无关向量的整数线性组合。用数学语言描述： 给定 n 个线性无关的向量 b₁, b₂, …, bₙ ∈ ℝⁿ，格 L 是这些向量的所有整数线性组合的集合： 1 L = { Σᵢ aᵢbᵢ | aᵢ ∈ ℤ } 格困难问题 格密码学的安全性基于以下困难问题：...

什么是 OCSP Must-Staple OCSP Must-Staple（RFC 6066 第 8 节定义）是一种证书扩展，用于告知客户端证书颁发机构（CA）要求在 TLS 握手时必须提供 OCSP 响应。通过此扩展，客户端可以拒绝与无法提供有效 OCSP 响应（或 OCSP stapling）的服务器建立连接。 作用机制 当证书包含 Must-Staple 扩展时： 服务器端：必须在 TLS 握手时通过 OCSP stapling 发送预缓存的 OCSP 响应 客户端验证：支持 Must-Staple 的客户端会检查 stapled OCSP 响应是否存在且有效 连接拒绝：如果服务器未提供有效的 OCSP 响应，客户端将拒绝建立连接 安全价值 Must-Staple 主要防止以下攻击场景： 防止吊销绕过：攻击者无法通过阻止客户端直接查询 OCSP 服务器来绕过证书吊销检查 减少客户端到 CA 的网络请求：通过 stapling 减少延迟和隐私泄露 强制证书状态检查：确保每次连接都进行证书有效性验证 验证证书是否包含 Must-Staple 使用 Let’s Encrypt 证书（推荐） Let’s Encrypt 签发的证书默认包含 Must-Staple 扩展。可以使用以下方式验证： 1 2 # 查看证书扩展信息 openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -text | grep -i "ocsp" 如果证书包含 Must-Staple，会看到类似输出：...

概述 随着量子计算技术的发展，传统加密算法面临潜在威胁。SSH 作为最常用的远程访问协议，其安全性尤为重要。本文介绍 OpenSSH 后量子密钥交换的配置方法，帮助管理员保护 SSH 连接免受"现在收集，以后解密"（Harvest Now, Decrypt Later）攻击。 为什么需要后量子密钥交换？ “现在收集，以后解密"攻击 即使量子计算机尚未实用化，攻击者已经开始收集加密的 SSH 流量。当量子计算机足够强大时，这些历史数据可能被解密。这就是所谓的"现在收集，以后解密”（也称"收获现在，解密 later"）攻击。 OpenSSH 官方文档指出：整个 SSH 连接的隐私取决于密钥协商。如果攻击者能够破解密钥协商，他们就能解密整个会话。攻击者无需实时执行此攻击——他们可以现在收集加密的 SSH 会话，然后在获得量子计算机后解密。 时间线 现在：攻击者开始收集加密数据 2030 年左右：RSA 和 ECDH 可能被量子计算机破解 2035 年：NIST 建议全面迁移到后量子密码学 OpenSSH 后量子支持历程 版本 发布时间 后量子支持 OpenSSH 9.0 2022年4月 默认启用 sntrup761x25519-sha512 OpenSSH 9.9 2024年 新增 mlkem768x25519-sha256 OpenSSH 10.0 2025年4月 mlkem768x25519-sha256 成为默认 OpenSSH 10.1 未来 未使用后量子算法时发出警告 RFC 9941 2026年4月 标准化 sntrup761x25519-sha512 支持的算法 混合密钥交换算法 sntrup761x25519-sha512 混合：NTRU Prime (sntrup761) + X25519 SHA-512 用于密钥派生 RFC 9941 标准化 mlkem768x25519-sha256...

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....