https://secdoc.jazor.net/tags/security/ Recent content in security on SecDoc Hugo -- gohugo.io zh-cn © 2026 黑豆子 Tue, 19 May 2026 00:06:56 +0800 https://secdoc.jazor.net/posts/wireshark-tls-decryption-sslkeylogfile/ Tue, 19 May 2026 00:06:56 +0800 https://secdoc.jazor.net/posts/wireshark-tls-decryption-sslkeylogfile/ 在排查 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）： https://secdoc.jazor.net/posts/nginx-gmssl-tls-configuration/ Sun, 17 May 2026 00:09:53 +0800 https://secdoc.jazor.net/posts/nginx-gmssl-tls-configuration/ 介绍国密 SSL/TLS 算法（SM2/SM3/SM4），讲解在 OpenSSL 和 Nginx 中配置国密加密的实战方法。 https://secdoc.jazor.net/posts/openssl-cross-signed-certificates/ Fri, 15 May 2026 00:09:25 +0800 https://secdoc.jazor.net/posts/openssl-cross-signed-certificates/ 交叉签名证书（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，通过交叉签名让新证书也能被这些客户端接受。 https://secdoc.jazor.net/posts/openssl-engine-hsm-integration/ Wed, 13 May 2026 00:06:58 +0800 https://secdoc.jazor.net/posts/openssl-engine-hsm-integration/ 深入解析 OpenSSL Engine 架构，讲解如何通过 Engine 接口集成 HSM、PKCS#11 设备、云 KMS 等外部加密服务。 https://secdoc.jazor.net/posts/nginx-ecdsa-curve-configuration/ Tue, 12 May 2026 00:06:06 +0800 https://secdoc.jazor.net/posts/nginx-ecdsa-curve-configuration/ 在配置 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" 输出示例： https://secdoc.jazor.net/posts/tls13-hello-retry-request/ Mon, 11 May 2026 00:05:42 +0800 https://secdoc.jazor.net/posts/tls13-hello-retry-request/ 在 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 流程如下： https://secdoc.jazor.net/posts/tls-alert-protocol-explained/ Sun, 10 May 2026 00:06:28 +0800 https://secdoc.jazor.net/posts/tls-alert-protocol-explained/ 在 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（致命） 致命告警会导致连接立即关闭。常见致命告警包括： https://secdoc.jazor.net/posts/dns-caa-record-guide/ Sat, 09 May 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/dns-caa-record-guide/ 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. https://secdoc.jazor.net/posts/tls13-psk-pre-shared-key-guide/ Fri, 08 May 2026 00:05:00 +0800 https://secdoc.jazor.net/posts/tls13-psk-pre-shared-key-guide/ 预共享密钥（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 的服务器： https://secdoc.jazor.net/posts/tls13-key-update-mechanism/ Wed, 06 May 2026 00:06:32 +0800 https://secdoc.jazor.net/posts/tls13-key-update-mechanism/ 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)：我已更新密钥，并请求对方也更新 工作流程详解 密钥更新的完整流程如下： https://secdoc.jazor.net/posts/certificate-pinning-guide/ Wed, 06 May 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/certificate-pinning-guide/ 证书固定（Certificate Pinning）是一种安全加固技术，通过将网站的身份与特定的证书或公钥绑定，防止攻击者使用伪造证书进行中间人攻击（MITM）。本文详细介绍证书固定的工作原理、实现方式和实战配置。 什么是证书固定 传统 HTTPS 验证依赖证书链信任机制：由浏览器内置的根证书库验证网站证书是否由可信 CA 签发。然而，如果攻击者能控制用户的根证书（如通过恶意软件或某些网络审查工具），就可以使用任意 CA 签发的伪造证书实施中间人攻击。 证书固定的核心思想是：不仅验证证书是否可信，还验证证书是否是我们预期的那一个。通过预先在客户端保存服务器的公钥指纹或证书指纹，客户端只会接受固定的那个证书，其他任何证书（包括合法 CA 签发的）都会被拒绝。 固定方式 1. 公钥指纹固定 直接固定服务器的公钥指纹，这是最推荐的方式。公钥是证书中最稳定的部分，即使证书续期，只要不更换密钥，指纹就保持不变。 1 2 3 4 5 6 # 提取证书公钥并计算 SHA-256 指纹 openssl s_client -connect example.com:443 2>/dev/null | \ openssl x509 -pubkey -noout | \ openssl pkey -pubin -outform der | \ openssl dgst -sha256 -binary | \ base64 输出示例： 1 aqQ4L+Pac7Qy3Or7l6f9IypN8w1H64i48B4weiXJ2v4= 2. 证书指纹固定 直接固定整个证书的 SHA-256 指纹： 1 2 3 # 提取证书 SHA-256 指纹 openssl s_client -connect example. https://secdoc.jazor.net/posts/tls13-0rtt-replay-attack-protection/ Sun, 03 May 2026 00:05:56 +0800 https://secdoc.jazor.net/posts/tls13-0rtt-replay-attack-protection/ TLS 1.3 引入了 0-RTT（Zero Round Trip Time）早期数据机制，可以在一个 RTT 内完成握手，大幅降低连接延迟。然而，这一特性带来了安全隐患：0-RTT 数据可能遭受重放攻击。本文详解攻击原理与防护措施。 0-RTT 快速回顾 TLS 1.3 的 0-RTT 模式允许客户端在首次握手时立即发送加密数据，无需等待服务器完成握手。典型场景： 1 2 3 4 5 6 7 客户端 服务器 | | |-------- ClientHello (+ EarlyData) --------->| | (立即发送加密数据) | | | |<-------- ServerHello + Finished ------------| | (握手完成) | 适用场景：需要快速建立连接的 HTTP/2 预热、频繁断连的移动应用等。 重放攻击原理 攻击场景 0-RTT 数据的核心风险在于缺乏前向安全性和可能重放： 客户端首次请求（包含敏感操作，如转账） 攻击者嗅探并记录这个加密的 0-RTT 数据包 攻击者重放这个数据包到服务器 服务器误认为是有效请求，重复执行 攻击条件 重放攻击需要满足以下条件： 0-RTT 数据包被攻击者截获 服务器未对 0-RTT 数据添加足够的时间限制 某些敏感操作（如只读操作）被重复执行不会造成危害 实际影响 典型的可重放场景： 操作类型 重放风险 GET 请求（幂等） 低风险 POST 表单提交 中等风险 支付/转账 高风险 状态变更操作 高风险 攻击演示 以下演示如何在 OpenSSL 中观察 0-RTT 数据传输： https://secdoc.jazor.net/posts/ssh-agent-forwarding-guide/ Sun, 03 May 2026 00:05:00 +0800 https://secdoc.jazor.net/posts/ssh-agent-forwarding-guide/ 在日常开发和运维工作中，我们经常需要通过多台跳板机 SSH 到内网服务器。每次都需要在每台机器上配置密钥或者输入密码，非常麻烦。SSH Agent 转发（Agent Forwarding）正是解决这一问题的利器。 什么是 SSH Agent SSH Agent 是一个后台运行的程序（守护进程），它负责管理用户的私钥。当你使用 SSH 连接服务器时，SSH Agent 会自动提供私钥进行认证，无需每次都输入密码或指定密钥文件。 核心组件 ssh-agent：后台守护进程，启动后会在环境变量中设置 SSH_AUTH_SOCK ssh-add：用于将私钥添加到 agent 管理列表 工作原理 1 2 [本地主机] ----SSH 隧道----> [跳板机] ----SSH----> [目标服务器] (持有私钥) (转发请求) (验证签名) 当启用 Agent Forwarding 后，跳板机会作为代理，将服务器的认证请求转发回本地主机，由本地的 SSH Agent 完成签名验证。 配置步骤 第一步：启动 SSH Agent 1 2 3 4 5 6 # 启动 ssh-agent $ ssh-agent -s # 输出示例： # SSH_AUTH_SOCK=/tmp/ssh-XXXX/agent.259996; export SSH_AUTH_SOCK; # SSH_AGENT_PID=260133; export SSH_AGENT_PID; 第二步：添加私钥 1 2 3 4 5 6 7 # 将私钥添加到 agent $ ssh-add ~/. https://secdoc.jazor.net/posts/private-ca-internal-certificate-guide/ Sat, 02 May 2026 00:05:28 +0800 https://secdoc.jazor.net/posts/private-ca-internal-certificate-guide/ 在企业内网、测试环境或私有服务中，使用公共 CA 签发的证书不仅成本高昂，还可能带来安全风险。搭建私有 CA（Certificate Authority）可以完全掌控证书生命周期，实现内部服务的 HTTPS 加密和双向认证（mTLS）。本文将详细介绍如何使用 OpenSSL 搭建私有 CA 并签发内部证书。 什么是私有 CA 私有 CA 是组织内部自行搭建和维护的证书颁发机构，与 Let’s Encrypt、DigiCert 等公共 CA 类似，但不向外部公开。私有 CA 通常用于： 内网 HTTPS：内部系统之间的安全通信 开发测试：模拟生产环境的 HTTPS 流程 mTLS 双向认证：验证客户端和服务端双方身份 物联网设备：无法访问公共 CA 的嵌入式设备 搭建私有 CA 架构 典型的私有 CA 采用两级结构： 根 CA（Root CA）：信任的起点，长期有效（10-20 年），离线存储 颁发 CA（Issuing CA）：实际签发终端证书，有效期较短（1-3 年） 这种设计更安全：根 CA 离线保存，日常签发由颁发 CA 完成，泄露风险更低。 创建根 CA 根 CA 是整个 PKI 体系的信任根基，需要妥善保管。 1. 生成根 CA 私钥 1 openssl genrsa -out root-ca.key 4096 生成 4096 位 RSA 私钥。私钥必须严格保密，建议设置文件权限为 600。 https://secdoc.jazor.net/posts/tls-session-resumption-guide/ Fri, 01 May 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/tls-session-resumption-guide/ TLS 握手是 HTTPS 连接建立的开销大头。每次完整握手都需要额外的往返时延和计算资源。Session Resumption（会话恢复） 技术允许客户端和服务器复用之前的会话密钥，跳过昂贵的公钥加密步骤，大幅降低连接延迟。 为什么要会话恢复？ 指标 完整握手 会话恢复 往返次数 2-RTT 或 1-RTT 0-RTT RTT 时间 ~30-100ms ~5-10ms CPU 消耗 高（RSA/ECDHE） 极低 适用场景 首次连接 短间隔重复访问 对于需要频繁建立连接的 HTTPS 场景（如 Web 攻击面扫描、API 调用），会话恢复可以将 TLS 握手耗时降低 80% 以上。 Session Resumption 的三种方式 1. Session ID（TLS 1.2 及更早） 服务端维护会话缓存，用 Session ID 作为 key。 1 2 3 4 5 # 客户端：保存会话 echo "" | openssl s_client -connect example.com:443 -sess_out session.pem # 客户端：恢复会话 echo "" | openssl s_client -connect example. https://secdoc.jazor.net/posts/openssl-verify-command-usage/ Thu, 30 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/openssl-verify-command-usage/ openssl verify 是 OpenSSL 中最常用的证书验证工具，用于验证证书链的完整性和有效性。本文详细介绍其常用选项和实战场景。 基本语法 1 openssl verify [options] certificate.pem 常用选项 指定可信 CA 选项 说明 -CAfile <file> 指定一个包含可信 CA 证书的文件 -CApath <dir> 指定可信 CA 证书目录（需要哈希索引） -CAstore <uri> 从 URI 加载可信证书 1 2 3 4 5 # 使用 CAfile 验证 openssl verify -CAfile ca.crt server.crt # 同时使用 CAfile 和 CApath openssl verify -CAfile ca.crt -CApath /etc/ssl/certs server.crt 指定中间证书 1 2 # -untrusted 指定中间证书（证书链中的非可信证书） openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt 常用验证选项 选项 说明 -partial_chain 接受部分链验证（只要链到某个可信 CA 即可） -show_chain 显示完整的证书链信息 -purpose <purpose> 验证证书用途（sslserver, sslclient, etc. https://secdoc.jazor.net/posts/ssh-certificate-authentication-guide/ Wed, 29 Apr 2026 00:05:37 +0800 https://secdoc.jazor.net/posts/ssh-certificate-authentication-guide/ 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 ~/. https://secdoc.jazor.net/posts/post-quantum-cryptography-nist-standard/ Wed, 29 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/post-quantum-cryptography-nist-standard/ 量子计算的快速发展对现代密码学构成了前所未有的威胁。当前广泛使用的 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 后： https://secdoc.jazor.net/posts/certificate-transparency-%E5%8E%9F%E7%90%86%E4%B8%8E%E9%AA%8C%E8%AF%81/ Tue, 28 Apr 2026 00:06:06 +0800 https://secdoc.jazor.net/posts/certificate-transparency-%E5%8E%9F%E7%90%86%E4%B8%8E%E9%AA%8C%E8%AF%81/ 什么是证书透明度 证书透明度（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 才能完全信任证书。 https://secdoc.jazor.net/posts/tls-record-protocol-explained/ Sun, 26 Apr 2026 00:05:46 +0800 https://secdoc.jazor.net/posts/tls-record-protocol-explained/ 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. https://secdoc.jazor.net/posts/tls13-early-data-zero-rtt/ Sat, 25 Apr 2026 00:05:00 +0800 https://secdoc.jazor.net/posts/tls13-early-data-zero-rtt/ 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. https://secdoc.jazor.net/posts/perfect-forward-secrecy-guide/ Thu, 23 Apr 2026 00:08:06 +0800 https://secdoc.jazor.net/posts/perfect-forward-secrecy-guide/ 完美前向保密（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 计算得到一个共享密钥，这个密钥从未在网络上传输过，并且在连接结束后就被销毁。 https://secdoc.jazor.net/posts/tls-cipher-suite-naming/ Mon, 20 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/tls-cipher-suite-naming/ 在配置 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） https://secdoc.jazor.net/posts/hsts-http-strict-transport-security/ Sun, 19 Apr 2026 00:05:56 +0800 https://secdoc.jazor.net/posts/hsts-http-strict-transport-security/ 什么是 HSTS？ HSTS（HTTP Strict Transport Security）是一种网络安全策略机制，允许网站声明浏览器必须仅通过 HTTPS 连接访问。一旦服务器发送 Strict-Transport-Security 响应头，浏览器就会记住这个指令，在指定时间内（max-age）自动将所有 HTTP 请求转换为 HTTPS。 HSTS 响应头格式 1 Strict-Transport-Security: max-age=<过期时间>; includeSubDomains; preload 参数说明 参数 说明 max-age 浏览器记住该规则的时长，单位为秒。例如 31536000 代表一年 includeSubDomains 可选指令，作用范围包含所有子域名 preload 可选指令，表示该域名申请加入 HSTS 预加载列表 实际案例 查看主流网站的 HSTS 头配置： 1 2 # 使用 curl 查看 HSTS 响应头 curl -sI https://cloudflare.com | grep -i strict-transport-security 输出示例： 1 Strict-Transport-Security: max-age=15552000; includeSubDomains 验证多个网站 1 2 3 4 5 # 检查不同网站的 HSTS 配置 for domain in cloudflare. https://secdoc.jazor.net/posts/tls12-vs-tls13-differences/ Sat, 18 Apr 2026 00:05:45 +0800 https://secdoc.jazor.net/posts/tls12-vs-tls13-differences/ TLS（Transport Layer Security）协议是 HTTPS 的核心安全保障。从 TLS 1.2 到 TLS 1.3，协议经历了重大改进。本文详细对比两者的主要区别，帮助你理解为什么应该优先使用 TLS 1.3。 握手过程：从 2-RTT 到 1-RTT TLS 1.2 的完整握手需要两次往返（2-RTT）： 1 2 3 4 ClientHello + ServerHello + 证书 + 密钥交换 → ← ServerKeyExchange + 证书请求 + ServerHelloDone ClientKeyExchange + 证书验证 + Finished → ← Finished → 应用数据 TLS 1.3 将握手优化为一次往返（1-RTT）： 1 2 3 ClientHello + 密钥交换材料 → ← ServerHello + 密钥交换材料 + 证书 + Finished Finished → 应用数据 TLS 1.3 还支持 0-RTT 模式，允许在首次连接时就开始发送加密数据，但需要预先共享密钥。 https://secdoc.jazor.net/posts/aes-block-cipher-modes/ Fri, 17 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/aes-block-cipher-modes/ 深入解析 AES 分组加密的四种工作模式：ECB、CBC、CTR、GCM，理解各模式的原理、安全性和适用场景。 https://secdoc.jazor.net/posts/ocsp-certificate-status-check/ Thu, 16 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ocsp-certificate-status-check/ OCSP（Online Certificate Status Protocol）是用于实时检查证书是否被吊销的协议。相比 CRL，OCSP 无需下载完整吊销列表，查询效率更高。本文介绍 OCSP 原理及 OpenSSL 命令行操作。 什么是 OCSP？ 当浏览器验证 TLS 证书时，除了检查证书链和有效期，还需确认证书未被吊销。传统方式是下载 CRL（Certificate Revocation List），但列表会随时间增长。OCSP 允许客户端直接查询证书颁发机构，获取特定证书的实时状态。 OCSP 响应类型 状态 含义 good 证书有效，未被吊销 revoked 证书已被吊销 unknown 响应者不知道该证书 从证书提取 OCSP 信息 获取证书的 OCSP 响应者地址 1 openssl x509 -in certificate.crt -noout -ocsp_uri 输出示例： 1 http://ocsp.digicert.com 获取颁发者信息 OCSP 查询需要知道证书的颁发者（CA）： 1 2 3 4 5 # 获取证书颁发者 openssl x509 -in certificate.crt -noout -issuer # 获取颁发者证书 openssl x509 -in certificate.crt -noout -issuer_hash 实际 OCSP 查询示例 使用 OpenSSL 进行 OCSP 查询 1 2 3 4 5 6 7 8 9 10 11 12 13 14 # 获取目标证书和颁发者证书 openssl s_client -connect google. https://secdoc.jazor.net/posts/ecdsa-digital-signature-algorithm/ Wed, 15 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ecdsa-digital-signature-algorithm/ ECDSA（Elliptic Curve Digital Signature Algorithm）是基于椭圆曲线密码学的数字签名算法，广泛应用于比特币、区块链以及 TLS 证书中。本文介绍其原理及 OpenSSL 命令行操作。 什么是 ECDSA？ ECDSA 是 DSA（Digital Signature Algorithm）的椭圆曲线版本，利用椭圆曲线离散对数问题的计算难度来保证签名安全性。相比传统 RSA，ECDSA 在相同安全强度下密钥更短，运算更快。 常见曲线 曲线 位数 应用场景 prime256v1 (P-256) 256 位 主流 TLS 证书、Web 应用 secp384r1 (P-384) 384 位 高安全场景、政府、金融 secp521r1 (P-521) 521 位 极高安全需求 生成 ECDSA 密钥对 生成私钥 1 2 3 openssl genpkey -algorithm EC \ -pkeyopt ec_paramgen_curve:prime256v1 \ -out ecdsa_private.pem 导出公钥 1 openssl pkey -in ecdsa_private.pem -pubout -out ecdsa_public.pem 查看密钥详情 1 openssl pkey -in ecdsa_private. https://secdoc.jazor.net/posts/rsa-padding-schemes-oaep-pss/ Tue, 14 Apr 2026 00:10:00 +0800 https://secdoc.jazor.net/posts/rsa-padding-schemes-oaep-pss/ 详解 RSA 加密和签名中的填充方案，解释为什么 PKCS#1 v1.5 不安全，以及如何使用 OAEP 和 PSS 提升安全性。 https://secdoc.jazor.net/posts/diffie-hellman-key-exchange/ Mon, 13 Apr 2026 00:05:46 +0800 https://secdoc.jazor.net/posts/diffie-hellman-key-exchange/ Diffie-Hellman（DH）密钥交换协议是现代密码学的基石之一，它解决了在不安全信道上协商共享密钥的难题。本文将讲解 DH 的原理，并通过 OpenSSL 演示实际操作。 问题背景 假设 Alice 和 Bob 想要通过公开信道协商一个共享密钥，用于后续的加密通信。如果信道被窃听者监听，如何安全地交换密钥？ 传统方案需要一个安全的密钥传输渠道，但这往往不现实。Diffie-Hellman 协议巧妙地解决了这个问题：双方可以在公开信道上协商出共享密钥，而窃听者无法得知最终密钥。 数学原理 离散对数难题 DH 的安全性基于离散对数难题： 对于素数 p 和生成元 g，已知 g^a mod p 很容易计算，但从结果反推 a 却极其困难（当 p 足够大时）。 密钥交换流程 假设参数 p（大素数）和 g（生成元）已公开： 1 2 3 4 5 6 7 8 9 10 11 12 13 Alice Bob ---------------------------------------------- 1. 选择私钥 a（随机数） 1. 选择私钥 b（随机数） 2. 计算公钥 A = g^a mod p 2. 计算公钥 B = g^b mod p 3. 发送 A 给 Bob --------> 3. https://secdoc.jazor.net/posts/ed25519-key-algorithm-guide/ Sun, 12 Apr 2026 00:05:00 +0800 https://secdoc.jazor.net/posts/ed25519-key-algorithm-guide/ Ed25519 是一种基于 EdDSA（Edwards-curve Digital Signature Algorithm）的数字签名算法，使用 Curve25519 椭圆曲线的变形 Ed25519。相比传统的 RSA 和 ECDSA，Ed25519 在安全性、性能和易用性上都有显著优势，已成为现代密码学的首选签名算法之一。 Ed25519 的核心优势 1. 密钥体积小 Ed25519 的密钥非常紧凑，公钥仅 32 字节，私钥 32 字节（种子）。这相比 RSA 2048 的 256 字节公钥和 1700+ 字节的私钥，存储和传输成本大幅降低。 公钥长度对比： 1 2 3 Ed25519 公钥: 82 字节（Base64 编码后） RSA 2048 公钥: 382 字节（Base64 编码后） ECDSA P-256 公钥: 162 字节（Base64 编码后） 2. 签名速度快 Ed25519 的签名和验证速度都非常快。其设计充分利用了现代 CPU 的特性，比 ECDSA 快约 3-5 倍，比 RSA 快得多。 3. 安全性高 128 位安全强度：等效于 RSA 3072 位或 AES-128 抗侧信道攻击：实现设计避免了时序攻击等侧信道风险 确定性签名：不需要随机数生成器，避免了 ECDSA 的随机数重用漏洞 4. https://secdoc.jazor.net/posts/mtls-mutual-tls-authentication/ Sat, 11 Apr 2026 00:05:00 +0800 https://secdoc.jazor.net/posts/mtls-mutual-tls-authentication/ 什么是双向 TLS 认证 普通 HTTPS 连接中，客户端验证服务器证书，确保连接的是真实的服务器。双向 TLS（Mutual TLS，简称 mTLS） 在此基础上增加了服务器对客户端的验证——客户端必须提供有效的证书才能建立连接。 这种认证方式比用户名密码更安全，广泛用于： API 服务间的身份认证 零信任网络架构 企业内部系统访问控制 高安全要求的金融、医疗系统 工作原理 mTLS 握手过程： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 客户端 服务器 | | |---------- ClientHello --------------->| |<--------- ServerHello ----------------| |<--------- Certificate ----------------| (服务器证书) |<--------- CertificateRequest ---------| (请求客户端证书) |<--------- ServerHelloDone ------------| | | |---------- Certificate ---------------->| (客户端证书) |---------- ClientKeyExchange --------->| |---------- CertificateVerify --------->| (证明拥有私钥) |---------- Finished ------------------>| |<--------- Finished -------------------| | | |====== 加密通信通道 ====================| 关键区别：服务器发送 CertificateRequest，客户端响应自己的证书并用私钥签名证明身份。 https://secdoc.jazor.net/posts/openssl-passwd-password-hash/ Fri, 10 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/openssl-passwd-password-hash/ OpenSSL passwd 命令用于生成 Unix 密码哈希，支持 SHA-512、SHA-256、MD5 等算法，适用于系统管理和脚本场景。 https://secdoc.jazor.net/posts/https-mixed-content-solution/ Sun, 05 Apr 2026 17:20:00 +0800 https://secdoc.jazor.net/posts/https-mixed-content-solution/ 当 HTTPS 页面加载 HTTP 资源时，就会产生混合内容（Mixed Content）。浏览器会阻止不安全的请求，导致页面功能异常。本文介绍混合内容的类型、排查方法和解决方案。 什么是混合内容 HTTPS 页面中通过 HTTP 加载的资源称为混合内容： 1 2 3 4 <!-- HTTPS 页面中的混合内容 --> <script src="http://example.com/script.js"></script> <img src="http://example.com/image.jpg"> <link rel="stylesheet" href="http://example.com/style.css"> 混合内容类型 混合被动内容（Mixed Passive Content） 低风险资源，浏览器通常只显示警告： <img> 图片 <audio> / <video> 媒体 <object> 子资源 混合主动内容（Mixed Active Content） 高风险资源，浏览器会直接阻止： <script> 脚本 <link> 样式表 <iframe> 内嵌页面 XMLHttpRequest / Fetch 请求 <frame> / <object> 加载的页面 排查方法 浏览器控制台 打开开发者工具（F12），查看 Console 和 Security 面板： 1 2 3 Mixed Content: The page at 'https://example. https://secdoc.jazor.net/posts/openssl-dgst-hash-calculation/ Sun, 05 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/openssl-dgst-hash-calculation/ 使用 OpenSSL dgst 命令计算文件的 SHA-256、SHA-512、MD5 等哈希值，用于文件完整性校验和密码存储。 https://secdoc.jazor.net/posts/ssh-key-auth-setup/ Sat, 04 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ssh-key-auth-setup/ 详细讲解 SSH 密钥认证的完整配置流程，包括密钥生成、公钥部署、配置优化等步骤。 https://secdoc.jazor.net/posts/password-hash-algorithms/ Sat, 04 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/password-hash-algorithms/ 对比常用哈希算法的特点和适用场景，解释为什么存储密码要用 bcrypt 而不是 SHA-256。 https://secdoc.jazor.net/posts/sha256-hash-principle/ Fri, 03 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/sha256-hash-principle/ 深入解析 SHA-256 哈希算法的工作原理，包括消息填充、分块处理、压缩函数等核心步骤，理解其安全性的数学基础。 https://secdoc.jazor.net/posts/ssh-proxyjump-configuration/ Thu, 02 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ssh-proxyjump-configuration/ 详解 SSH ProxyJump 跳板机配置，包括命令行用法、SSH Config 配置、与 ProxyCommand 的对比。 https://secdoc.jazor.net/posts/ssl-tls-handshake-explained/ Thu, 02 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ssl-tls-handshake-explained/ 本文深入解析 SSL/TLS 握手过程，理解加密通道如何建立以及密钥交换的原理。 https://secdoc.jazor.net/posts/tls13-features-and-configuration/ Thu, 02 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/tls13-features-and-configuration/ 介绍 TLS 1.3 的核心改进，包括握手优化、加密套件精简、0-RTT 等特性，以及 Nginx、Apache 配置方法。 https://secdoc.jazor.net/posts/hash-digital-signatures/ Thu, 02 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/hash-digital-signatures/ 本文介绍哈希函数的特性、常用算法，以及数字签名如何保障数据完整性和 authenticity。 https://secdoc.jazor.net/posts/key-management-best-practices/ Thu, 02 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/key-management-best-practices/ 本文介绍密钥管理的关键实践，包括密钥生成、轮换、存储和销毁的最佳方法。 https://secdoc.jazor.net/posts/symmetric-encryption-basics/ Thu, 02 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/symmetric-encryption-basics/ 本文介绍对称加密的基本原理、常见算法及其实际应用场景。 https://secdoc.jazor.net/posts/asymmetric-encryption-explained/ Thu, 02 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/asymmetric-encryption-explained/ 本文深入解析非对称加密的工作原理，以及公钥和私钥如何协同工作。 https://secdoc.jazor.net/posts/ssh-keepalive-configuration/ Wed, 01 Apr 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ssh-keepalive-configuration/ 介绍如何配置 SSH 客户端和服务端的 keepalive 机制，防止 SSH 会话因空闲而断开。 https://secdoc.jazor.net/posts/tls-1.3-cipher-suites-guide/ Sun, 29 Mar 2026 00:00:19 +0800 https://secdoc.jazor.net/posts/tls-1.3-cipher-suites-guide/ TLS 1.3 密码套件配置指南 TLS 1.3 相比之前的版本有了重大改进，其中最重要的变化之一就是大幅简化了密码套件。本文将详细介绍 TLS 1.3 的密码套件配置和使用方法。 TLS 1.3 密码套件概述 TLS 1.3 对密码套件进行了大幅简化，移除了不安全的算法，只保留以下类型的密码套件： AEAD 密码套件：所有套件都使用 AEAD（Authenticated Encryption with Associated Data）算法 前向保密：所有套件都支持完美前向保密（PFS） 移除弱算法：不再支持 RC4、MD5、SHA-1 等 TLS 1.3 支持的密码套件 1. GCM 密码套件 密码套件 密钥交换 认证 加密 密钥长度 适用场景 TLS_AES_256_GCM_SHA384 ECDHE ECDSA/RSA AES-256-GCM 256位 高安全性要求 TLS_CHACHA20_POLY1305_SHA256 ECDHE ECDSA/RSA ChaCha20-Poly1305 256位 移动设备、弱网络 TLS_AES_128_GCM_SHA256 ECDHE ECDSA/RSA AES-128-GCM 128位 标准安全性 TLS_AES_128_CCM_SHA256 ECDHE ECDSA/RSA AES-128-CCM 128位 兼容性要求 2. 查看系统支持的 TLS 1.3 密码套件 1 2 3 4 5 # 查看 OpenSSL 支持的 TLS 1. https://secdoc.jazor.net/posts/openssl-ec-key-generation/ Sun, 29 Mar 2026 00:00:18 +0800 https://secdoc.jazor.net/posts/openssl-ec-key-generation/ OpenSSL EC 密钥生成与管理 椭圆曲线密码学（Elliptic Curve Cryptography, ECC）是现代密码学中的重要技术，相比传统 RSA 算法，ECC 在提供相同安全级别的情况下只需要更短的密钥长度。本文详细介绍如何使用 OpenSSL 生成和管理 EC 密钥。 EC 密钥的优势 相比 RSA 密钥，EC 密钥具有以下优势： 更短的密钥长度：256位 EC 密钥相当于 3072位 RSA 密钥的安全强度 更快的计算速度：加密解密和签名验证速度更快 更小的存储空间：密钥文件更小，节省存储空间 更低的带宽占用：传输密钥时占用更少带宽 生成 EC 密钥对 1. 生成 EC 私钥 1 2 3 4 5 6 7 8 # 生成 P-256 曲线的 EC 私钥 openssl ecparam -name secp256r1 -genkey -out ec_private.pem # 生成 P-384 曲线的 EC 私钥 openssl ecparam -name secp384r1 -genkey -out ec_private.pem # 生成 P-521 曲线的 EC 私钥 openssl ecparam -name secp521r1 -genkey -out ec_private. https://secdoc.jazor.net/posts/certificates-crl-validation-guide/ Sun, 29 Mar 2026 00:00:16 +0800 https://secdoc.jazor.net/posts/certificates-crl-validation-guide/ 证书吊销列表验证指南 证书吊销列表（Certificate Revocation List, CRL）是 PKI 系统中用于撤销已颁发证书的重要机制。本文将详细介绍如何使用 OpenSSL 工具验证证书的吊销状态。 什么是证书吊销列表 CRL 是由证书颁发机构（CA）维护的已撤销证书的列表。当证书出现以下情况时，会被添加到 CRL 中： 私钥泄露 证书信息变更 用户不再需要该证书 CA 发现证书存在问题 验证证书吊销状态的命令 1. 查看证书基本信息 1 openssl x509 -in certificate.pem -text -noout 2. 下载 CRL 文件 1 2 3 4 5 # 从证书中提取 CRL 分布点 openssl x509 -in certificate.pem -text -noout | grep -A 5 "CRL Distribution Points" # 下载 CRL 文件 wget -O crl.crl http://crl.example.com/crl.crl 3. 验证证书是否被吊销 1 openssl x509 -in certificate.pem -noout -purpose sslserver -verifycrl crl. https://secdoc.jazor.net/posts/openssl-certificate-management/ Sat, 28 Mar 2026 00:00:34 +0800 https://secdoc.jazor.net/posts/openssl-certificate-management/ OpenSSL 是最强大的证书管理工具之一。本文聚焦日常证书管理中最常用的操作：生成、签名、转换和验证。 生成私钥 生成 RSA 私钥 1 2 3 4 5 6 7 8 # 生成 2048 位 RSA 私钥 openssl genrsa -out private.key 2048 # 生成 4096 位 RSA 私钥（更安全） openssl genrsa -out private.key 4096 # 生成带密码保护的私钥 openssl genrsa -aes256 -out private-encrypted.key 2048 生成 EC 私钥 1 2 3 4 5 # 生成 EC 私钥（P-256 曲线） openssl ecparam -name prime256v1 -genkey -noout -out ec-private.key # 生成 EC 私钥（P-384 曲线） openssl ecparam -name secp384r1 -genkey -noout -out ec-private-384. https://secdoc.jazor.net/posts/tls-protocol-deep-dive/ Sat, 28 Mar 2026 00:00:33 +0800 https://secdoc.jazor.net/posts/tls-protocol-deep-dive/ TLS（Transport Layer Security）协议是现代互联网安全的基石。本文聚焦 TLS 1.2 和 TLS 1.3 的核心差异，帮助你理解协议升级的重要性。 TLS 1.2 的工作流程 TLS 1.2 的握手过程需要 2 个 RTT（Round-Trip Time）： 1 2 3 4 5 6 7 8 9 10 11 Client Server |-------- ClientHello ----------------------->| |<------- ServerHello ------------------------| |<------- Certificate ------------------------| |<------- ServerKeyExchange ------------------| |<------- ServerHelloDone --------------------| |-------- ClientKeyExchange ----------------->| |-------- ChangeCipherSpec ------------------>| |-------- Finished -------------------------->| |<------- ChangeCipherSpec -------------------| |<------- Finished ---------------------------| 使用 OpenSSL 测试 TLS 1.2 连接 1 2 3 4 5 # 测试服务器是否支持 TLS 1. https://secdoc.jazor.net/posts/ssh-key-types-conversion/ Thu, 26 Mar 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ssh-key-types-conversion/ SSH 密钥认证比密码认证更安全、更方便。但面对多种密钥类型，应该如何选择？本文聚焦这个问题。 常见密钥类型对比 类型 密钥长度 安全性 性能 兼容性 ed25519 256位 极高 最快 OpenSSH 6.5+ rsa 4096位 高 较慢 广泛兼容 ecdsa 521位 高 快 较好 推荐：优先选择 Ed25519 Ed25519 是目前最推荐的 SSH 密钥类型： 安全性高：基于椭圆曲线，256位密钥相当于 RSA 3072位 性能优秀：签名和验证速度都很快 密钥简短：私钥仅 411 字节，公钥仅 98 字节 生成 Ed25519 密钥 1 ssh-keygen -t ed25519 -C "your_email@example.com" 输出示例： 1 2 3 4 5 Generating public/private ed25519 key pair. Your identification has been saved in test_key_ed25519 Your public key has been saved in test_key_ed25519. https://secdoc.jazor.net/posts/csr-certificate-signing-request/ Tue, 24 Mar 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/csr-certificate-signing-request/ 什么是 CSR？ CSR（Certificate Signing Request，证书签名请求） 是申请 SSL/TLS 证书时向证书颁发机构（CA）提交的文件。它包含了申请者的公钥和身份信息，由申请者的私钥签名。 CSR 的用途 申请 SSL/TLS 证书 - 向 CA 提交 CSR 申请服务器证书 身份验证 - CSR 中的信息用于验证申请者身份 密钥关联 - 将公钥与域名/组织信息绑定 CSR 包含哪些信息？ 一个标准的 CSR 包含以下信息： 字段 说明 示例 C (Country) 国家代码 CN ST (State) 州/省 Beijing L (Locality) 城市 Beijing O (Organization) 组织名称 Example Corp OU (Organization Unit) 部门 IT Department CN (Common Name) 通用名称/域名 example.com emailAddress 电子邮件 admin@example.com 此外，CSR 还包含： 公钥 - 与私钥配对的公钥 签名 - 使用私钥生成的数字签名 可选扩展 - 如 Subject Alternative Name (SAN) 使用 OpenSSL 生成 CSR 基本命令格式 1 2 3 4 5 # 生成私钥的同时生成 CSR（交互式） openssl req -new -newkey rsa:2048 -nodes -keyout domain. https://secdoc.jazor.net/posts/ssh-hardening-best-practices/ Tue, 24 Mar 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ssh-hardening-best-practices/ SSH（Secure Shell）是系统管理员最常用的远程访问协议，也是攻击者的首要目标。本文详细介绍 SSH 安全加固的各个层面，从基础配置到高级技巧，帮助你构建坚不可摧的 SSH 防线。 一、SSH 基础安全配置 sshd_config 核心配置 配置文件路径：/etc/ssh/sshd_config 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 # 禁用 root 登录 PermitRootLogin no # 禁用密码认证（强制密钥认证） PasswordAuthentication no PubkeyAuthentication yes # 禁用空密码 PermitEmptyPasswords no # 禁用 PAM（可选，提高安全性但可能影响某些认证方式） UsePAM no # 限制登录用户 AllowUsers admin deploy@192.168.1.0/24 # 或使用组 AllowGroups ssh-users # 设置登录超时（秒） LoginGraceTime 60 # 最大认证尝试次数 MaxAuthTries 3 # 限制会话数 MaxSessions 10 # 限制启动会话数（防止资源耗尽） MaxStartups 10:30:100 # 格式: start:rate:full # start: 开始拒绝前的未认证连接数 # rate: 拒绝概率增长速率 # full: 完全拒绝的连接数 修改默认端口 1 2 3 4 5 6 7 8 9 10 11 12 # 不要使用默认的 22 端口 Port 2222 # 或使用多个端口（便于过渡） Port 22 Port 2222 # 记得更新防火墙规则 ufw allow 2222/tcp # 或 firewall-cmd --add-port=2222/tcp --permanent firewall-cmd --reload 完整的安全配置示例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 # /etc/ssh/sshd_config 安全加固版 # 网络设置 Port 2222 AddressFamily inet ListenAddress 0. https://secdoc.jazor.net/posts/ssl-tls-certificates-deep-dive/ Tue, 24 Mar 2026 00:00:00 +0800 https://secdoc.jazor.net/posts/ssl-tls-certificates-deep-dive/ SSL/TLS 证书是互联网信任体系的基石。本文深入剖析证书的工作原理、类型选择、配置最佳实践，以及常见问题的排查方法。 一、证书工作原理 TLS 握手过程 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 客户端 服务器 | | | 1. ClientHello | | (支持的加密套件、TLS版本、随机数) | | --------------------------------------> | | | | 2. ServerHello | | (选定加密套件、TLS版本、随机数) | | + Certificate (服务器证书链) | | + ServerKeyExchange (可选) | | + CertificateRequest (可选,双向认证) | | <-------------------------------------- | | | | 3.