ssl

在 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 流程如下：...

在 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（致命） 致命告警会导致连接立即关闭。常见致命告警包括：...

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

预共享密钥（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 的服务器：...

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)：我已更新密钥，并请求对方也更新 工作流程详解 密钥更新的完整流程如下：...

证书固定（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....

什么是 SNI？ SNI（Server Name Indication，服务名称指示） 是 TLS 协议的一个扩展，允许客户端在 TLS 握手开始时提前声明要访问的服务器域名。这一看似简单的机制，彻底解决了 HTTPS 早期的核心痛点——单 IP 多域名 问题。 为什么需要 SNI？ 在 SNI 出现之前，TLS 握手存在一个困境： 客户端发送 ClientHello 消息时，还没有指定要访问的具体域名 服务器收到 ClientHello 后，无法确定客户端想要哪个虚拟主机 服务器只能返回一个"默认"证书，无法为每个域名提供正确证书 这意味着： 一个 IP 地址只能部署一个 HTTPS 网站 要托管多个 HTTPS 网站，必须为每个网站分配独立 IP SNI 的出现改变了这一局面。客户端在 ClientHello 中直接携带 server_name 扩展，声明目标域名，服务器据此返回对应证书。 工作原理 TLS 握手中的 SNI SNI 作为 TLS 扩展（Extension），在 ClientHello 消息中发送： 1 2 3 4 5 6 7 8 9 ClientHello ├── Version: TLS 1.2 / TLS 1....

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 数据传输：...

在企业内网、测试环境或私有服务中，使用公共 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。...

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