SSH 证书认证是一种比传统公钥认证更安全的方案。本文介绍 SSH 证书的工作原理和配置方法。 传统公钥认证的问题 传统的 SSH 公钥认证需要在每台服务器上添加用户的公钥： 1 2 # 用户将公钥发送到服务器 ssh-copy-id user@server 这种方式在大规模环境中存在以下问题： 密钥管理困难：新增或撤销用户需要手动更新所有服务器 无时效性：公钥永久有效，离职后难以撤销 无法追踪：无法知道谁在什么时候登录过 扩展性差：成百上千台服务器时维护成本极高 SSH 证书认证的原理 SSH 证书认证引入**证书颁发机构（CA）**的概念： CA 密钥：管理员创建一个 CA 私钥，用于签发证书 用户证书：CA 使用私钥对用户公钥进行签名，生成证书 服务器信任 CA：服务器只需配置信任 CA 公钥，无需逐个添加用户公钥 证书验证：用户登录时提交证书，服务器通过 CA 公钥验证证书有效性 证书包含的信息 用户公钥 用户 ID（Key ID） 有效期（起始时间 + 结束时间） 允许的登录用户名（Principals） CA 签名 创建 SSH CA 首先创建 CA 密钥对。建议使用 ED25519 算法： 1 2 3 4 5 # 创建用户证书CA ssh-keygen -t ed25519 -f ~/.ssh/user_ca -C "SSH User CA" # 创建主机证书CA（可选，用于验证服务器身份） ssh-keygen -t ed25519 -f ~/....

量子计算的快速发展对现代密码学构成了前所未有的威胁。当前广泛使用的 RSA、ECDSA 等公钥密码算法依赖于大整数分解或离散对数问题的计算难度，但量子计算机的 Shor 算法可以在多项式时间内解决这些问题。这意味着当大规模量子计算机成熟时，现有的 SSL/TLS 证书、SSH 密钥、数字签名都将面临被破解的风险。 什么是后量子密码学 后量子密码学（Post-Quantum Cryptography，PQC）是指能够在经典计算机上运行，但能够抵御量子计算机攻击的密码学算法。这些算法不依赖量子力学原理，而是基于量子计算机也难以高效求解的数学问题，如格密码（Lattice-Based）、编码密码（Code-Based）、多变量密码（Multivariate）等。 与量子密钥分发（QKD）不同，PQC 是软件层面的解决方案，可以在现有硬件和网络上部署，无需专门的量子通信设备。 NIST PQC 标准化进程 美国国家标准与技术研究院（NIST）自 2016 年启动后量子密码学标准化项目，经过多轮筛选，于 2024 年 8 月发布了首批三个最终标准。 首批发布的三个标准 标准名称 类型 底层技术 用途 ML-KEM 密钥封装机制 模块格（Module-Lattice） 密钥交换、TLS 握手 ML-DSA 数字签名 模块格（Module-Lattice） 证书签名、代码签名 SLH-DSA 数字签名 哈希（Hash-Based） 替代签名方案 ML-KEM（原 Kyber）是基于格理论的密钥封装机制，将取代传统的 Diffie-Hellman 密钥交换，用于 TLS 1.3 握手阶段的密钥协商。 ML-DSA（原 Dilithium）是基于格理论的数字签名算法，将作为主要的签名方案，用于 SSL/TLS 证书、代码签名等场景。 SLH-DSA（原 SPHINCS+）是基于哈希的签名算法，作为备份方案，安全性基于哈希函数的抗碰撞性。 正在标准化的候选算法 除了首批三个标准，NIST 还在评估以下算法： Falcon：基于格的高效签名算法，签名更短，适用于带宽受限场景 HQC：基于编码的密钥封装机制，提供额外的安全保障 实际影响与迁移时间线 对 TLS/SSL 的影响 当前的 TLS 协议使用 RSA 或 ECDSA 进行身份验证，使用 ECDHE 进行密钥交换。迁移到 PQC 后：...

什么是证书透明度 证书透明度（Certificate Transparency，简称 CT）是 Google 提出的一个开源框架，旨在为 TLS 证书提供公开的审计和监控机制。它的核心目标是检测恶意或错误签发的证书，防止证书颁发机构（CA）未经授权签发证书。 在 CT 出现之前，如果某个 CA 被攻击或故意签发虚假证书，这些证书可能在很长时间内不被发现。CT 通过要求所有证书必须记录在公开的日志服务器上，使得任何人都可以审计证书签发行为。 CT 架构解析 证书透明度由三个核心组件构成： 1. 日志服务器（Log Server） 日志服务器是 CT 的核心，是一个仅追加（append-only）的 Merkle 树结构数据库。每个日志服务器接收并存储证书条目，主要特性： 仅追加：一旦记录被添加，就不能删除或修改 Merkle 树：使用密码学哈希树结构，可以高效验证数据完整性 公开可访问：任何人都可以提交证书或查询日志 主流的公开日志服务器包括： Google Argon（ct.googleapis.com/pki/argon) DigiCert Log（ct.digicert.com/log) Let’s Encrypt（ct.letsencrypt.org) 2. 监控器（Monitor） 监控器定期检查日志服务器，查找可疑的证书签发行为。例如： 为知名域名签发的异常证书 仿冒知名网站的证书 来自不可信 CA 的证书 常见的监控服务包括： crt.sh - 免费证书搜索数据库 Google Monitor Cloudflare Monitor 3. 审计员（Auditor） 审计员验证日志服务器的行为，确保它们： 正确记录了所有提交的证书 没有作弊或隐瞒记录 响应一致的查询 浏览器通常内置审计员功能，在验证证书时自动检查 SCT。 SCT：签名证书时间戳 当证书被提交到 CT 日志时，日志服务器会返回 Signed Certificate Timestamp（SCT）。SCT 包含： 日志服务器 ID：签发 SCT 的日志服务器标识 序列号：该证书在日志中的唯一编号 时间戳：证书被记录的时间 签名：日志服务器对上述信息的数字签名 浏览器在验证 TLS 连接时，会检查证书是否附带有效的 SCT。根据浏览器策略，通常要求至少 1-2 个 SCT 才能完全信任证书。...

深入解析 TLS 1.3 密钥派生机制，HKDF 工作原理以及在 OpenSSL 中的实际应用。

TLS 记录协议（Record Protocol）是 TLS 协议栈的最底层，负责对数据进行分片、压缩、计算 MAC、加密和传输。理解它的工作原理有助于深入掌握 TLS 安全机制。 记录协议的核心功能 记录协议接收上层数据后，依次经过以下处理流程： 分片：将数据切分为固定大小的记录块 压缩：对数据进行压缩（TLS 1.3 已废弃） MAC 计算：添加消息认证码 加密：对数据加密 传输：发送加密后的数据 分片机制 每个 TLS 记录包含一个 5 字节的头部和可变长度的载荷： 1 2 3 4 5 +-----------+------------+----------------+ | 类型(1) | 版本(2) | 长度(2) | <- 头部 (5 字节) +-----------+------------+----------------+ | 加密数据... | <- 载荷 +-----------+---------------------------+ 类型：Content Type，1 字节，标识记录类型 0x14 = ChangeCipherSpec 0x15 = Alert 0x16 = Handshake 0x17 = Application Data 版本：Protocol Version，2 字节（TLS 1.2 为 0x0303，TLS 1....

TLS 1.3 引入了 0-RTT（Zero Round Trip Time，零往返时间）模式，旨在减少连接延迟，提升用户体验。本文深入解析 0-RTT 的工作原理、安全风险以及如何正确配置。 什么是 0-RTT？ 0-RTT 是 TLS 1.3 引入的新特性，允许客户端在首次握手时就开始发送加密数据，无需等待服务器完成握手。相比传统的 1-RTT 或 2-RTT 模式，这可以显著减少建立连接所需的时间。 各版本 TLS 的往返次数 TLS 版本 模式 往返次数（RTT） TLS 1.2 RSA 完整握手 2-RTT TLS 1.2 ECDHE 完整握手 1-RTT TLS 1.3 完整握手 1-RTT TLS 1.3 0-RTT 0-RTT 工作原理 首次连接（建立会话） 1 2 3 4 客户端 ───── ClientHello ────> 服务器 客户端 <─── ServerHello ───── 服务器 客户端 <─── 加密完成 ───────── 服务器 (+Session Ticket) 客户端发送 ClientHello，请求建立 TLS 1....

完美前向保密（Perfect Forward Secrecy, PFS）是现代 TLS 连接的核心安全特性。它确保即使服务器的长期私钥在未来被泄露，攻击者也无法解密过去捕获的加密通信。 本文将深入理解 PFS 的工作原理、密钥交换机制差异，以及如何在实战中验证和配置 PFS。 什么是完美前向保密 要理解 PFS，先看一个没有 PFS 的场景： 1 2 3 4 5 6 7 8 Client Server | | | --- ClientHello ------->| | <--- ServerHello --------| (包含服务器 RSA 公钥) | | | -- PreMasterSecret ---->| (用服务器 RSA 公钥加密) | | | <-- Encrypted Data ---->| (双方用派生的会话密钥加密) 在传统的 RSA 密钥交换中，客户端生成一个 PreMasterSecret，用服务器的 RSA 公钥加密后发送。服务器用自己的 RSA 私钥解密。这里的致命问题是：任何人如果记录了这段加密通信，并且在未来获得了服务器的 RSA 私钥，就能解密 PreMasterSecret，进而解密所有历史通信数据。 引入 PFS 后，情况完全不同： 1 2 3 4 5 6 7 8 9 10 Client Server | | | --- ClientHello ------->| | <--- ServerHello --------| (包含服务器临时 ECDHE 公钥) | | | -- Client ECDHE Pub --->| (客户端临时公钥) | | | (双方各自独立计算共享密钥，不通过网络传输) | | | <-- Encrypted Data ---->| (通信结束后临时密钥立即销毁) 使用 ECDHE 或 DHE 等临时密钥交换时，每次连接都会生成一对新的临时密钥。双方通过 Diffie-Hellman 计算得到一个共享密钥，这个密钥从未在网络上传输过，并且在连接结束后就被销毁。...

什么是 ALPN ALPN（Application-Layer Protocol Negotiation，应用层协议协商）是 TLS 协议的一个扩展，定义于 RFC 7301。它允许客户端和服务器在 TLS 握手阶段就协商好使用哪个应用层协议，而无需额外的往返通信。 如果没有 ALPN，客户端只能先建立 TLS 连接，再通过 NPN（Next Protocol Negotiation，已废弃）或在 TLS 握手完成后通过额外协商来确定使用 HTTP/1.1 还是 HTTP/2。ALPN 将这个过程整合到 TLS 握手中，减少了延迟。 ALPN 的工作原理 在 TLS ClientHello 消息中，客户端通过 application_layer_protocol_negotiation 扩展发送自己支持的协议列表，按优先级排序。服务器从中选择一个双方都支持的协议，并在 ServerHello 中回显该选择。 整个协商过程在 TLS 握手内部完成，对应用层透明： 1 2 3 4 5 6 7 8 9 10 11 12 Client Server | | |-------- ClientHello ---------->| | + ALPN: [h2, http/1.1] | | | |<------- ServerHello -----------| | + ALPN: h2 | | | |-------- 后续 TLS 握手 -------->| | | |<===== TLS 加密通道建立 ========>| | 使用 HTTP/2 通信 | 常见的 ALPN 协议标识符 协议标识符 说明 h2 HTTP/2 over TLS http/1....

什么是 OCSP Stapling OCSP Stapling（正式名称为 TLS Certificate Status Request）是一种 TLS 扩展机制，允许服务端在 TLS 握手过程中主动向客户端提供证书的状态信息，而无需客户端自行向 CA 的 OCSP 响应服务器发起查询。 它的核心价值在于：将证书状态验证的责任从客户端转移到服务端，同时保护用户隐私、提升连接速度。 为什么需要 OCSP Stapling 要理解 OCSP Stapling 的价值，先看没有它时证书撤销检查的三种方式。 方式一：CRL（证书吊销列表） CA 定期发布一个包含所有已吊销证书序列号的列表（CRL），客户端下载后自行检查。 1 2 # 查看 CRL 分布点（CRL Distribution Points） openssl x509 -in cert.pem -noout -text | grep -A2 "CRL Distribution" 问题很明显：CRL 文件会随着时间不断增长，下载和解析开销越来越大。即使使用增量 CRL（Delta CRL），也难以应对大规模部署。 方式二：OCSP（在线证书状态协议） 客户端直接向 CA 的 OCSP 响应服务器发送查询，获取单张证书的实时状态。 1 2 3 # 提取证书的 OCSP 响应器 URL openssl x509 -in cert.pem -noout -ocsp_uri # 示例输出: http://ocsp....

在配置 TLS/SSL 时，我们经常看到类似 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 这样的密码套件名称。对于初学者来说，这串字符可能令人困惑。本文将详细解析 TLS 密码套件的命名规范，帮助你理解每个部分的含义。 什么是密码套件 密码套件（Cipher Suite）是 TLS 协议的核心组件，它定义了一整套加密算法组合，包括： 密钥交换算法 身份认证算法 加密算法 哈希算法 一个密码套件决定了 TLS 握手期间如何协商安全参数，以及如何加密传输的数据。 TLS 1.2 密码套件命名格式 TLS 1.2 采用以下命名格式： 1 TLS_密钥交换算法_认证算法_加密算法_哈希算法 以 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 为例： 组成部分 含义 TLS 协议名称 ECDHE 密钥交换算法（Elliptic Curve Diffie-Hellman Ephemeral） RSA 身份认证算法 AES_256_GCM 加密算法（AES，256位，GCM模式） SHA384 哈希算法 各组件详解 密钥交换算法（Key Exchange） ECDHE：椭圆曲线临时 Diffie-Hellman（推荐，前向安全） DHE：临时 Diffie-Hellman（传统但性能较低） RSA：基于 RSA 的密钥交换（已被废弃，不提供前向安全） ECDH：椭圆曲线 Diffie-Hellman（静态） 认证算法（Authentication） RSA：RSA 公钥证书 ECDSA：椭圆曲线数字签名算法 DSS：数字签名标准（较老） 加密算法（Cipher） AES_256_GCM：AES 加密，256位密钥，GCM 模式（推荐） CHACHA20-POLY1305：Google 开发的流密码（移动设备友好） AES_128_CCM：AES 加密，128位密钥，CCM 模式 ARIA256-GCM：韩国标准加密算法 哈希算法（MAC/Hash）...