security

升级到 OpenSSL 3.x 后，很多老系统生成的证书无法验证通过，错误提示类似 error:0308010C:digital envelope routines。这通常是因为 OpenSSL 3.0 默认禁用了遗留算法（MD5、SHA-1、DES、RC4 等）。本文介绍如何配置 Legacy Provider 来处理这些遗留证书。 问题背景 OpenSSL 3.0 引入了 Provider 架构，密码学算法的实现被分离到独立的 Provider 中： Default Provider：提供现代安全算法（AES、SHA-2、ChaCha20 等） FIPS Provider：提供 FIPS 140-2 认证的算法 Legacy Provider：提供遗留算法（MD5、SHA-1、DES、RC4、CAST 等） 默认情况下，只有 Default Provider 启用，因此使用遗留算法的操作会失败。 验证问题现象 1. DES 加密失败 1 2 3 4 5 $ echo -n "test" | openssl enc -des-ede3-cbc enc: Unknown cipher: des-ede3-cbc error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported: ../crypto/evp/evp_fetch.c:386:Global default library context, Algorithm (des-ede3-cbc : 27), Properties (<null>) 2....

OpenSSL 3.0 引入的 Provider 架构是其最重要的架构变革之一。它将密码学算法的实现与 OpenSSL 核心解耦，使得算法可以独立加载、更新和替换。本文深入解析 Provider 的工作机制。 为什么需要 Provider？ 在 OpenSSL 1.1.x 及之前版本中，所有密码学算法（对称加密、非对称加密、哈希、签名等）都内置在 OpenSSL 库中。这种架构存在以下问题： 紧耦合：算法实现与核心库绑定，无法独立更新 扩展困难：添加新算法需要修改 OpenSSL 源码 Legacy 负担：过时的算法实现（如 MD5、DES）始终存在 OpenSSL 3.0 引入的 Provider 架构完美解决了这些问题。 Provider 架构概述 核心概念 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ┌─────────────────────────────────────────────────────┐ │ Application │ └──────────────────────┬──────────────────────────────┘ │ OSSL_DECODER / OSSL_ENCODER ┌──────────────────────▼──────────────────────────────┐ │ OpenSSL 3.0 Core │ │ ┌──────────────────────────────────────────────┐ │ │ │ Algorithm Fetch Layer │ │ │ │ (根据 Property Query 选择合适的 Provider) │ │ │ └──────────────────────────────────────────────┘ │ └──────────────────────┬──────────────────────────────┘ │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ ┌───────────────┐ ┌─────────────┐ ┌─────────────┐ │ Default Prov │ │ Legacy Prov │ │ FIPS Prov │ │ (默认算法集) │ │ (遗留算法) │ │ (合规算法) │ └───────────────┘ └─────────────┘ └─────────────┘ Provider 类型 OpenSSL 3....

SSH 的 ForceCommand 功能可以在用户连接时强制执行预设的命令，忽略客户端尝试自行执行的命令。这在需要限制用户只能进行特定操作（如只允许 SFTP、只允许 git 推送）的场景下非常有用。 ForceCommand 工作原理 ForceCommand 是 sshd_config 中的一个指令，它会： 强制执行预设的命令，忽略用户客户端传递的任何命令 同时忽略 ~/.ssh/rc 脚本 通过用户的登录 Shell 执行预设命令（shell -c "command"） 原始命令仍可通过环境变量 SSH_ORIGINAL_COMMAND 获取（仅读取，不能执行） 1 2 3 # 查看当前默认配置 sshd -T | grep forcecommand # 输出：forcecommand none 基础配置示例 1. 禁止执行任何命令，只允许端口转发 1 2 # /etc/ssh/sshd_config ForceCommand /bin/true 这样配置后，用户无法执行任何远程命令，但可以正常使用端口转发（-L/-R）。 2. 记录用户尝试执行的命令 1 ForceCommand /usr/local/bin/audit_command.sh 审计脚本示例： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 #!...

在管理 SSL/TLS 证书和私钥时，你可能会遇到两种不同的私钥格式：PKCS#1 和 PKCS#8。本文详细介绍这两种格式的区别、使用场景以及转换方法。 什么是 PKCS#1 PKCS#1 是 RSA 加密标准的第一个版本，定义了 RSA 密钥的数学结构。其 PEM 格式的私钥文件头部为： 1 -----BEGIN RSA PRIVATE KEY----- PKCS#1 只支持 RSA 密钥，格式相对简单，直接存储 RSA 算法的参数（n, e, d, p, q 等）。 什么是 PKCS#8 PKCS#8 是通用的私钥格式标准，支持多种算法（RSA、EC、Ed25519 等）。其 PEM 格式的私钥文件头部为： 1 -----BEGIN PRIVATE KEY----- PKCS#8 使用更通用的结构，可以封装任意类型的私钥，并且支持加密存储。 格式对比 特性 PKCS#1 PKCS#8 PEM 头部 -----BEGIN RSA PRIVATE KEY----- -----BEGIN PRIVATE KEY----- 支持算法 仅 RSA RSA、EC、Ed25519 等多种算法 兼容性 旧版系统和应用 现代系统和应用（OpenSSL 1.0+） 生成与转换命令 生成 PKCS#8 格式私钥（默认） 1 2 3 4 5 6 7 8 # 生成 RSA 私钥（PKCS#8 格式，默认） openssl genrsa -out key....

DANE（DNS-Based Authentication of Named Entities）是一种基于 DNS 的证书认证机制，通过 TLSA 记录将证书信息绑定到域名上。本文详细介绍 DANE 的原理、TLSA 记录格式以及在 Nginx 中的配置方法。 传统证书验证的问题 传统的 TLS 证书验证依赖 CA（证书颁发机构）体系，存在以下问题： CA 可能被攻陷：全球有数百个可信 CA，一个 CA 被攻陷即可签发任意域名证书 证书透明度不足：难以发现恶意或错误签发的证书 依赖链复杂：多级中间 CA 增加验证复杂度和风险 什么是 DANE？ DANE 定义于 RFC 6698，是一种基于 DNS 的证书认证机制。它通过在 DNS 中添加 TLSA 记录（TLS Authentication），将证书信息直接与域名绑定，绕过传统 CA 验证体系。 DANE 的核心优势 防范 CA 被攻陷：即使 CA 被攻陷，攻击者也无法伪造 DNS 中的 TLSA 记录 自建 CA 的福音：企业内部 CA 签发的证书也能被客户端信任 证书固定：将证书指纹写入 DNS，客户端只能接受指定证书 TLSA 记录格式 TLSA 记录包含四个字段，格式为：Usage Selector MatchingType AssociationData 1 _443._tcp.example.com. IN TLSA 3 1 1 73D2522B56547E710E480F27CCFD6F75959422668C2C300B98AC07E6D7 1....

X.509 证书中的 Name Constraints（名称约束）扩展是 PKI 安全的核心机制之一。它允许 CA 证书限制其下级证书的适用范围，防止被滥用来签发任意域名的证书。本文详细介绍其工作原理和实际使用方法。 什么是 Name Constraints Name Constraints 是 X.509 证书标准（RFC 5280）定义的一个关键扩展，主要用于 CA 证书。它声明了该 CA 可以签发证书的域名和 IP 地址范围。 作用场景 限制中间 CA 权限：企业私有 CA 可以限制下级 CA 只能签发特定域名的证书 分层授权：在大型组织中实现细粒度的证书管理权限划分 安全边界：防止某个被入侵的子 CA 被用来签发其他域名的证书 约束类型 Name Constraints 包含两种类型的约束： 类型 说明 permitted 允许使用的名称范围 excluded 禁止使用的名称范围 这两个可以同时使用，excluded 优先级更高。 证书格式 Name Constraints 扩展的 ASN.1 结构如下： 1 2 3 4 5 6 7 8 9 10 11 12 NameConstraints ::= SEQUENCE { permittedSubtrees [0] GeneralSubtrees OPTIONAL, excludedSubtrees [1] GeneralSubtrees OPTIONAL } GeneralSubtrees ::= SEQUENCE SIZE (1....

本文介绍 OpenSSL 3.x 中自定义 Engine 的开发方法，帮助你实现硬件安全模块（HSM）集成、国密算法扩展等需求。 什么是 OpenSSL Engine？ OpenSSL Engine 是 OpenSSL 密码学操作的可插拔后端实现。通过 Engine，你可以： 集成硬件安全模块（HSM） 使用国密算法（如 SM2/SM3/SM4） 调用专用的加密加速卡 实现自定义的密码学算法 查看可用 Engine 系统已内置多个 Engine，使用以下命令查看： 1 openssl engine -t 输出示例： 1 2 3 4 5 6 (dynamic) Dynamic engine loading support [ unavailable ] (padlock) VIA PadLock (no-RNG, no-ACE) [ unavailable ] (afalg) AFALG engine [ unavailable ] [ unavailable ] 表示该 Engine 在当前系统上不可用，但可以加载。 使用动态 Engine 加载 OpenSSL 支持动态加载自定义 Engine。创建一个简单的配置文件进行测试： 1 2 3 4 5 # 创建 Engine 配置目录 mkdir -p ~/....

在需要对加密操作进行合规性控制的场景中，FIPS 140-2（或 FIPS 140-3）是一个重要的标准。本文介绍如何在 OpenSSL 中启用和配置 FIPS 模式。 什么是 FIPS 140-2？ FIPS 140-2 是美国国家标准与技术研究院（NIST）发布的密码学模块安全要求标准。它定义了四个安全等级（Level 1-4），要求密码学实现经过严格测试和验证。 关键点： 强制要求在政府机构和受监管行业使用 OpenSSL 通过 FIPS 模块（OpenSSL-FIPS）提供支持 FIPS 模式开启后，仅允许使用经认证的加密算法 环境检查 首先检查当前 OpenSSL 版本： 1 openssl version -a 注意输出中的 FIPS 标记。如果显示 fips-mode 相关信息，说明已支持 FIPS。 安装 OpenSSL FIPS 模块 方法一：使用系统包管理器（推荐） Ubuntu/Debian： 1 2 sudo apt update sudo apt install openssl-fips RHEL/CentOS： 1 sudo yum install openssl-fips 方法二：从源码编译 1 2 3 4 5 6 7 8 9 # 下载 OpenSSL FIPS 模块源码（以 2....

ChaCha20-Poly1305 是 TLS 1.2 和 TLS 1.3 中广泛使用的 AEAD（带认证的加密）密码套件，尤其在移动设备上因性能优势被广泛采用。本文深入解析其加密原理及 OpenSSL 命令行实现。 1. 什么是 AEAD？ AEAD（Authenticated Encryption with Associated Data）同时提供： 机密性：通过加密保护数据隐私 完整性：通过 MAC（消息认证码）验证数据未被篡改 关联数据：可选择性地对未加密的元数据进行认证 常见的 AEAD 组合包括 AES-GCM、ChaCha20-Poly1305、ChaCha20-Poly1305-IETF。 2. ChaCha20 加密算法 2.1 算法概述 ChaCha20 是 Daniel J. Bernstein 于 2008 年设计的流密码算法，作为 Salsa20 的改进版本。其核心特点： 特性 说明 类型 对称流密码 密钥长度 256 位 Nonce 长度 96 位（12 字节） 块大小 512 位（64 字节） 迭代次数 20 轮（故名 ChaCha20） 2.2 加密原理 ChaCha20 使用**置换置换网络（PRP）**结构，将密钥、Nonce 和计数器混合生成 512 位的密钥流块： 1 2 ChaCha20(key, nonce, counter) → keystream blocks ciphertext = plaintext ⊕ keystream 核心操作包括：...

什么是 FIDO2 安全密钥？ FIDO2 是一个开放认证标准，旨在提供更安全的密码替代方案。在 SSH 认证场景中，FIDO2 安全密钥（如 YubiKey、Titan Security Key 等）可以存储私钥，实现硬件级别的私钥保护。 与传统 SSH 密钥相比，FIDO2 安全密钥具有以下优势： 私钥永不离开硬件设备：即使计算机被攻破，攻击者也无法获取私钥 需要物理按键：每次认证都需要用户触摸密钥确认，防止远程恶意使用 支持 PIN 保护：可设置 PIN 码作为额外验证层 支持常驻密钥：密钥可存储在设备上，在多台机器间共享使用 支持的密钥类型 OpenSSH 支持两种 FIDO2 密钥类型： ecdsa-sk：基于 ECDSA 曲线的安全密钥 ed25519-sk：基于 Ed25519 的安全密钥（推荐） 生成 FIDO2 SSH 密钥 基本生成命令 1 ssh-keygen -t ed25519-sk -C "your-email@example.com" 生成过程中需要： 按提示触碰安全密钥的金属感应区 输入设备 PIN 码（如已设置） 常用生成选项 1. 创建常驻密钥（可在多台设备使用） 1 ssh-keygen -t ed25519-sk -O resident -C "resident-key@example.com" 常驻密钥存储在安全密钥内部，可通过 ssh-add -K 从其他机器加载。 2. 禁用触控要求（不推荐） 1 ssh-keygen -t ed25519-sk -O no-touch-required -C "no-touch@example....